What no one tells you about building your first SaaS.

We have built three SaaS MVPs in the last two years — one for a client in HR tech, one for logistics, and one internal tool that we eventually productised. None of them went the way we expected. All three taught us things we wish someone had said out loud before we started.

This is the unfiltered version.

It will take twice as long as you think

Not because developers are slow. Because the scope you think is an MVP is not actually an MVP. It is a version-two product with version-one ambitions.

The real MVP question is: what is the single workflow a user needs to complete to get value? Not five workflows. Not a dashboard. Not settings. One thing. If you can deploy something that does one thing well, you have an MVP.

Every feature you add before launch is a bet that it will increase activation, made before you have any activation data. Most of those bets lose.

Distribution is harder than building

This is the thing nobody says clearly enough. Building the product is the tractable problem. You write code, you test it, you ship it. Distribution is the intractable problem that kills most SaaS companies quietly.

Before you write a line of code, you should know: how will the first 100 users find you? Not the first 10,000 — the first 100. If the answer is vague, the product will sit uninstalled.

The founders who succeed at SaaS almost always have one of three things before they launch: an existing audience, a direct sales motion they are willing to do personally, or a very specific community they are already part of and trusted in.

Churn will tell you everything your users will not

Users who cancel rarely tell you why. They just leave. And the natural response is to assume they left because of missing features. Usually that is not why.

In our experience, the top three churn drivers in early SaaS are:

• Activation failure — the user signed up but never actually completed a valuable action
• Poor fit — they signed up for a use case the product was not really built for
• Habit failure — the product requires a behaviour change they were not ready to make

Features almost never fix these. Better onboarding, narrower ICP, and a more opinionated workflow fix these.

Price higher than feels comfortable

The SaaS pricing mistake almost every founder makes: pricing based on what feels fair rather than what the outcome is worth. If your tool saves a finance team four hours a week, and that team's time is worth ₹2,000 an hour, the value is ₹8,000 a week. Charging ₹499 a month is not modest — it signals that you do not believe in your own product.

Low prices attract users who are price-sensitive, not value-sensitive. Those users churn the moment a cheaper alternative appears. High prices attract users who care about outcomes. They give better feedback, stay longer, and refer others.

We have seen founders 3x their price and watch churn drop. Every time it surprises them. It should not.

Your tech stack matters less than you think

The framework debate is a distraction. Rails, Next.js, Django, Laravel — all of them can power a successful SaaS. The question is not which stack is best. The question is which stack your team can move fastest with, debug most confidently, and hire for most easily.

We default to Next.js with a Postgres database and keep infrastructure as boring as possible until scale demands otherwise. Boring technology lets you focus on the product problems instead of the infrastructure problems.

The one thing we would change

Talk to users before you build anything. Not to validate your idea — founders are notoriously bad at hearing "no" as validation data. Talk to them to understand the current workflow in exhausting detail. Where does it break down? What do they hate? What have they tried that did not work?

The answer is almost never what you expected. And the product you build from that understanding is almost always better than the one you had in your head.

---

Building a SaaS and need a technical partner? Let's talk.