Build or buy? A decision framework that survives contact with reality

Two failure modes, mirror images of each other. One business buys a rigid packaged product for the process that is its actual competitive advantage, and spends years working around it. Another builds a custom accounting module and spends a decade maintaining a worse version of software that costs a few thousand rupees a month.

The question is not "build or buy" as a philosophy. It is per-capability, and it has a decent test.

Should you build or buy this capability?

For any capability, ask: would a customer ever choose us because of how we do this?

Payroll, general ledger, expense claims, email, standard CRM, standard inventory: no. These are commodities. Doing them 20% better than a competitor produces no advantage. Buy them, configure them, move on.

Your specific dispatch allocation logic, your pricing model, the portal your customers use daily, the workflow that lets you quote in an hour when competitors take two days: possibly yes. These are candidates for building.

Most businesses have one or two genuine differentiators. Founders reliably believe they have six. Test each honestly, because building a differentiator you do not have is the most expensive mistake in this category.

What else should you weigh before building?

1. Does a product exist that fits without heavy modification?

Actually check, with a trial and your own data. If a product handles 80% of the flow through configuration alone, buying almost always wins — and the remaining 20% is often a process you should reconsider rather than a requirement you must preserve.

The trap is a product that fits 60% and needs deep customisation for the rest. That is the worst outcome available: you pay licences and development, and you re-test the customisation at every upgrade forever.

2. What is the true cost of building, over five years?

Initial development is roughly a third of lifetime cost. Add maintenance, security patching, dependency upgrades, browser and OS changes, hosting, monitoring, and the feature requests that arrive the moment the first version ships.

Then add the risk nobody prices: key person dependency. If one developer holds the whole system in their head and leaves, you may pay a large part of the build cost again just to regain understanding.

3. How fast is the requirement changing?

Stable and regulated — statutory reporting, tax computation — favours buying, because the vendor absorbs regulatory change across their whole customer base. Fast-moving and specific to how you compete favours building, because vendor roadmaps will not follow you.

4. What is the cost of being wrong?

Buying wrong is recoverable: you migrate, painfully but finitely. Building wrong is worse, because sunk cost keeps the project alive long past the point of sense. If uncertain, buy — the reversal is cheaper.

What is the best build-vs-buy approach for most businesses?

In practice most growing businesses end up here, and should:

• Buy the commodity core. ERP for finance, inventory and procurement. CRM for sales. Packaged payroll.
• Build the thin differentiating layer. The customer portal, the allocation engine, the quoting tool — small, focused applications that read from and write to the core.
• Integrate deliberately. Designate one system of record per data entity. Build connectors with retries, idempotency and monitoring. This layer is where hybrid architectures actually succeed or fail.

The advantage is proportionality: you write and maintain only the code that is genuinely yours, and let vendors absorb the enormous ongoing cost of the commodity parts.

Before you build anything, prototype manually

If you conclude you should build, run the process manually first — spreadsheets, forms, a shared document, whatever is quickest. For weeks, deliberately.

Manual operation exposes what the real requirement is. In a retail aggregation network I worked on, an eight-week manual pilot revealed that the binding constraint was settlement timing, not pricing — which reshaped the entire platform. Building first would have produced an elegant solution to the wrong problem.

Manual prototyping is cheap, fast and reversible. Code is none of those things.