The ten build rules.

You give an AI one line, it builds for an hour, and the thing that comes back is not what you meant. Everyone blames the model. The problem is almost always the way the build was run.

These are the ten rules Sean follows on every build, from internal dashboards to the tools linked on this site. The first three are about the plan, because that is where most builds go wrong.

No contractor starts work without approved drawings. Neither should your AI.

THE CHECKLIST

The rules.

Make it plan before it builds.
Ask your AI to go into plan mode and write a PRD, which is the plan for the app in plain words: what you are building, who uses it and every screen. No building until the plan exists.
Review the plan like a contractor's drawings.
Read every line and correct what is wrong. A correction on the plan costs you a minute. The same correction after the build costs you the rebuild.
Approve it, then let it build.
Building starts when the plan says exactly what you want, and only then. That approval is the whole trick.
Give it your business before you give it the job.
Prices, customers, how the work gets done. An AI that knows your business builds the thing you meant the first time.
One feature at a time.
“Build me an app” comes back wrong. “Add a booking form to this page” comes back right. Small asks, checked as you go.
Open it and try it after every feature.
Click through it the way a customer would before you ask for the next thing. An AI reporting that something works is not the same as it working.
When it comes back wrong, fix the instruction.
The model did what the instruction said. Rewrite the instruction with what was missing and run it again.
Keep everything in plain files you own.
If the app and its plan live in files on your machine, you can change AI tools tomorrow and lose nothing.
Save a version before every big change.
When something breaks you go back one step instead of starting over, and big changes stop being scary.
End every session with a written handover.
Ask the AI to write down what it did and what is left. The next session starts knowing everything instead of starting from zero.

The same ten rules as plain text, for your notes or the instructions file your AI reads.

The checklist.

1. Make it plan before it builds. Ask your AI to go into plan mode and write a PRD, which is the plan for the app in plain words: what you are building, who uses it and every screen. No building until the plan exists.

2. Review the plan like a contractor's drawings. Read every line and correct what is wrong. A correction on the plan costs you a minute. The same correction after the build costs you the rebuild.

3. Approve it, then let it build. Building starts when the plan says exactly what you want, and only then. That approval is the whole trick.

4. Give it your business before you give it the job. Prices, customers, how the work gets done. An AI that knows your business builds the thing you meant the first time.

5. One feature at a time. “Build me an app” comes back wrong. “Add a booking form to this page” comes back right. Small asks, checked as you go.

6. Open it and try it after every feature. Click through it the way a customer would before you ask for the next thing. An AI reporting that something works is not the same as it working.

7. When it comes back wrong, fix the instruction. The model did what the instruction said. Rewrite the instruction with what was missing and run it again.

8. Keep everything in plain files you own. If the app and its plan live in files on your machine, you can change AI tools tomorrow and lose nothing.

9. Save a version before every big change. When something breaks you go back one step instead of starting over, and big changes stop being scary.

10. End every session with a written handover. Ask the AI to write down what it did and what is left. The next session starts knowing everything instead of starting from zero.

START WITH RULE ONE

The plan is the whole trick.

Ask your AI to go into plan mode before it builds anything, and have it write the plan as a document you can read: what the app is, who uses it, every screen, and the order it will build them in. Correct the document, approve it, and only then say build.

Corrections on the plan cost minutes. The same corrections after the build mean rewriting the app at the end, which is where most people decide AI can’t build. It can. It was never given a plan.

Rule four matters almost as much: an AI that knows your business builds the thing you meant. The Context Interview Prompt writes your business down for it, and the Vault Prompt gives those files a permanent home.

WHAT CHANGES

Builds stop being a gamble.

Run a build this way and the app that comes back matches the plan you approved, because there was a plan to match. The rules work for more than apps: a website, a proposal, anything complex enough to go wrong is worth a plan you have read first.

Sean runs 6 live internal apps built exactly this way, and the method behind them is what we install for clients.

See what we do