How App Foundry builds a running app from one prompt

There is a quiet sleight of hand in most “AI app builders.” You describe what you want, watch some boxes connect themselves on a canvas, and are told you’ve built an app. You haven’t. You’ve built a diagram. Someone still has to host it, secure it, wire the credentials, give it a database, write the tests, and own it at 2am when it breaks.

App Foundry starts from the same place you do — a sentence describing what you want — and finishes somewhere different: a self-sustaining application running on your own infrastructure, with its own database, container, test suite, and a complete audit trail of how it was built.

The output isn’t a chatflow you have to babysit. It’s software you can run, observe, and change by sending it another message.

Describe & attach

The input is deliberately small. You write the goal in plain language, and — optionally — attach the definitions you already own: agents, workflows, skills, a harness, MCP tools, RAG datasets. Then you pick a build mode (hybrid, agent-first, or human-first) and the surfaces you need: a web UI, an API, an MCP server, docs.

Everything you attach becomes context the build is grounded in — not decoration. Attach a “Calculator” agent and it doesn’t just flavour the prompt; its engine can be called during the build and delegated to at runtime.

PRD-first, with a human in the loop

Before a single line of code is written, a product-architect agent drafts a PRD. This is where the platform earns trust: if it detects an external dependency — a payment provider, an identity gate — it pauses and asks rather than hallucinating an integration. Nothing load-bearing is generated from a guess.

You review the PRD, answer the open questions, and the build resumes. In hybrid mode it also gates the blueprint and the deploy; in human-first mode it gates every stage. You decide how much rope to give it.

The harness does the work

Once the plan is approved, a deep-agent harness takes over and drives the rest of the pipeline:

• It plans with explicit todos, so long builds stay on track.
• It provisions MCP servers and registers tools.
• It spawns sub-agents in parallel — research, architect, coding, review, ops.
• It generates the code, then self-verifies with pytest and Playwright, feeds failures back to itself, and retries until the checks pass.

The stages are legible the whole way through: PRD → blueprint → scaffold → generate → verify → deploy, streamed live into a run ledger.

Ship & govern

The result deploys to your infrastructure behind HITL gates and RBAC, with every event, cost and token recorded. Deploy always gates — shipping is irreversible — and a failed health check rolls back automatically.

What you’re left with is not a prototype. It’s an app with a database, a container, tests, and a paper trail. Want a change? Send it another message and it revises itself, re-verifies, and re-ships.

---

A flow builder stops at the canvas because the canvas is all it ever produced. App Foundry treats the description as the beginning of the work, not the end of it — which is why what comes out the other side is an application, not a picture of one.