Ready-Made vs Custom Software: How to Decide Without Regret

Start with the 85% rule

Take your top twenty requirements — the things the system must do, written as sentences a member of staff would recognise. Score a candidate product on each: does it, out of the box, without a workaround?

• 17 or more (85%+): buy it. Adapt your process for the rest. A build will cost multiples more and take months longer to be worse.
• 12 to 16: it depends on which ones are missing. If the gaps are in reporting or convenience, buy and work around them. If the gaps are in how you actually make money, look harder at building.
• 11 or fewer: you are about to spend two years fighting the software. Build, or find a better-fitting product.

The rule works because the last 15% is exponentially more expensive than the first 85%. Vendors have already amortised the common part across thousands of customers. You would be paying for it alone.

The honest comparison

Neither column is the good one. They fail differently, and you are choosing which failure mode you would rather manage.

When buying is clearly right

• Accounting and statutory compliance. Tally and its peers have absorbed twenty years of GST rule changes. Rebuilding that is not a competitive advantage; it is a liability you would be volunteering for.
• Email, storage, video calls, payroll basics. Commodity functions where your process is not special and should not be.
• You need it working next week. No custom build competes with a product you can switch on this afternoon.
• You are still discovering the process. If the workflow will change three times this year, do not cast it in code yet. Use a product, learn, then build once you know.

When building genuinely pays

• The mismatch is where your margin lives. A distributor whose slab-based pricing and scheme calculations are the reason customers stay cannot outsource that logic to a product that does not model it.
• You are paying per user for something you use constantly. Sixty staff on a ₹700-per-user product is ₹5 lakh a year, forever, rising. That is a build every two and a half years.
• You are running the business through spreadsheets stitched to WhatsApp. The tell is a person whose actual job is copying data between systems. That salary is your budget.
• Several products, none of which talk to each other. Sometimes the right build is not a replacement but the layer that connects what you already have.
• Data location or audit requirements. When you must control where data sits and who touched what, "trust our platform" is not an answer you can give an auditor.

The hybrid most people miss

The framing "buy or build" is usually wrong. The best-run systems I see in Indian SMEs are neither: they buy commodity functions and build only the part that is genuinely theirs.

A hotel group I have worked with keeps Tally for accounts, uses a channel manager for OTA inventory, and runs a custom property management system for everything in between — rate rules, corporate billing, banquet enquiries, housekeeping. Nobody rebuilt accounting. Nobody accepted a rigid off-the-shelf PMS either. APIs hold it together.

Before commissioning any build, list what you already pay for. Half the requirements in a typical brief are already met by software the business owns and has forgotten it has.

The three-year arithmetic

For a 40-user business comparing a ₹650-per-user SaaS product with a ₹9,00,000 custom build:

Crossover in year four at this headcount. At 80 users it arrives in year two. At 15 users it may never arrive, and SaaS is simply the right answer.

But run the non-financial column too. Over those four years, how many times will the vendor's roadmap have gone somewhere you did not want? How much staff time goes into workarounds? What does the migration cost if they raise prices 40% or get acquired?

Questions to ask a SaaS vendor before committing

1. What does pricing look like at three times our current headcount?
2. Can we export all our data, including history and attachments, in a usable format?
3. What is the contractual notice period, and what happens to our data after we leave?
4. Which of our top twenty requirements need a workaround today?
5. Is there an API, and is it included in our plan or an enterprise upgrade?

Question five catches a lot of people. Plenty of products offer an API only on a tier that costs several times what you were quoted.

How I approach this conversation

A meaningful share of scoping calls I take end with me recommending a product instead of a build. That is not modesty; it is the cheapest correct answer, and recommending a ₹9 lakh project that will not pay back is a good way to lose a client and a reputation at the same time.

When building is right, I build it so you are never in this position again: you own the source code, the schema is documented, and there is no per-seat licence quietly scaling with your growth.