Build or buy: when custom software is actually the cheaper option

The comparison almost everyone gets wrong

The instinct is to compare a subscription against a build quote: ₹4,000 a month against ₹12 lakh. Framed that way, buying wins for twenty-five years and the conversation ends.

That comparison is wrong because it prices only the licence. The real cost of a bought tool that does not quite fit is the work your team does to compensate for the gap — the exports, the re-keying, the spreadsheet that reconciles two systems, the person who knows which fields are lying.

• Licence cost per seat, multiplied by the seats you will have in three years, not today
• Hours per week spent moving data between the tool and everything else
• The cost of a process you cannot change because the tool will not allow it
• Integration tiers — the API you need is very often on the plan above yours
• What leaving costs, if your data only exports as CSV

Where buying clearly wins

If the process is genuinely standard, buy. Accounting rules are not your competitive advantage. Neither is payroll, email, or document storage. A commodity process handled by a mature product will beat anything custom on cost, reliability and the speed at which it gets fixed when it breaks.

Buy when the process is well understood across your industry, when the tool is not going to sit at the centre of daily operations, and when the seat count is small enough that per-user pricing never compounds into something painful.

Where building wins

Building wins when the process is the thing you are actually good at. If the way you quote, schedule or fulfil is why customers choose you, then bending it to fit a generic product is not a saving — it is filing down the part that works.

The second case is scale of friction. A workaround that costs ten minutes a day costs a person-month a year at ten users. Multiply by however many workarounds you have accumulated and the build quote stops looking like the expensive option.

The tell is not cost. It is whether your team describes the process differently from how the software models it.

The arithmetic, concretely

Take the total annual licence cost for the seats you expect in three years. Add the loaded hourly cost of every hour per week spent working around the tool, times fifty. That is your real annual run rate.

Against it, put the build cost amortised over three years plus a realistic maintenance figure — assume fifteen to twenty percent of the build cost per year, because software you own is software you maintain. If the build is cheaper across three years and the process is core to how you compete, build. If it is close, buy, because a close call means the fit is good enough.

The middle path most teams should take first

There is a third option that gets skipped: keep the bought tools and build the connective tissue between them. A great deal of the pain that gets diagnosed as “we need a custom system” is really “our four systems do not talk”.

Automation and integration work is a fraction of a platform build, ships in weeks rather than months, and — this is the part that matters — tells you exactly which parts of the process are genuinely unusual. If you still want a custom build afterwards, you will scope it far better for having done this first.