Guide8 min · 20 points · no sign-up
Build-vs-buy guide for operations software
We build custom software for a living, which is exactly why this guide spends most of its length on when not to. A customer who should have bought a product and didn't is an unhappy customer eighteen months later.
01
Buy, almost always, when
- The process is standard across your industry — accounting, payroll, email, CRM basics, helpdesk.
- A mature product covers 80% of your need and the remaining 20% is preference rather than operation.
- Compliance or certification is involved and a vendor already carries it.
- You would be the only user of the thing you are about to build.
02
Build when
- The process is the business — the thing you do differently from competitors, which is also the thing no product models.
- You are paying per seat for software that three people use one screen of.
- The off-the-shelf option requires you to change a workflow that is a genuine advantage.
- Integration between systems you already own is the actual product, and no vendor sits across all of them.
- Data residency, air-gap or ownership requirements rule the products out.
03
Do neither when
- The spreadsheet works and the only complaint is that it is a spreadsheet.
- The process changes every quarter and has not settled.
- Nobody internally will own the system after it exists.
- The real problem is a staffing or incentive problem wearing a software costume.
04
The costs comparisons usually miss
- Buy: per-seat growth, the implementation partner, data migration, the integrations that are extra, and the renewal in year three.
- Build: hosting, maintenance, security patching, the person who owns it, and the rewrite when the first engineer leaves without documentation.
- Both: the cost of change management. The system nobody uses costs 100% of its price.
- Both: exit cost. How do you get your data out, and how much does leaving cost in each case?
05
A middle path people forget
- Buy the standard parts and build only the layer that is genuinely yours — often a thin operations app over a bought system's API.
- Build a deliberately small internal tool to learn the process, then buy or build properly once it has settled.
- Take over and modernise what you already have instead of replacing it; a week's assessment will tell you if that is viable.
If you want a second pair of eyes
We will walk through this with you, free, for thirty minutes.
No deck. Bring the specifics and we will tell you where the risk actually is — including when the answer is that you should not start this project yet.
- GSTIN 09CPBPD9064H1ZS
- Lucknow, India
- Reply in 1 working day