A short video I posted about this got saved hundreds of times more than anything else I have shared, which tells me something: a lot of people are building projects with AI, and most of them can feel that their process is missing structure. So here is the full version, the five steps we actually use at Eclypso.
Step 1: Define the problem before touching any code
Not the app. The problem. "A booking system for a padel club" is an app. "Members cannot see court availability without phoning, and the owner pays commission on every booking made through a third-party platform" is a problem. When you can state the problem in one sentence with a number in it, you know what to build and, more importantly, what to leave out.
AI makes this step more important, not less, because AI will happily build the wrong thing at incredible speed.
Step 2: Write the spec file
This is the step almost everyone skips, and it is the one that separates a project from a prototype. Before we open an editor, we write a spec: what the system does, who uses it, every page, every data model, the stack, what is out of scope. Then that file goes to the AI as permanent context for the whole build.
Without a spec, the model guesses. It invents features, renames things halfway through, and produces a generic version of whatever you asked for. With a spec, every session starts from the same source of truth. We keep a template for this, and you can download it free and use it on your own project.
Step 3: Choose your stack deliberately
Do not let the model decide. Left alone it will reach for whatever is most common in its training data, which is how every AI-built app ends up on the same three technologies regardless of whether they fit. Pick your stack for reasons you can say out loud: we use Django and PostgreSQL for backends because the security defaults are strong and boring, and boring is what you want holding your data.
The test is simple. If you cannot explain why a technology is in your project, it should not be in your project.
Step 4: Build page by page, feature by feature
The single biggest mistake is asking for the whole app at once. You get two thousand lines that almost work, and debugging "almost" across an entire codebase is slower than building it properly would have been.
Instead: one page, review it, commit it. One feature, test it, commit it. Small pieces mean the model holds full context for the thing it is working on, and you always have a version that ran five minutes ago. This is how our whole process is structured, with working software pushed to the client at every stage rather than a big reveal at the end.
Step 5: Test, secure, deploy
This is the step that separates engineers from prompters, because it is the step AI will not do for you. Does the app survive wrong input? What happens when a payment fails halfway? Who can see whose data? At Eclypso every build ends with in-house penetration testing against the OWASP Top 10 before a client touches it, because AI-generated code fails security review in predictable ways. I wrote about the five most common failures in what AI forgets when it builds your login page.
Then deployment: containerised, repeatable, with a rollback. Not a drag-and-drop upload you cannot undo.
Where people fall off
Having watched a lot of people try this workflow, the failure points are consistent, and they are worth naming so you can catch yourself.
Skipping step two because it feels slow. Writing a spec feels like not building. Then week three arrives, the model has drifted, and you spend two days re-explaining your own project to it. The spec is not overhead. The spec is the build, compressed.
Accepting code you do not understand. If the model produces something that works and you cannot say why, you have not saved time, you have borrowed it. The day it breaks, and it will, the debt comes due with interest, at production prices.
Mistaking the demo for the product. A demo runs on the happy path with one polite user. A product survives a hostile one at two in the morning. The distance between those two is exactly steps four and five, which is why they cannot be skipped, only postponed until the worst possible moment.
Never shipping. The opposite failure. Some people spec forever. The spec should take a day, maybe two for a serious system. If it has taken a week, you are hiding in it.
The honest summary
AI has made building software faster than it has ever been. It has not made engineering optional. The five steps are the engineering: know the problem, write it down, choose deliberately, build in small verified pieces, then test and secure like someone is trying to break it, because eventually someone will.
Grab the spec template, follow the steps on your next project, and if you would rather have engineers do it with you, that is literally what we do.