By Nikhil Garg — ex-CTO, 13+ years building and shipping software
Why 8 Weeks Is the Right Target
Eight weeks is not a marketing number. It's the longest a non-technical founder can stay focused on one build before the wheels start coming off — runway tightens, an investor wants an update, a competitor announces something, you start doubting the idea. It's also the shortest realistic timeline for a real SaaS — auth, payments, a working product, a deploy that doesn't depend on someone's laptop. Faster than 8 weeks and you're shipping a Lovable demo with a polished name. Slower than 8 weeks and you're drifting; week 12 looks the same as week 9, and week 16 looks the same as week 12. The constraint is what makes the work honest. You decide what's in. You decide what's cut. You ship it. Then you find out if you were right. (For why this window exists now and didn't five years ago, see how AI changed the math.)
The Week-by-Week Build
Week 1 — Discovery and Architecture
No code. This is the most expensive week to skip and the cheapest week to get right. We map every user action end to end — signup, login, the three workflows that matter, the dashboard, the billing path. We list every external integration (payments, email, the AI API, anything regulated). We pick the stack: I default to Next.js + Postgres + a managed host because it's boring, fast, and a thousand other engineers can pick it up if I get hit by a bus. We write down what's not in v1 — the kill list is more important than the feature list. By Friday, you should be able to describe the product to a stranger in three sentences. What goes wrong here: founder wants to keep "thinking about" the spec. We ship it Friday or we lose the week. Decisions made in week 1 about the five decisions that haunt every startup are also where most of the future pain is bought or avoided.
Week 2 — Environments, Auth, Schema
Three things stand up: a dev environment that runs with one command, an auth system that works (signup, login, password reset, session expiry, rate limiting on login — all of it, not the AI-tool version), and a database schema with the right indexes from day one. By Friday there's a deployed URL on a staging environment, and you can sign up, log in, and see an empty dashboard. It feels like nothing. It's actually 40% of the work. What goes wrong here: treating auth as a checkbox. Half the production breaches I've seen come from auth that "worked" — until someone changed a URL parameter and saw another user's data.
Weeks 3–4 — Core Feature Build
The two or three workflows that are the product. Not the dashboard charts. Not the settings page. The actual thing the user signed up to do. We build the ugliest possible version that works end to end and deploy it to staging by end of week 3. Week 4 is where it gets shaped — error handling, edge cases, the "what happens when…" questions. By Friday of week 4, ten of your friends should be able to use the core flow without you on the call. What goes wrong here: scope creep. Every "while you're in there, can you also…" pushes the ship date by a week. The right answer is "yes, week 9." Most of the time week 9 means never, and that's fine.
Weeks 5–6 — Secondary Features, Integrations, Payments
The supporting cast. Settings, profile, search, the second workflow if there is one, email notifications, and — usually the biggest single chunk — payments. Stripe, plans, webhooks, the failure modes (card declined, subscription cancelled mid-period, refund). Payments take longer than you think, every single time. By Friday of week 6, the product is feature-complete on staging. Not pretty yet. Not fully tested. But everything you said you'd ship is shipping. What goes wrong here: Stripe webhooks. They fail silently, retries are async, your local environment doesn't see them without ngrok, and the first time a subscription doesn't cancel correctly is when a customer emails asking for a refund.
Week 7 — QA, Bugs, Performance
The week the founder usually wants to skip. Don't. We seed the database with 10,000 realistic rows and click through every page. Anything that loads in over two seconds gets an index or a query rewrite. Every form gets a malformed-input test. Every API endpoint gets an authorization test (logged in as user A, try to read user B's data — should fail). Error tracking goes in (Sentry), logs go to a real service, basic uptime monitoring gets configured. What goes wrong here: "we'll fix it in production." You won't. Production bugs cost ten times what staging bugs cost — in user trust if not in dev hours.
Week 8 — Production, Monitoring, Launch
Production environment stands up — real domain, real database with backups, real secrets in a vault, not in source. We deploy from staging once, watch it for a day, and migrate any beta users. The launch checklist runs: SSL valid, sitemap submitted, robots.txt sane, transactional emails landing in inboxes (not spam), Stripe in live mode, error alerts wired to your phone. Then a quiet beta — ten users, not a hundred. You want signal, not noise. By Friday, you have a working product, a repo any senior engineer could pick up tomorrow, and the first real users telling you what's wrong with it. What goes wrong here: the founder wants to launch on Product Hunt the same day. Don't. Soft launch first. Find the embarrassing bug at ten users, not a thousand.
What Pushes This Past 8 Weeks
Four reasons, in order of frequency. One — undecided scope. "Can we also add…" said three times across three weeks adds three weeks. Two — the founder is unavailable. Decisions queue up; I send a Slack on Tuesday, hear back Friday, the week is gone. A lot of what nobody tells founders about hiring developers is really about how the founder shows up — your decision velocity is the project's velocity. Three — a "small" integration that isn't. Stripe Connect instead of Stripe Checkout. SAML SSO instead of email login. CRM sync instead of a CSV export. Each of these is a two-week project pretending to be a Tuesday. Four — the AI feature gets greedy. One AI workflow shipped well beats four shipped poorly. Founders who try to ship four end up with zero.
What I Need From You to Hit 8 Weeks
Five things, non-negotiable. One — a 24-hour decision SLA. I send a question Monday, you answer by Tuesday. Async is fine. Silent is not. Two — a single source of truth for scope. One doc, one Loom, anything — but only one. Three — access from day one to whatever third parties matter (Stripe, SendGrid, the domain registrar). Founders who promise to "set that up later" lose week 8 to it. Four — protect 30 minutes a day. Not an hour. Thirty minutes, every weekday, for review and decisions. Five — don't ship to your investors before week 6. Premature demos generate premature feedback that breaks the plan.
What I'd Do If I Were You
If you have a clear product in your head, eight weeks is enough. If you don't have one, no amount of engineering compresses that — pay for a product manager or do twenty more customer interviews first. The build isn't the bottleneck; the clarity is. If you've got the clarity and want to put a real engineer on it, I run two of these at a time and the slots open about every six weeks. Bring your scope doc, your kill list, and your calendar. We'll know in a thirty-minute call whether eight weeks is realistic for what you're trying to build, or whether it's a twelve-week problem someone's mis-priced for you. Either way you'll get an honest answer.
You can find me at nikhilgarg510.com.
