Every mid-market business eventually does the math. Most of them do it three years too late. The math is simple; the timing is not.
By Mohammad Jamnagarwala · Simply Five Studio
Every mid-market business that runs on subscription software eventually does the math. The annual cost of the SaaS stack exceeds what a custom build would have cost. The custom build, retroactively, would have been the right answer.
The math is simple. The timing is the hard part. Most founders do the math three years too late, after they have already paid the subscription cost they wish they had not.
This essay is about the timing question. When is the moment to do the math, and what does the math actually look like.
The subscription cost of a serious SaaS stack for a mid-market business is larger than founders typically realise. A core ERP, a CRM, a marketing platform, a customer support tool, a notification service, an analytics dashboard, plus the add-ons each of these require to function for a non-trivial business. The total per-month spend, for a firm doing twenty to fifty crore in annual revenue, is commonly in the range of one to three lakh rupees per month. That is twelve to thirty-six lakh per year, recurring, forever, with annual price increases.
The build cost of a custom equivalent, for a firm of the same profile, is in the range of ten to thirty lakh as a one-time investment, plus a long-term technology partnership retainer of fifty thousand to a lakh and a half per month for ongoing maintenance and evolution.
The two streams cross between year two and year four, depending on the specifics. After they cross, the custom path is permanently cheaper, and the gap widens every year as the SaaS price increases and the custom system continues to amortise.
The math is unambiguous when you write it out. The reason most founders do not write it out is that the SaaS payment is broken into twelve monthly pieces that each look small individually, and the custom-build payment is a single large number that looks scary. Loss aversion does the rest.
The math above understates the case for custom in one important way. The SaaS stack rarely fits the firm's workflow out of the box. The firm pays the subscription, then pays again to customise. The customisation work is often done by a third party, charged hourly, across many small engagements over the years.
The customisation tax is invisible because no one totals it. The firm budgets for the subscription. The customisation gets buried in the operational budget, charged to one or another project, never summed up as a category. A firm that spends two lakh per month on SaaS subscriptions often spends another lakh per month on customisation, integration, and workaround engineering. The total is three lakh per month, or thirty-six lakh per year, of running cost.
When the customisation tax is added to the math, the cross-over with the custom-build cost happens sooner. Often in year one.
Beyond cost, the deeper issue with the SaaS stack is fit. The customisations the firm wants are bounded by what the SaaS vendor allows. The integrations are bounded by what the vendor's app marketplace supports. The data model is the vendor's, which means the firm's operational reality has to bend to fit the vendor's view of how the business should work.
Most mid-market businesses do not look like the vendor's view. They have category-specific workflows, customer relationships that span years, vendor relationships that involve negotiation, and reporting needs that the vendor's standard reports cannot answer. The mismatch produces a thousand small frictions that the team works around daily. The friction is invisible per instance and material in aggregate.
A custom system fits the firm's operational reality by construction. The data model is the firm's. The workflows are the firm's. The reports answer the firm's questions. The fit problem disappears, and with it the daily friction the team had learned to live with.
The right time to do the math is when any one of three signals shows up.
The first signal is the subscription line item being a meaningful percentage of operational spend. If the SaaS stack costs more than the firm's top-five operational vendors combined, the firm is implicitly running a software company without the upside of being a software company.
The second signal is the customisation work being permanent rather than periodic. If the firm has a customisation engineer or an external agency on a retainer to keep the SaaS stack working as the business changes, the SaaS is no longer providing leverage. It is providing overhead.
The third signal is the founder's frustration that the system cannot answer basic questions. If the founder is asking the team for reports that should take minutes and getting answers that take days, the system has stopped being decision infrastructure and started being record-keeping bureaucracy.
When any of these signals shows up, the math is worth doing. The math will tell you, accurately, which path costs less over the next five years. For most firms past mid-market scale, it tells you the same thing.
The custom path is not free of effort. It requires a clear diagnostic up front, a build of six to twelve weeks for the first working version, a migration plan that respects the firm's operational continuity, and a long-term partnership with the firm that built the system.
These are not trivial requirements. They are smaller, in aggregate, than the cost of continuing on a SaaS stack that has stopped fitting. But they are not zero, and a founder considering the path should be ready to invest the time as well as the money.
For founders who do the math and find the custom path is right for their firm, the path is well-trodden. Several of our long-term partners arrived here exactly this way; the CFX multi-tenant ERP we built for three cutting-tool manufacturers in Mumbai is the clearest example. The first conversation, in each case, started with the same recognition: the subscription cost exceeded the build cost, and the friction cost exceeded both. The math made the case. The execution required commitment. The result, a few years in, is a system the firm owns and an operational rhythm that scales without the friction tax.
The math is simple. The timing is not. The cost of doing the math late is large. The cost of doing it on time is small.
Accounting software produces statutory output. ERP automates the workflows of a generic business. Neither is the same as the structured truth a founder needs to run a specific business. That third thing is decision infrastructure, and it is what founder-led firms eventually outgrow SaaS to acquire.
Every six months a founder asks why they need another system when Tally already runs the books. The honest answer is a diagnostic, not a sales pitch. Here is how to run one on your own business.
Tally is the financial system of record. An ERP is the operational system of record. Most founders buy one and assume it is also the other. The confusion costs years.
The contact form takes about two minutes. The reply comes from the founder within two working days.
