How to Build a Web Application With AI

Most AI code tools answer a narrow question: "write this function". That is useful, but it is not the same job as building an application. An application has a data model, a route structure, a set of screens that agree with each other, and states that have to behave — a signed-out visitor, a signed-in customer, an administrator, an empty list, a failed request.

The difference matters because the hard part of application work is not writing a component. It is keeping a dozen decisions consistent with each other while they are being made at the same time. That is the problem an autonomous builder is actually trying to solve, and it is worth judging one on that basis rather than on how fast it emits tokens.

What an AI builder should actually produce

Before you write a single line of prompt, it helps to have a checklist of what "finished" means, because it determines what you ask for. For a web application built with Echo, a finished result has five parts:

1. A plan you have read and agreed with — the routes, the data model, and the shape of the application.
2. Code that runs: a TypeScript project that compiles and a set of routes that respond.
3. A live preview you can click through without leaving the project.
4. A record of what changed, so a follow-up instruction edits the right thing.
5. Full source code you can export or push to a repository, with no runtime you have to buy later.

If a tool can give you items 2 and 3 but not 1, 4 and 5, you are not building an application — you are collecting a prototype. Echo is built around all five, which is why the way you brief it matters so much.

Write a brief that produces a useful first build

The single most common reason a first build is disappointing is not the model. It is that the request described a category of app instead of an app. "Build me a CRM" gives the planner nothing to anchor on. "Build me a CRM for a 12-person landscaping company that tracks jobs by crew, photos the work and invoices on completion" gives it anchors.

A useful brief names four things:

• Who the user is and what they are trying to get done.
• The two or three jobs the app must do well.
• The data the app holds, described in plain language — "a job has a crew, a date, a set of photos and an invoice".
• The visual direction, if you care about it — "clean, dense, a lot of tables, no illustrations".

Echo's composer also accepts reference files — a schema, a spec, an existing export — and you can dictate a brief instead of typing it. If you already have a data model or a written spec, attach it; the plan is better when it has something concrete to work from.

Read the plan before you read the code

Echo can plan before it builds. Choosing **Plan** in the composer produces a technical blueprint first — the route graph, the data model, the API contracts — and waits for you to look at it. This is the cheapest possible place to catch a mistake, because changing a plan costs one message, while changing an implemented feature costs a rebuild.

Read it as a reviewer, not as a user of the app. The questions worth asking:

• Are the routes the ones you expected, and is anything important missing?
• Does the data model have the relationships the product actually needs, with the right ownership rules?
• Is there a page for the empty state, the error state and the permission-denied state?
• Is anything in there that you did not ask for and would have to unpick later?

The plan is the cheapest artifact in the whole process. Every minute spent reading it is a minute you do not spend debugging a half-built screen.

Watch the build instead of guessing at it

Once you approve the plan, Echo runs the implementation as several specialist agents working at the same time: one on the interface, one on state and data access, one on the API surface, one on quality. They edit different files, so they do not fight over the same lines, and the plan acts as the contract they all agreed to.

You can follow the build conversation in the workspace, but you do not have to. The useful thing to watch is the activity trail — every file that changed, and what changed in it. When you later ask for a revision, that trail is what lets the agent edit the right thing instead of rebuilding the screen from scratch.

Let verification do its job

This is where an autonomous builder earns its keep. After the code is written, Echo launches the project in an isolated browser sandbox and checks the things that are cheap to check automatically and expensive to discover by hand:

• Does the project compile under a strict TypeScript check, with no errors?
• Does each route respond when the sandbox requests it?
• Did the interface actually get styled, or did it ship as unstyled markup?
• Does the page render in a real browser, with a real DOM, rather than just compiling?

When something fails, Echo does not hand you a broken preview and wish you luck. It repairs and re-runs, using the failure output as the input to the next attempt. You get a preview that has already survived a browser, which is a materially different thing from a preview that merely type-checks.

Iterate in small, reviewable steps

The fastest way to waste an afternoon is to ask for a redesign, then ask for three features, then ask for the layout to be "more modern", and then ask why nothing works. Each message changes the context the next one is answered in.

A better loop is one change, then look, then the next change:

1. Make one request, in the vocabulary of the app ("the jobs list should be sortable by date and filterable by crew").
2. Look at the preview and the diff, not just the summary.
3. Confirm the change did not break the screen you already liked.
4. Only then ask for the next thing.

Echo keeps every modification in a shared activity trail, so "did my last change break the invoice screen?" is a question you can answer by reading, not by re-running.

Take the code and ship it

At the end of the run, the project is yours. Echo exports the full source code as a ZIP, and you can push the repository to GitHub, GitLab or Bitbucket directly from the workspace. There is no proprietary runtime in the middle: the output is a standard React and Next.js TypeScript project with the dependencies it declared.

That matters for two reasons. It means the application keeps working if you stop paying. And it means you can hand the code to a real engineering team, put it in CI, and keep shipping it long after the conversation with the builder is over. Echo can also prepare a deployment and hand it to a hosting provider you have connected — but the provider makes the final decision, and the code never depends on that decision.

A worked example brief

Here is a brief in the shape described above. It is deliberately specific, and it is the kind of input that produces a first build you can actually review:

Build an internal dispatch board for a field-service company with 12 technicians.

Jobs have: customer, address, crew, scheduled date, status, and a list of photos.
Statuses: scheduled, en route, on site, complete, invoiced.

Three roles: dispatcher (sees everything, assigns crews), technician (sees only their
own jobs for the day, uploads completion photos), owner (sees revenue totals).

Pages: today's board, job list, job detail, crew schedule, weekly revenue.

Visual direction: dense, quiet, mostly tables, no illustrations, works on a phone.

Do not build invoicing or payments yet — just show an invoice status field.

Five minutes of writing that brief will save an hour of revision, because every decision the planner has to make is either answered or explicitly deferred.

If you want the longer version of the same idea for product work rather than internal tooling, read the guide on building a SaaS MVP with AI. If you want to understand the machinery behind the plan-and-build loop, read how AI coding agents plan, build and test software.