Most MVPs fail because they're too ambitious, not too modest. The whole point of an MVP is to test your riskiest assumption, not to build a small version of your final product.
When to Hire and When to Stay Small
The right time to hire is when a specific, ongoing need consistently bottlenecks the team, not when revenue lets you. A lot of startups hire to performatively feel like companies. That's how you burn cash fast.
The useful question is "what would this person actually do for the first 90 days, and would it clearly pay back their salary?" If you can't answer crisply, don't hire yet. Keep looking for better leverage.
Common Pre-PMF Mistakes
A short list of things we see often. Raising more than needed and getting burn inertia. Hiring senior people too early into ambiguous roles. Choosing vendors that don't match your stage. Optimising for scale before you've found PMF. Every one of these feels justified in the moment. Most of them kill startups that would otherwise have worked.
The pattern we see in healthy early-stage companies is the opposite: under-hire, under-spend, iterate close to the work, and resist the urge to look like a company before you are one.
Where Founder Time Should Actually Go
The highest-leverage thing a founder can do in the first year is talk to customers. More than build, more than fundraise, more than strategy. Every founder we've worked with who got this right ended up with clearer product, faster PMF, and better narrative for investors. The ones who didn't ended up rebuilding based on guesses.
If you're spending more than 60% of your time not talking to users, that's a flag. Re-arrange the schedule until you are.
What Year Two Actually Looks Like
Year one is scrappy and exciting. Year two is where most startups either establish or lose their momentum, and the transition is harder than people expect. The urgency that got you through year one becomes dysfunction. The founders who personally owned every decision become the bottleneck. The flexible processes start breaking.
The companies that navigate year two well start delegating specific outcomes, not just tasks. They invest in systems that let the team operate without founder approval for every decision. They fire cheerfully when they realise they've made the wrong hire. None of these decisions are technical. All of them affect whether the company survives to year three. Related read: our post on SaaS development guide covers the flip side of this.
The Early-Stage Reality
Early-stage is different. Every rule you've learned at bigger companies needs to be filtered through the question "does this help us learn faster?" Most best practices assume a level of resource and stability that doesn't exist when you're six people and fourteen months of runway.
That doesn't mean "move fast and break things". It means picking which best practices are load-bearing for a small team and which are premature. Clean code is load-bearing. Comprehensive testing infrastructure usually isn't, at seed stage. Good judgement is the rare skill.
The Tech Stack for a New Startup
For a typical web SaaS or D2C product starting today, a reasonable stack is: Next.js or Remix on the frontend, Supabase or Postgres on the backend, Stripe or Razorpay for payments, Vercel for hosting, Resend or Postmark for email, PostHog or Mixpanel for analytics. This will scale from zero to several million in revenue without major rework.
The temptation to over-engineer from day one is strong, especially for technical founders. Resist it. The company you'll be in three years doesn't exist yet. Build for the company you are.
The Strategic Questions Worth Thinking About Annually
Once a year, we recommend every founder we work with ask three questions honestly. What would have to be true for this company to be 10x the size in five years? Are we on a path that makes those things true? If not, what are we actually optimising for?
These aren't planning questions. They're reality-check questions. A surprising number of startups are quietly operating in ways that make the ambitious outcome impossible, without anyone having consciously decided to downshift. The annual check forces the conversation onto the table.
The Early-Stage Climate in India
The funding environment for Indian startups has shifted several times in the last few years. What was an easy fundraising climate in 2021 tightened significantly in 2023 and has been more measured since. Founders starting today face a market that rewards capital efficiency and clear revenue models over vanity metrics.
That's actually good news for most founders. Raising less and building slower produces stronger companies. The unicorns that survived the correction are the ones that had real businesses underneath the narrative. The ones that didn't are cautionary tales for the next generation.
For founders starting in 2026, our advice is the same as always: build something people want, charge for it, keep burn sustainable, and don't raise money you don't need. Focus on customers, not press. Measure retention before scale. None of this advice is new. It remains right.
Things First-Time Founders Commonly Get Wrong
One: 'we need to raise before we can really build'. False for most companies. Starting with real revenue (pre-orders, paid pilots, low-budget MVPs) puts you in a stronger fundraising position than starting with a deck.
Two: 'we're behind schedule, we need to hire faster'. Usually the wrong solution. Hiring to solve scheduling problems creates new coordination overhead that slows things further. Look for the actual bottleneck before hiring.
Three: 'this customer feedback doesn't apply to us'. Sometimes true, often false. If five customers are telling you the same thing, it's signal. Dismissing consistent feedback because it doesn't match your vision is how promising companies lose their way.
A Founder We Worked With
A founder we worked with in 2024-2025 built a niche B2B SaaS serving fintech compliance teams. She had the insight, the network, and about eighteen months of runway. What she didn't have was technical co-founding experience, which often means over-engineering the MVP.
The conversation we had in kickoff was about scope. She wanted to ship everything her target customers mentioned. We pushed to test one hypothesis first: that a specific monthly audit trail would be purchased by at least five customers at her target price. Everything else got deferred.
The focused MVP launched in 11 weeks. Seven customers signed up in the first two months. Real revenue, real feedback, real PMF signals. The features she'd wanted to launch with would have taken seven months and probably would have gotten cut anyway based on what users actually asked for. The discipline paid off.
The Short Checklist
If you take nothing else from this post, take this checklist. It's what we'd hand to someone just starting out in this area. None of it is revolutionary. All of it is worth doing. The compound effect of consistently doing these things, even without any other clever moves, is meaningful over a year or two. We'd rather see a team do the checklist competently than chase the latest trend while skipping the fundamentals.
- Talk to customers weekly. Not "meetings". Actual conversations about their problems.
- Track one metric that proxies PMF. Revenue, retention, usage frequency. Pick one and watch it.
- Hire slowly in year one. Most regrets are about hiring, not about not hiring.
- Keep six months of runway minimum. Fundraising always takes longer than you think.
- Write things down. Founder memory is unreliable at stress.
- Celebrate small wins publicly. It compounds team morale.
- Write down your core hypothesis. Review it monthly against what you're actually learning.
- Keep founder payroll modest. Your salary is runway, and runway is everything at early stage.
- Say no to customers asking for features that don't fit your focus. Saying yes to everything kills focus.
- Celebrate small wins. Early-stage morale compounds.
We've watched enough teams succeed and fail at this over the years that the pattern's pretty clear. The winners aren't necessarily the smartest or the fastest. They're the most disciplined, the most honest about what they don't know, and the most willing to course-correct when the data tells them to. If you can do those three things consistently, you'll end up ahead of most of your competition. Not all of it — luck is real — but most of it. The final thing we'd say: don't try to do everything in this post at once. Pick the one or two items that clearly apply to your situation, commit to doing them properly, and leave the rest for later. Better to do a few things well than many things poorly.
Thanks for reading all the way to the end. If this was useful, the next most useful thing is usually to pick one concrete action from it and actually do it this week. Insight without action is just entertainment, and we suspect you've got better things to do than be entertained by a technology blog.
Frequently Asked Questions
What's the single biggest mistake first-time founders make with MVPs?
Building too much. The MVP should test your single riskiest assumption, not be a small version of the final product. Most first MVPs have five features when they should have two. The extra three features delay launch, consume budget, and often don't match what users actually want once the core is validated.
How much should an MVP actually cost in India?
Rs 3-15 lakh is the realistic range. Below that, you're getting a no-code prototype or a template shell. Above that, you're probably overbuilding. If an agency quotes you Rs 50 lakh for an MVP, it's not an MVP — it's a first product. Price discipline is part of MVP discipline.
Should I use no-code tools for my MVP?
Depends on what you're testing. If the core hypothesis is about market demand, user behavior, or pricing, no-code tools like Glide, Adalo, or Bubble can validate cheaply. If the product IS the technology (AI models, complex algorithms, deep integrations), you need real code from day one.
When should I hire developers vs use an agency for my MVP?
For the first MVP, an agency is usually faster and lower-risk. You get experienced engineers, project management, and QA without recruiting overhead. Transition to in-house hiring once you have product-market fit and need long-term ownership of the codebase.
Need help with your project?
Orange Essence Technologies builds e-commerce, software, mobile apps and AI solutions for clients across India and around the world. If any of this is relevant to what you're working on, we'd love to chat.
Get in touch →