TL;DR: Most Indian SMEs abandon SaaS not because the product is bad, but because per-user-per-month pricing compounds faster than the visible value. The 22% who stay aren't loyal. They're paying three times more for the same outcome. The fix is a build-vs-buy framework that converts software from a recurring P&L hit into a balance-sheet asset.

Key Takeaways: - The 78% churn number masks a cost-structure problem, not a product-quality problem - Per-seat SaaS pricing compounds faster than most SMEs can negotiate down - Custom software built for core workflows delivers lower total cost over five years than stacked subscriptions because the marginal cost of additional users approaches zero - Phased MVP delivery, not big-bang builds, is what separates a software asset from a sunk cost

Your finance team signed a SaaS renewal last quarter without scrutinizing the per-seat math. So did 78% of Indian SMEs. They walked away next. The 22% who stayed aren't loyal customers. They're the ones paying three times more to do the same work. Nobody ran the real cost math.

The dominant narrative says Indian buyers don't pay for software. That's lazy. The truth is more uncomfortable.

Reddit threads about Indian SaaS reluctance surface a pattern. Buyers will pay for convenience, but only when the per-month value is visible and proportionate. The moment the renewal arrives and no one can defend the line item, the tool gets cut. This isn't price sensitivity. It's a missing feedback loop between spend and outcome.

Here's the macro signal that should worry every CFO. India's SaaS market is projected to reach $50 billion by 2030. In 2021 alone, $4.8 billion poured into Indian SaaS companies. That's a flood of new tools, vendors, and per-seat pricing models chasing the same SME wallet. Yet SME churn remains stubbornly high.

The 78% who quit didn't reject software. They rejected a pricing model that punished them for growing. Every new hire, every new branch, every new user added a line item to a subscription that was never designed to scale with them. The SaaS industry calls this expansion revenue. Indian SMEs call it a trap.

The 22% who stayed aren't winning either. They're locked into overlapping tools, each with its own renewal cycle, each increasing in cost as headcount grows. Their loyalty looks like discipline, but the math tells a different story.

The question isn't which SaaS to pick next. It's whether the custom software cost of owning your workflows might be the cheaper path over a five-year horizon.

The 22% who stay are stacking tools. A CRM here. An ERP add-on there. A workflow automation layer on top. A reporting dashboard bolted to all of it. Each one carries its own per-user-per-month tax.

The per-seat multiplication trap is the silent killer. Per-user-per-month pricing multiplies across seats, tools, and months. What looks like a small line item turns into a major expense.

Most mid-sized Indian SMEs run multiple overlapping SaaS products. Each carries its own per-seat tax. The total annual SaaS bill for a 50-person company scales with every new hire and every new tool. Finance rarely aggregates the subscriptions.

Finance sees line items. Operations sees a mess.

The obvious fix almost always fails. Swap one SaaS for a better one. Integration debt compounds with every replacement. The new vendor needs API connections to the tools you kept. Data migration eats weeks of engineering time. Retraining drags down productivity. The new tool has its own limitations, which is why you switched to it in the first place.

There's a FinOps angle most procurement teams miss. Bought software has excellent line-item visibility. The bill shows up in the expense feed, and the renewal calendar pings you well in advance. Finance can flag the spend.

That's the good news. The bad news is that total cost of ownership stays hidden. No one aggregates it. The CRM renewal gets reviewed. The automation tool's renewal gets reviewed. Nobody adds them up to ask whether subscriptions cost more than salaries for the team using them.

If the answer is yes, the problem isn't vendor selection. It's a category error. Software that runs a core workflow shouldn't compete with rent and payroll. It should be a capital asset you own and amortise, because the alternative is renting a tool forever while your margins shrink with every renewal.

Custom software development flips the cost structure. The build is a one-time hit, enhancements are scoped, and users are free. Over five years, the TCO math changes completely.

But that math only works if you build the right thing. Which is why the next question matters more than the build-or-buy label.

Walk through a realistic TCO comparison. A mid-sized Indian SME spending on stacked SaaS subscriptions pays that annual amount every year for five years. The full recurring cost accumulates with nothing owned at the end. The vendor owns the code, the roadmap, the pricing, and the terms of renewal.

Contrast that with building a focused MVP for one critical workflow. The scoped build is a one-time investment. The marginal cost of each additional feature drops as the architecture and data model mature. By year three, adding a new report or new integration costs a fraction of the SaaS equivalent's seat upgrade or module add-on.

Here's the paradox. Built software's cost is harder to see. It scatters across cloud bills, headcount allocation, and maintenance sprints, but it's easier to control.

Bought software's cost is easy to see but hard to reduce. The subscription is fixed, predictable, and compounds. There's no negotiation leverage after year two because switching costs are already too high.

This is the FinOps insight most SMEs miss. Transparency without control is just visibility into your own margin compression.

The teams that get this right end up with systems still running in production half a decade after deployment, paid off long ago, generating value that compounds. The teams that get it wrong churn through vendors repeatedly and never build anything that survives a leadership change.

Cost alone doesn't close the argument. The 22% who stayed might be making the right call. If their software is a commodity function nobody cares about, staying is fine. So the real question is: when does custom actually beat the subscription?

Most build-vs-buy advice is generic. It tells you to evaluate your needs or consider total cost of ownership.

That's not a framework. It's a homework assignment.

