Most people using AI to build things run the same broken loop. Paste a wall of text describing what you want, hit enter, pray, then fix what comes out, then fix the fix. I ran that loop for two years. It works, eventually, and about half the time it produces a clean, functional product that nobody wanted. The problem was never that I can't code. The problem was that I was building before I'd done any of the work that tells you what to build.
Here's my proof. My first product, Split-Test-O-Matic, I built by hand with ChatGPT back on GPT-3.5, when the model was really stupid. The MVP took two days, which was fast for what it was. Perfecting it took over a year of grinding, one prompt at a time. Today, with the exact system below, I'd rebuild STOM in an afternoon or less. Same product. The only thing that changed is the order I work in.
So I reverse-engineered my own good builds and found there was an order underneath them. Here it is, in the sequence I actually run it.
Before any research, I write down the specific thing that would make me abandon the idea. A good-enough free competitor already exists. No evidence anyone spends money on this. A maintenance load one person can't carry. I write it first, on purpose.
I have the AI go read what real people say about the problem, in their own words, off real forums and reviews. It builds a set of personas out of that reading and runs the idea past a simulated audience. Then a separate step, a different model with one job, tries to kill the idea. Not to be nice. To find the reason it's a bad plan. The output is exactly one of three verdicts:
The build runs in phases, and every phase writes down where it is. On one app that was 16 phases and north of 260 saved checkpoints, each one a step I could undo. This sounds like bookkeeping. It's the difference between a hobby and a system. I do this between everything else going on and two kids with one on the way, so I will close the laptop for three days, and the project has to remember where it was so I don't lose ten minutes every restart. The copy gets written here too, as part of the build, because on most software the words are half the product.
Simulated users run the core tasks over and over, and I score each round. I push until it hits a nine out of ten, with a blind user in the test every single round, because my wife is blind and if she can't use it, it isn't done. One app took five rounds to climb from a four to a nine.
No simulated user can feel glare on a screen, gloves on hands, or a GPS drifting. So I take the thing out and use it on the real task, and I write down every annoyance as a punch list. Then I fix the list, one item at a time, and go back out to confirm.
If it was a build-for-yourself, I install it into daily life and stop. If it was a build-for-market, it goes to launch. Either way, the run writes down what the process itself got wrong, so the next build starts smarter. A run that doesn't teach the system anything is a wasted run.
You could skip half of the above and still win if you nail these two.
Move one: build the AI that tells you no. Everyone has a tool that will build anything they ask. Almost nobody has one that will look at the ask and say "this already exists for free, don't waste your month." I built that refusal directly into the process, and it has saved me from myself more than once. One honest "don't" is worth more than any feature.
Move two: build the thing they didn't ask for. After the research comes back, I re-read what people actually said and pull out what they need but would never file as a request. On a tracker I built, people were quietly nervous about privacy, so "your data never leaves your computer" became a real, built feature. On a navigation app, nobody asked for automatic pace counting or hazard warnings, but a soldier in the field needs them, so in they went. That second layer is what makes a tool feel like it gets you, and you only find it by listening before you build.
The cleanest test of the whole system: I took a photo of a page from an Army land-navigation field manual, fed it in as the single source of truth, and ran it through every stage above. Synthetic review board, five usability rounds, a real field test against a real map. I had a working, field-accurate navigation app by the end of a lunch break, from my phone. It's live at deadreckon.adamgarceau.com.
You don't need to become an engineer. You need the order of operations and a sense of how much the machine can carry before the building even starts. Read what real people say. Ask the fake customers. Let something honest try to kill the idea. Then build, then hand it to real people. I put the exact order into Forge and open-sourced the whole thing. It's free. Clone it, run it on your next idea, and let it try to talk you out of it.
I send what I'm building, what worked, and what broke. Free, no fluff.
Free. Unsubscribe anytime.I'm a marketer who builds his own tools. More at adamgarceau.com.