// guide · founders
How to Build AI Software: A Step-by-Step Guide for Non-Technical Founders
You don't need to learn to code to get AI software built — but you do need to make about nine decisions correctly. This is the sequence I use with founders, in plain English, with the traps marked.
Want this done for you?
Send your idea and I'll reply within 24 hours with what's buildable, how long it takes, and what it costs.
Before anything technical
Most failed AI builds fail before the build. The founder picks a capability ("summarise documents") rather than an outcome ("cut claims triage from two days to two hours"). Capabilities are impossible to price and impossible to finish. Outcomes have a finish line.
So the first work is not choosing a model or a framework. It's getting specific enough that someone could tell you the thing is done.
The nine steps
Work them in order — skipping ahead is what causes rebuilds:
01
Write the problem as one sentence
"X person wastes Y hours doing Z." If you can't fill that in with a real person you've spoken to, you don't have a product yet — you have a technology you like. Start with the hour being wasted.
02
Decide what 'good' looks like before you build
Collect ten real examples of the input and write the answer you'd accept for each. That set becomes your test. Without it, every change is a vibe and you'll never know if you're improving.
03
Do it manually first
Run the workflow by hand for three customers. It's slow and it's the cheapest research you'll ever do — you'll find that half the AI you planned isn't needed and the part you skipped is the whole product.
04
Build the thinnest possible version
One input, one output, one screen. No settings, no dashboard, no accounts if you can avoid it. The goal is a link you can send someone, not a platform.
05
Choose boring infrastructure
A hosted database, a hosted auth provider, and a mainstream model API. Novel infrastructure adds risk without adding value at this stage, and it's the first thing that stalls a launch.
06
Design for being wrong
Show confidence, allow edits, keep an undo, and put a human in the loop on anything with money or legal consequences. Users forgive a wrong answer they can correct; they don't forgive one they can't see.
07
Meter the expensive parts
Cap document size, cap retries, cache repeated work, and track cost per user from day one. AI features are the rare kind where your heaviest users can make you lose money.
08
Put it in front of ten real people
Not friends. Ten people with the problem. Watch them use it without instructions. Everything confusing in that session is your roadmap for the next two weeks.
09
Charge before you're ready
Price it, put a payment link on it, and see who pays. Revenue is the only reliable signal that the problem was real. Free users will tell you it's great and never come back.
Tell me your one-sentence problem
Send your idea and I'll reply within 24 hours with what's buildable, how long it takes, and what it costs.
What it costs and how long it takes
A focused first version — one workflow, real data, live on the internet, able to take payment — is typically two to four weeks and lands in the low five figures. Anything quoted at six months before a single user has touched it is scoped wrong, not scoped ambitiously.
Ongoing, budget for model usage (usually small at first), hosting, and a monthly block of time for fixes and improvements. The build is the cheap part; the year after launch is where products are won.
How to hire for it without being technical
Ask for a live link to something they shipped, not a portfolio of screenshots. Ask what they'd cut from your idea — a good builder always cuts something. Ask who owns the code and the accounts (you should). And insist on a fixed first milestone with a date, so you find out quickly whether the working relationship works.
Get a build plan for your idea
Send me the one-sentence version of your problem. I'll reply within 24 hours with scope, timeline, and cost — or tell you honestly if AI isn't the right fit.
Get a build plan →