By Nikhil Garg — ex-CTO, 13+ years building and shipping software
The $47,000 Lesson
Let me tell you about a founder I talked to last month. Call her Priya. She had a sharp idea for a compliance SaaS, real customer interviews, three LOIs in hand. She did everything right — until she hired.
She went cheap. $18/hour developer off a marketplace. Decent portfolio. Fast replies. He promised eight weeks. Four months later, she had a half-working prototype, a database that couldn't handle more than fifty users, and a repo nobody else could run. She'd burned $47,000 and her runway was bleeding.
Then she tried the opposite. She hired an agency. $60k retainer, slick deck, "senior team." They handed her back a Next.js app wrapped around a ChatGPT API call and called it AI-native. When she asked who owned the code, she got a legal email.
Priya isn't dumb. She's the norm. If you're about to build a SaaS in 2026, this is the post I wish she'd read first.
Why This Keeps Happening
Three things are quietly colliding, and founders are getting caught in the middle.
First — vetting shortcuts. You're not technical. So when a developer shows you a portfolio, you're judging the screenshots, not the architecture. You can't tell the difference between a clean codebase and a disaster held together with duct tape. Marketplaces made this worse by flattening "senior dev" into a five-star rating and a response time. The signal is gone.
Second — AI tool overconfidence. Cursor, Copilot, Claude Code, Lovable, v0 — these tools are genuinely good. So good that a junior dev can now ship something that looks production-ready in a weekend. But "looks production-ready" and "is production-ready" are different planets. The AI writes code that compiles. It doesn't write code that scales, stays secure, or survives a migration. Someone has to know the difference. If neither you nor your developer does, you're building on quicksand.
Third — agency abstraction. Agencies sell you outcomes. That sounds great until you realize the outcome they're optimizing for is the invoice getting paid, not the thing still working six months later. They hand you a black box. You can't edit it. You can't hire someone else to fix it. Every future change costs you another retainer. It's not fraud — it's just the incentive structure. And it burns founders every single month.
The 3 Questions to Ask Before Hiring Anyone
Whether it's a freelancer, an agency, or a friend-of-a-friend — ask these before you sign anything. If they can't answer clearly, walk.
1. "What's the technical debt risk of your approach?"
This is a test. Watch their face when you ask it. A good developer will light up and start talking about trade-offs — why they'd pick boring Postgres over a trendy vector DB, why they'd avoid an ORM that's going to bite you in six months, why they're not using seventeen microservices for a pre-revenue product. A bad one will say "don't worry, we use best practices." Best practices is not an answer. It's a dodge.
You don't need to understand every word. You need to hear specificity. If they're vague, they're winging it.
2. "What breaks first when I get 1,000 users?"
Every system breaks somewhere. The question is whether your developer has thought about where. A senior person will tell you: "Honestly, the background job queue will choke before the database does, so we should set up a proper worker from day one." A junior or a sloppy agency will tell you the system scales infinitely. Nothing scales infinitely. That answer means they haven't thought about it.
Bonus: ask what it would cost to fix when it does break. If they can't ballpark it, they don't know the system well enough to build it right the first time.
3. "Who owns this after you're gone?"
This is the one that saves your company. Can another developer clone the repo, run one command, and have it working locally in under an hour? Is there a README? Are the environment variables documented? Is the database schema in version control? Is the deployment a button or a tribal ritual only they know?
If the answer to any of these is "well, I'll walk them through it," you don't own your product. They do. And the day you try to part ways is the day you find out how expensive that really is. I've done AI codebase rescues for founders stuck in exactly this trap — and the cost of untangling it is always higher than doing it right the first time.
What a Good 8-Week Build Actually Looks Like
Here's the shape of a real build. Not a fantasy timeline — what actually works.
Weeks 1–2: Scope and architecture. No code yet. You sit down with your developer and map every user action, every piece of data, every third-party integration. You pick a boring, proven stack (Next.js, Postgres, a managed host — something a thousand developers know). You write down what's not in v1. That list is more important than the feature list.
Weeks 3–5: Core build. Auth, database, the two or three workflows that matter, and a dashboard. No AI bells and whistles yet. No fancy animations. Ugly but working. Deployed to a real URL by end of week 3 so you can click it every day and feel it.
Weeks 6–7: The hard parts. Payments. Permissions. The one AI feature that's actually a differentiator — not seven of them. Real error handling. Logs you can actually read when something breaks at 2am.
Week 8: Shipping prep. Onboarding flow, email sending, basic analytics, a landing page, and a closed beta with ten real users. Not a hundred. Ten. You want signal, not noise.
At the end of week 8 you should have: a working product, a repo any developer can open, a deploy that doesn't require anyone's laptop, and a beta user telling you what to fix next. If you're missing any of those four, the build wasn't good — no matter how pretty the UI is. This is the exact process I walk through in SaaS MVP development.
The 5 Free Hours — Why I Do It
Here's the thing. I've been a CTO. I've cleaned up more burned-founder codebases than I can count. And most of the time, the damage was avoidable if someone had spent ninety minutes with them before they hired.
So I offer five free hours to founders. No pitch, no retainer pressure. You bring me whatever you have — an idea, a half-built repo, a quote from an agency you're not sure about, a developer you're second-guessing. We get on a call and I give you the unvarnished read.
You get: an honest architecture review, a scope sanity-check, a stack recommendation based on your product (not my preferences), a rough cost and timeline range, and a list of the specific questions to ask any developer before you sign. If you're already in trouble, we map the cheapest path out.
Why free? Because the alternative is founders losing $50k learning the same lessons I already know. And because the work I actually want — building the right thing with the right team — only shows up when founders aren't already burned out and broke by the time they find me.
Stop Guessing. Get a Real Read.
If you're about to hire, about to sign an agency contract, or already feeling a pit in your stomach about your current build — talk to me before you spend another dollar.
Five hours, free, no strings. Just a senior engineer telling you what's actually going on.
Book a slot — send me your repo, or just email me with the question that's keeping you up at night. I read every one.
Don't be Priya. The $47k lesson is free if someone else already paid it.
