By Nikhil Garg — ex-CTO, 13+ years building and shipping software
I offer founders five free hours of real coding before anyone pays me a dollar. Not a discovery call. Not a "free consultation" that's secretly a sales pitch. Five actual hours where I get into your code, your architecture, or your idea, and do real work.
People ask me why. Here's the honest answer — and exactly what happens when you take me up on it.
The honest reason I do it
I'll be straight with you: the five free hours are a filter as much as they're a gift.
Most founders who reach out aren't sure they trust me yet. Fair. They've been burned by a cheap dev, an agency black box, or an AI tool that shipped something that looked done and wasn't. A pitch deck won't fix that distrust. Doing the actual work in front of them does. After five hours, they've seen how I think, how I write, and whether I'm honest when something's broken. That's trust you can't fake on a sales call.
But it cuts both ways. Those five hours tell me whether we should work together. I find out fast if a founder argues with every recommendation, has no decision-making authority, or wants me to rubber-stamp a bad plan. Some people are a bad fit, and five hours surfaces that before either of us is locked into a contract neither of us wants.
So it's not charity. It's the cheapest way for both of us to find out if this is real — before money, contracts, or pressure distort the picture.
What actually happens during the 5 hours
This isn't me nodding on a Zoom call. It's hands-on work, and it goes one of two directions depending on where you are.
If you already have a codebase, I do a real audit. I clone the repo, run it, and read it the way the next engineer who inherits it will. I look at the architecture, the database schema, the auth, the parts held together with duct tape. I'm not skimming — I'm finding the things that will cost you money later. This is the same work I do in a full SaaS rescue, just compressed into the highest-signal hours.
If you're starting fresh, I do an architecture review instead. We map every user action, every piece of data, every integration. I recommend a stack based on your product — not my favorite tools — the same way I'd scope a 30-day MVP.
Either way, three things come out of it:
- Risk identification. What will break first when you get a thousand users. What's over-engineered for a pre-revenue product. What's missing entirely — usually error handling, logging, or a sane deploy.
- A prioritized action plan. Not a wish list. The specific things to build first, in order, with the reasoning for why each one comes before the next.
- A written document at the end. Plain language, not a pitch deck. Findings, risks, recommendations, rough cost and timeline ranges. Something you can hand to any other developer and they'll understand it.
You leave with work product, not a sales follow-up.
What you walk away with
Here's the part that matters: even if we never work together after this, you keep everything.
You walk away with a clear-eyed read on your actual situation. If your current build is fine, I tell you it's fine — I'm not going to invent problems to win a contract. If it's a disaster, you find out now, while it's still cheap to fix, instead of six months and $50k from now.
You get the written document. That alone is worth more than most paid consultations, because it's specific to your code and your product, not generic advice. You can take it to another developer, a co-founder, or an investor and it holds up.
You get a stack and architecture recommendation you can act on immediately, whether I build it or someone else does. And you get the list of exact questions to ask any developer before you sign with them — the kind of questions I cover in hiring your first developer.
Most importantly, you get certainty. You stop guessing about whether your technical foundation is solid. That clarity is the whole point.
What makes someone a bad fit
I'll be honest, because the offer isn't for everyone.
You're a bad fit if you want someone to validate a decision you've already made and won't revisit. I'm going to tell you the truth, and if the truth is "this stack is wrong" and you don't want to hear it, we'll both waste the five hours.
You're a bad fit if you can't make decisions — if every recommendation has to go through three other people who aren't in the room. The five hours work when the person I'm talking to can act on what we find.
And you're a bad fit if you're shopping purely on price and plan to take my document straight to the cheapest dev you can find. That's your right, but it's not why I do this. I do it to find founders who want the thing built right — the kind who understand why a CTO who actually writes code matters.
How to book it
If you've got a repo you're worried about, a quote from an agency you're not sure about, or just an idea and a pit in your stomach — that's exactly who this is for.
Go to nikhilgarg510.com, book a slot, and send me whatever you have. The repo, the agency contract, the half-finished Figma — anything. I'll come in having already looked at it.
Five hours. Free. No retainer pressure, no obligation to continue. Just a senior engineer doing real work and telling you the truth about where you stand. The worst case is you walk away with a document worth more than most people charge for. Book it.
