// process · build log
How I Ship an AI SaaS MVP in Two Weeks
Two weeks is not a marketing number — it's what's possible when scope is ruthless, the stack is decided up front, and nobody is waiting on a design committee. Here's the exact shape of those fourteen days.
Want your idea run through this process?
Send your idea and I'll reply within 24 hours with what's buildable, how long it takes, and what it costs.
The three rules that make it possible
One workflow, one buyer. Every extra user type doubles the surface area. An MVP that finishes one job for one person beats a platform that half-finishes five.
Decide the stack before day one. No evaluations mid-build. React with server functions, Postgres with row-level security, hosted auth, and a single model provider behind one interface.
Humans approve anything that sends, signs, or spends. Approval UX removes an entire class of accuracy problems and is usually what the buyer wants anyway.
The fourteen days
Weekends included or excluded, the order never changes:
day 01
Scope to one job
We cut the idea down to a single workflow with a paying buyer at the end of it. Everything else goes on a v2 list that we do not touch for two weeks.
day 02
Data and model decisions
Where the inputs come from, what the model has to be right about, and what the fallback is when it isn't. This decides the architecture more than anything else.
day 03–04
Schema, auth, and the boring spine
Database tables, row-level security, sign-in, and roles. Done first because retrofitting auth into a working prototype is where most timelines die.
day 05–07
The core loop, end to end
Input in, model runs, human reviews, result saved. Ugly but real. By the end of week one, you can run your own workflow through the product.
day 08–09
Interface pass
The screens people actually live in: the queue, the review view, the history. Design system applied, empty and error states written.
day 10
Billing and limits
Plans, checkout, usage caps. A product that cannot take money is a demo, and demos do not get feedback that means anything.
day 11–12
Hardening
Rate limits, retries, cost ceilings on model calls, logging, and the failure paths. This is the difference between a launch and an incident.
day 13
Real-data dry run
We run your actual documents, tickets, or transcripts through it and tune prompts and thresholds against outcomes you can judge.
day 14
Ship and hand over
Custom domain, analytics, error monitoring, and a walkthrough. You own the code and the accounts on day fourteen, not day ninety.
Tell me the job you want finished
Send your idea and I'll reply within 24 hours with what's buildable, how long it takes, and what it costs.
What gets cut every single time
Admin dashboards, multi-tenant org hierarchies, custom role builders, in-app onboarding tours, white-labelling, and settings pages full of toggles nobody has asked for yet. Each one is a week, and none of them decide whether the product works.
Also cut: fine-tuning. Prompting plus retrieval plus a review step gets you to a shippable quality bar far faster, and you need production data before fine-tuning is even a sensible idea.
What happens after day fourteen
You put it in front of real users and watch where the workflow breaks. Weeks three and four are usually accuracy tuning and the two features your first users all asked for — which are almost never the ones on the original v2 list.
Two weeks from now, this could be live
Send the idea and I'll come back within 24 hours with the day-by-day plan, the timeline, and the cost.
Get a build plan →