A founder's matrix. Seven questions, weighted. If you score five toward custom, build. If you score five toward SaaS, buy. If you score three to four either way, the question is wrong.
By Mohammad Jamnagarwala · Simply Five Studio
Every founder running a mid-market Indian business reaches the moment where the operational software question becomes urgent. The SaaS stack has stopped fitting, or the manual workflows have grown beyond what spreadsheets can hold, and the choice between continuing on a vertical SaaS, switching to a different vertical SaaS, or building something custom presents itself. The choice is usually made on incomplete information and partial reasoning. The result, three years later, is either an operational backbone the firm depends on or a stack of regret that everyone pretends to be happy with.
The matrix below is the structured version of the questions we walk through with founders in the first conversation. Seven questions. Each scored toward custom or toward SaaS. The total tells you which path the firm should take. If you land between, the question itself is wrong, and the right answer is more conversation, not a coin flip.
Score toward custom if your workflow has category-specific steps the generic vendor has never modelled. The CFX multi-tenant ERP for the cutting-tool group exists because Zoho could not model their cross-brand reporting and shared-inventory situation without endless customisation.
Score toward SaaS if your workflow looks like the generic vendor's template with minor adjustments. Most early-stage firms with standard sales pipelines fit here. Forcing custom in this profile is a waste of build budget.
Score toward custom if your volume justifies the build economics. A firm doing 5000 transactions a month with senior staff time consumed by the operational software has more to gain from custom than a firm doing 50.
Score toward SaaS if your volume is small enough that the per-seat or per-transaction cost stays modest. Below a threshold, the SaaS subscription is genuinely cheaper than the build.
Score toward custom if your requirements have been stable for two or more years. Stable requirements are encodable. The encoding pays back over the system's lifetime.
Score toward SaaS if your operational model is still evolving rapidly. A firm three months into a new product line should not be building custom software for that line. Wait for the workflows to stabilise.
Score toward custom if your firm's data is part of your competitive position. Customer relationship history, vendor performance data, operational margins by category. These are competitive assets the firm should own outright, in its own database, on infrastructure it controls.
Score toward SaaS if the data has no competitive sensitivity. Generic back-office data, where vendor lock-in is a future inconvenience but not a strategic risk, can sit in a SaaS provider.
Score toward custom if you are building a firm for the next decade or two. The SaaS subscription compounds against you over a long time horizon. The essay on when SaaS exceeds custom build walks through the math. The cross-over is between year two and year four.
Score toward SaaS if you are building toward an exit in the next two to three years. The custom build has a long payback period that may not complete before the exit. Buyer-side diligence sometimes prefers familiar SaaS over unfamiliar custom.
Score toward custom if you have a technology partner who can build, maintain, and evolve the system reliably. The long-term partnership with AKSD is the kind of relationship that makes custom feasible: someone owns the ongoing operational responsibility.
Score toward SaaS if you do not have that partner relationship and hiring an internal engineering team is not in the plan. Custom software without ongoing maintenance becomes a liability faster than founders expect.
Score toward custom if your team spends material daily time working around the SaaS limitations. Manual reconciliation between two SaaS systems that should integrate. Workflows that exist because the SaaS forced a workaround. Reports the system cannot answer that require exporting to Excel. The friction cost is invisible in the SaaS invoice and material in aggregate.
Score toward SaaS if your team operates inside the SaaS without material workaround. The system fits, the team is productive, the friction is genuinely modest.
Five or more questions pointing to custom: build. The firm has the volume, the specificity, the stability, the data sensitivity, and the operational support to make custom the right answer. The build is worth committing to. The enterprise engagement is the right shape for this profile.
Five or more questions pointing to SaaS: buy. The firm's profile does not justify a custom build. The right move is a careful selection of the SaaS stack, ideally a vertical SaaS for the specific category rather than a horizontal one. The cost of the wrong custom build, in a firm that did not need it, is higher than the cost of a SaaS that fits.
Three or four questions either way: the question is wrong. The right move is more conversation, not a decision. Specifically, the firm needs to understand which of the seven questions are actually load bearing for its situation. Sometimes the matrix score is misleading because one question (often data ownership or friction cost) outweighs the others. The first conversation in our practice is dedicated to finding which questions actually matter for this firm.
The matrix presents the choice as binary. The reality is more often hybrid. A firm runs Tally for accounting (genuine vertical SaaS that fits the Indian context), the ES HAJI industrial ERP for operational workflows (custom build), Zoho Mail for email (SaaS that fits), and WhatsApp Cloud API directly integrated into the operational system (self-hosted integration). Each piece is the right answer for its specific workload.
The mistake is treating the choice as all-custom or all-SaaS. The mistake is also treating the choice as static. A firm's profile changes over time. Workflows that justified SaaS three years ago may now justify custom. The matrix should be re-run periodically, not just at the founding decision.
The cost of building custom when SaaS would have fit is wasted budget and slow time-to-value. The build takes three to six months. The SaaS would have been operational in three weeks. The opportunity cost is real but recoverable.
The cost of staying on SaaS when custom would have paid back is harder to recover. Two or three years of friction tax, of customisation tax, of opportunity cost from the system not fitting. By the time the firm recognises the misfit, the cost of switching includes a data migration on top of the build cost. The essay on when SaaS cost exceeds custom build covers this asymmetry in detail.
The cost of staying on the wrong answer is always larger than the cost of moving. The cost of moving is largest when the move is delayed.
This matrix is a structured starting point for a conversation. It is not a substitute for the conversation. The internal systems engagement begins exactly here: working through the seven questions, scoring them honestly for the firm in front of us, and recommending the path the score actually supports.
If the score points to custom and we believe SaaS is the better answer for the firm's specific circumstances, we say so. If the score points to SaaS and we believe custom is the better answer, we say so. The matrix is the structure. The judgement is the conversation.
If your firm has not run this exercise in the last twelve months, the exercise is worth running. Start a Conversation.
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.
