The agency says
“Your product needs a scalable architecture.”
Startup Engineering · 0 → 1
Technical judgment for non‑technical founders building AI products.
Make the technical decisions that take your startup from idea to a real, reliable product — without becoming technical yourself.
The founder's problem
You don't have a shortage of technical advice.
The freelancer says
“I can build it in six weeks.”
The AI assistant says
“Here's the recommended technology stack.”
The difficult part is knowing who is right.
Evaluating technical advice takes technical experience — exactly what a non-technical founder doesn’t have. Serious technology companies don’t let one interested party make expensive decisions unchecked; senior engineers review them first. Early-stage founders rarely have that room.
I help provide that founder-side technical judgment.
The discipline
Startup Engineering
The technical discipline of getting from 0 → 1 without letting your commitments outrun your evidence.
Traditional engineering optimizes for scale, reliability and longevity. Startup engineering has a different first priority: learn faster than you burn. Every technical choice should buy the next piece of evidence as cheaply — and as reversibly — as possible.
Principle 1
Evidence before architecture
Don't solve scaling problems before you've validated the product. Technology should buy the next piece of evidence as cheaply and reversibly as possible.
Principle 2
Stay reversible
While uncertainty is high, avoid large technical commitments. The option to change your mind is worth real money.
Principle 3
Build only what the stage has earned
A prototype, an MVP, and a scalable platform are different things. Each loop of the journey earns you the right to build the next one.
The Five Loops
Where are you right now?
Between 0 and 1 sit five loops — Problem, Solution, Product, Market, Fit. The right technical decision depends on which loop you're in.
Is the problem real and worth money?
What this stage has earned: Manual delivery
- Should software be built yet — or should the service be delivered by hand first?
- What is the riskiest technical assumption in the idea?
- Could AI make the idea obsolete before it ships?
Does this solution actually create value?
What this stage has earned: Disposable prototype
- Prototype, or a manual workflow that fakes the software?
- How real does the prototype need to be to learn anything?
- Should the AI-built prototype become the actual product?
Can strangers reliably receive the value?
What this stage has earned: Launchable MVP
- Who should build the MVP — and under what agreement?
- What goes into the MVP, and what gets cut?
- Which technical decisions actually matter at this stage?
- What must the founder own from day one?
- Is the build progressing properly?
Will customers adopt it in the real world?
What this stage has earned: Observable product
- What should be measured after launch?
- What happens when the product fails at 2 a.m.?
- What does one customer cost to serve?
Does the value repeat without founder heroics?
What this stage has earned: Repeatable system
- Is this genuine traction — or founder heroics?
- When should technical ownership move in-house?
- When should permanent engineering leadership be hired?
Common situations
Bring me the decision that's costing you sleep.
“I have three development quotes. I can't tell which is realistic.”
Vendor & proposal review
“I built a prototype using AI. Can customers actually use it?”
Prototype → product assessment
“The agency says we need microservices and Kubernetes.”
Architecture sanity check
“How much should this MVP actually cost?”
Scope & engineering assessment
“Should AI make this decision automatically?”
AI architecture & autonomy assessment
“The development team says everything is on track. How do I know?”
Build oversight
“When should I hire my first engineer or CTO?”
Technical ownership planning
How I help
Founder-side Technical Advisory.
Independent senior technical judgment when your startup doesn't yet have that capability in-house.
Product & Technical Decisions
Product scope, MVP definition, feasibility, architecture decisions, build-vs-buy, AI strategy.
Builder & Vendor Decisions
Agency evaluation, proposal review, technical interviews, quote comparison, vendor selection, acceptance criteria.
Build Oversight
Architecture review, milestone review, technical risk review, AI quality review, ownership and handover review, technical escalation.
Technical Ownership
Founder-owned cloud, code and accounts, architecture documentation, AI observability, engineering readiness, first hires, transition to an internal team.
“I don’t make more money because your build becomes bigger.”
My role is to help you make the right technical decision — including telling you when something should not be built yet. I advise; I don’t build your product, and I don’t sell implementation.
AI product engineering
AI changes how products are built. It doesn't remove the need for engineering judgment.
AI should improve your product — not be your entire moat.
Workflow, proprietary knowledge, data, customer relationships and integrations become more valuable as models improve, not less.
Rent the fast-changing layer.
Models change quickly. Avoid deep coupling to one model or vendor where you can — keep the expensive commitments where things are stable.
Earn autonomy.
AI progresses Draft → Recommend → Decide → Act. Autonomy increases only when evidence shows acceptable error rates. Start one notch more supervised than feels necessary.
Production AI is more than prompting.
Real AI products need evaluation, cost control, observability, reliability, fallbacks, data boundaries, rate-limit handling, and human supervision.
Track record
I've built startups — not just advised them.
~20 Years
Product engineering across four technology waves
₹6 Cr ARR
B2B SaaS startup built as Founder & CEO
1M
Shipments per month handled by the SaaS platform
30 Engineers
Engineering organization led
60% → 85%
Production GenAI accuracy improvement
5×
Reduction in OpenAI processing cost
I’ve worked across network infrastructure, cloud-native SaaS and production GenAI systems — and spent five years building my own B2B SaaS company from zero.
I know what engineering decisions feel like when the runway is your own.
Working principles
What I believe about 0 → 1 engineering.
- 01The cheapest code is the code you don't write yet.
- 02A working demo is not automatically a product.
- 03Build the risky part; buy the plumbing.
- 04Choose boring technology unless novelty buys a real advantage.
- 05The founder should own the keys from day one.
- 06Evidence beats technical vocabulary.
- 07Start AI one notch more supervised than you think it needs to be.
The book
Startup Engineering for Non-Technical Founders.
Make the technical decisions that take your idea from 0 to 1.
A practical guide for founders who need to get a technology product built but cannot build it themselves. The book walks the five loops — Problem → Solution → Product → Market → Fit — one real technical decision at a time.
Writing
Technical decisions explained for founders.
Problem loop
Should I build an MVP yet?
The evidence you need before writing the first serious line of code — and the cheaper experiments that come first.
Coming soon
Solution loop
Prototype vs MVP — what's the difference?
A prototype answers a question. An MVP serves a stranger. Confusing the two is one of the most expensive mistakes a founder can make.
Coming soon
Product loop
How much should an MVP actually cost?
Why quotes for the same product range from ₹5 lakh to ₹50 lakh — and how to tell which one is realistic.
Coming soon
Product loop
How do I evaluate a software development agency?
The questions that separate a capable build partner from a proposal that will outrun your runway.
Coming soon
What technical decision are you trying to make?
Bring the decision, proposal, prototype or architecture you’re uncertain about. We’ll start there.