A three-rule test that actually produces a decision: - Build when the software is a competitive differentiator (your pricing model, your routing logic, your customer experience); when no mature vendor covers your workflow (India-specific distributor networks, multi-branch reconciliation, regulatory logic vendors consistently miss); and when you have multi-year commitment to maintain it. The build is the easy part. The upkeep is what kills projects. - Buy when the function is commodity (email, basic accounting, generic HR, file storage); when time-to-value matters more than perfect fit; and when a credible vendor already solves 80%+ of the need out of the box. - Buy and extend when you need most of a product but not all of it; when the vendor's core is solid but the layer that matters to you is missing; and when you're willing to license the platform and build the proprietary glue on top.

The India-specific context matters. Vendor coverage for Indian regulatory workflows, distributor management, multi-branch operations, and compliance logic is thin. Most SaaS tools were built for the US market and adapted poorly.

If your business runs on workflows that no global vendor has bothered to localise, building isn't optional. It's the only path.

Teams that follow this discipline ship bespoke software that runs for years, not months. The pattern is consistent across regulated industries and Fortune 500 deployments. The systems that survived a decade were the ones where the framework rejected the projects that should never have been built.

If the framework points toward building, the next question isn't who to hire. It's how to do it without the cost overruns that have killed most in-house software projects, and which delivery model keeps the project alive after the launch.

Most custom software failures aren't technical. They're scoping failures. Teams try to replace the entire SaaS stack on day one. They run out of budget by month four. They ship a half-built system nobody trusts.

The phased approach has four steps. - Step 1: Scope to one workflow. Pick the one that hurts most. The one where the SaaS bill is largest, the vendor's limitations are sharpest, or the competitive gap is widest. Ship a focused MVP that solves that workflow and nothing else. Trying to build a full ERP replacement as your first build is the 40-user wall problem dressed up as ambition. - Step 2: Define kill criteria before writing code. If the MVP doesn't reduce your software spend by 40% within 12 months, you stop and reassess. This isn't optional. Without kill criteria, sunk-cost logic takes over and you end up funding a project that should have been cut. - Step 3: Architect for extensibility from day one. Microservices. Clean API boundaries. A backend that integrates with existing tools rather than replaces them. The goal isn't to rip out Salesforce on day one. It's to own the workflow that matters while the rest of your stack keeps running. - Step 4: Budget realistically for the full MVP cost. Most SMEs underestimate the 18-24 month enhancement budget after initial launch. The initial build quote is the down payment, not the total. Plan for the MVP build plus two years of iterative enhancement at two to three times the initial build cost. Anything less and you're planning for failure.

Teams that follow this discipline end up with systems still running in production half a decade later. Teams that skip it end up with abandoned codebases and a return to SaaS. This time with trust issues and a burned budget.

What changes when the math finally starts working in your favor?

Year one to two is the hardest stretch. Upfront spend is higher, and the software isn't an asset yet. It's a project. The P&L takes the hit, and finance will ask questions the build team can't answer.

Year three to five is where ownership pays off. The marginal cost of a new feature drops because the architecture and data model already exist. Adding a new user doesn't increase your bill.

Adding a new module doesn't trigger a vendor negotiation. The compounding effect is real. Every enhancement makes the system more valuable, and none of it shows up as a renewal line item.

Strategically, software that understands your specific business becomes a moat your competitors using generic SaaS cannot replicate. A distributor management system built for your territory, your margins, and your payment cycles isn't something a competitor can buy off the shelf. It's an application development investment that compounds into operational advantage.

But the counterpoint matters. Custom software abandoned within a couple of years is worse than SaaS churn. At least with churn, you stop paying.

With abandoned code, you paid once and got nothing. The commitment to maintain what you build is non-negotiable.

The teams that get this right treat software as infrastructure, not as a tool. Across regulated industries, the pattern is the same. The systems that lasted a decade were the ones the business kept funding because they kept generating returns.

That's the trade-off. Higher discipline, higher commitment, but software that stops being a liability and starts being an asset.

How much does custom software development cost in India for an SME?

A focused MVP requires an upfront investment that varies with scope and complexity. Full-scale applications cost much more as features and integrations expand. The key is phased delivery: start narrow, validate, then expand, rather than building everything at once. Most SMEs underestimate the 18-24 month enhancement budget after initial launch, which is where the real cost surprises hit.

Is building custom software actually cheaper than SaaS for an Indian SME?

Over a 3-5 year horizon, yes, if the software is a core business function. An SME spending on stacked SaaS tools sees that annual cost recur every year for five years with zero ownership. Custom software built for the same scope delivers lower total cost over the same period. The marginal cost of additional users approaches zero, and you own the asset on the balance sheet instead of renting it forever.

When should an Indian SME build vs buy software?

Build when the software is a competitive differentiator, when no mature vendor covers your specific workflow, or when you have multi-year commitment to maintain it. Buy when the function is commodity (email, basic accounting, generic HR) and a credible vendor already solves 80%+ of your need. Buy and extend when you need most of a product but not all of it.

What are the hidden costs of SaaS that most Indian SMEs miss?

Per-user-per-month pricing multiplies fast. Seats times months times per-seat cost compounds into lakhs of rupees per tool per year, and most SMEs run several overlapping tools. Add integration costs, retraining during vendor switches, data migration, and the productivity loss from context-switching between tools. These rarely appear in the procurement line item, but they show up in the year-two bill that kills custom CRMs. The same applies to the SaaS equivalents.

How long does it take to build custom software for a small business in India?

An MVP takes three to five months with a focused team. Full-featured applications take nine to eighteen months depending on scope. The smarter approach is phased delivery: ship the highest-value workflow first, measure impact, then iterate. This reduces both time-to-value and total software development cost. It avoids the trap of most Indian manufacturers buying ERP twice because the first build never landed.

Run the five-year TCO on your current SaaS stack before the next renewal arrives.