What you can build, start to finish.

A solution is one complete job, followed end to end. It names a starting situation — you run a bakery with no website, you have a red test in CI — walks every stage in order, and finishes with something specific that now exists. It is narrower than a feature list and broader than a tutorial step, and it is written to answer the question people actually have, which is not “can this be done” but “what does doing it here involve, and what am I left holding.”

That is different from a use case, which describes who you are rather than what you are doing. Use cases are organised by industry and by role — retail, finance, education, health, product management, operations, developer productivity — and show the range of things people in that position build. It is also different from a template, which is a starting point rather than a path: a finished, hand-built app you can spin up in one click and then change by chat. And it is different again from a capability, which is one thing the platform does. Solutions are assembled out of capabilities; the capability pages explain each mechanism on its own terms.

Most people arrive through a use case and leave through a solution. If you already know what you want to build, skip the taxonomy and go straight to the pattern whose shape matches yours.

Two shapes of work, not six niches

The six patterns below are not six industries. They are two fundamentally different ways of working, with three worked examples each, and the difference between them matters more than the difference between a bakery and a barbershop.

The first group starts from nothing but a sentence. There is no codebase, no hosting account and no repository, and the whole point is that none of those become your problem. The second group starts from a codebase you already own and already care about, where speed matters far less than knowing what is true about a change before you are asked to approve it. Everything else — how you pick, what is always included, how long the path is, and what you own at the end — is covered further down this page.

These three are the same machinery applied to different jobs, and each one is chosen because it exposes a different part of it. Adding dark mode is a test of coverage: the difficulty is not making a colour dark, it is finding every place colour is set, including the screens you would never have listed. Fixing a failing test is a test of diagnosis: anyone can make a suite green by weakening an assertion, which is worse than leaving it red. A TypeScript migration is a test of follow-through: types added without resolving the downstream fallout is how migrations stall, and types added as any is how they deliver nothing.

The arrangement underneath all three is the same, and it is deliberately conservative. The repository is indexed semantically and by symbol before anything is touched. The edit happens in an isolated sandbox clone, where your own typecheck, tests and build have to pass. What reaches your repository is a pull request — never a direct push, never an automatic merge — and your code does not change until you merge it.

A number invented for a marketing page would be worse than no number, so here is the useful version instead: the stages, and where your attention is genuinely required. On both paths the pattern is the same — the mechanical work happens elsewhere, and what is left for you is judgement at two or three specific moments.

The create path

A new project opens in chat before it opens any tabs. The agent asks about the parts of your idea it cannot guess — who signs in, what gets stored, whether money changes hands — and fills in a blueprint as you answer. While the scope is thin the header button reads Blueprint; once there is enough to build from it becomes Review blueprint, and the build starts from your confirmation. Nothing there is permanent: the blueprint is a starting point, not a contract, and you can change anything after the first build.

From there it is build, preview, refine, Go Live. Your attention is needed twice: once to settle the scope, and once to look properly at the preview — including at phone width, where problems are cheapest to catch. Everything between those two moments is code, checks and deploys, none of which are yours to do.

The edit path

The stages carry the product’s own names: connect, index, edit, verify, pull request. You authorise a repository once, describe a change in your own terms once, and review a pull request once. The indexing, the sandbox work and the compile-fix loop happen away from your machine, which is where the interruption cost of this kind of work has always lived.

The one lever you control

A project’s build quality decides how much effort a build is allowed to spend. Prototype is the fastest and cheapest with fewer checks — the right choice for testing whether an idea is worth having. Standard is the balanced default. Best researches current practice and reviews more before shipping, which is slower and a bit pricier, and is what you want for something people will rely on. The docs glossary defines each one.