GREA · applied AI

Send an idea. Get a signed Android build.

App Foundry turns a paragraph into a buildable app spec, a real Expo project, and a Play-ready App Bundle — then stops at a draft for you to approve or send back.

Open the app See the pipeline

foundry — a real run

$ foundry submit "app for restaurant staff to swap shifts"
→ spec      3.1s    com.grea.shiftswap · 5 screens
→ generate 27.3s    ~/dev/foundry-builds/shiftswap
→ build   103.5s    46,898,292 bytes
→ verify           package=com.grea.shiftswap
                   targetSdk 36 · jar verified
→ upload           needs Play service account

The pipeline

Six stages, one of which is deliberately not automated. State lives in a Cloudflare Worker with D1; the Gradle work happens on a machine that claims jobs from it.

intakeyou describe the idea

A sentence is enough. Attach a brief if you have one. It is stored, not summarised away.
spec~3 s

The model returns a structured spec — app name, package id, store copy, screens, and a list of risks it wants you to see before anything is built.
generate~27 s

Clones a known-good Expo project, rewrites the package id, moves the Kotlin sources to match, writes the screens, and installs dependencies fresh.
build~104 s

Gradle produces a release App Bundle signed with the upload key. Slow the first time, fast after — the native compilation is cached.
verifyevery time

The bundle's own manifest is read back and the signature checked. A green build log is not evidence; the artifact is.
uploadone manual click, by design

Google's Publisher API has no method that creates an app record — every app-scoped call needs a package that already exists. So each new app is created once in Play Console, and everything after that is automatable.

What it has actually produced

Not a demo. Two apps taken from a paragraph to a signed bundle, with the package id read back out of each artifact.

Both bundles verified with `bundletool dump manifest` and `jarsigner`.
Idea	Package	Screens	Build	Bundle
Yard-sign tracker	`com.grea.signtracker`	4	123 s	`46,896,056 B`
Restaurant shift swap	`com.grea.shiftswap`	5	104 s	`46,898,292 B`

Where it stops

The interesting part of a system like this is the edges. These are real, not hedged.

Play accountUploading needs a Play developer account and a service account bound to it. Neither exists yet, so the upload stage refuses rather than pretending.
App recordsGoogle's API cannot create an app. One console click per app is unavoidable; the pipeline reports it instead of hiding it.
Generated UIThe model ignores brand colours and line limits — it has written a 510-line screen file in its own palette. Treat generated UI as a first draft.
SigningEvery generated app currently reuses one upload key. Play allows it; per-app keys are better practice.

Why it is built this way. Cloudflare owns state, the conversation, and the upload call. Gradle cannot run in a Worker, so a machine-resident worker claims jobs and reports back. That split is the whole architecture, and it is why the system can be inspected stage by stage.