How Adrian builds an app, step by step
· updated
Between typing a prompt and getting a running app, Adrian does five things: it turns the prompt into a build plan, assigns specialist agents to the parts, generates the code, puts it through a compile gate with a repair loop, and boots the result into a live preview. Most AI coding tools hand you a wall of text and leave the running to you. This is what happens in between instead.
1. The prompt becomes a plan
Your prompt is not passed straight to a code model. It is first turned into a build plan — what the app is, what it needs, and which specialists should work on it. Vague prompts get an interview step instead of a guess, because a wrong assumption early is the most expensive kind: every later stage builds on it, and the cost of discovering it at the preview is the whole build.
Part of planning is working out what kind of thing you asked for. A landing page, a dashboard and a portfolio have different expected shapes, and knowing which one you meant is what later lets the system notice that something is missing rather than broken.
2. Specialists take their parts
Adrian runs a crew rather than one generalist model. Different roles handle design, code, and review, and the crew you get scales with your plan. Model choice per role is not fixed — you can see and change the assignment.
The split is not decoration. Coding and visual design are genuinely different skills, and the models that are best at them are different models — so a coder and a designer are assigned separately, by capability rather than by whatever happened to be installed first. It is also the reason you can mix: run the designer on a local model and the coder on an API key, or the reverse.
3. The agents read before they write
On anything but a blank project, generating a change means first working out which files matter. An agent that rewrites a file it never read is how a follow-up prompt quietly undoes the previous one.
This is also the stage that costs the most tokens on a paid model, and the reason a build system spends more than a chat window for the same question — what building actually costs breaks that down.
4. The compile gate
Generated code is compile-checked before you ever see it. Dependencies are installed and the project is type-checked; if it fails, a repair loop gets to fix it, with one final attempt after the ordinary retries are exhausted. Code that cannot be made to compile does not get quietly handed over as if it were finished.
Compiling is a floor rather than a finish line, so the gate is followed by deterministic checks that read the code against the request — scaffold text left behind, features with no implementation, state nothing can change. Findings go back to the coder as instructions and the checks run again, so a repair is verified rather than assumed.
5. A preview you can actually use
The result boots into a live preview beside the editor, and follow-up prompts edit the same project rather than starting over. There is a full Monaco-based editor when you want to change something by hand.
Being able to edit by hand matters more than it sounds. The failure mode of a pure prompt-driven builder is the last ten per cent — the specific spacing, the one condition you cannot phrase — where describing the change costs more than making it. An editor beside the preview means you are never stuck negotiating with a model over a two-line fix.
What the second prompt does
The first build is the demo; the second prompt is the product. Asking for a change runs the same pipeline against an existing project rather than a blank one, which is a harder problem — the agents have to find the files that matter, change those, and leave everything else alone.
This is where prompt-driven builders most often disappoint. A system that regenerates from scratch on every prompt will happily undo the fix it made two prompts ago, and you end up fighting it. Editing in place is slower to build and the only version that survives contact with a real project.
It is also why the checks run on every pass, not just the first. A regression introduced by a follow-up is exactly as invisible as one introduced by the initial build, and considerably more annoying.
What it costs to try
- Running local models through Ollama is free, with no account required.
- Bringing your own API key is free — Adrian never takes a cut of your provider bill.
- Adrian Agents, the hosted crew with credit included, is the paid tier.
What is not in the pipeline yet
Deployment. The pipeline takes you to a working app on your machine, and getting it hosted somewhere is still on the roadmap rather than in the product. If you want the finished thing deployed for you, that is a real reason to use something else today, and the comparisons say so plainly. The same goes for the platform: this is a Windows desktop application, and macOS and Linux have not shipped.
The Windows desktop build is available now. The current build is unsigned, so Windows will show a SmartScreen warning on first run — the download page explains how to verify the checksum before you run it.