XCofinite
Consulting

Build versus buy for internal tools, without the religion

Elena PetrovaApril 8, 20265 min read

The honest answer is usually buy. Here is the short checklist for the times it genuinely is not.


Every internal-tools conversation attracts strong opinions. Strip out the ideology and it comes down to a few questions.

Buy when

  • A mature product covers 80% of the need out of the box.
  • The process you are supporting is common across many companies (expenses, ticketing, scheduling, CRM).
  • You do not have the capacity to maintain software for years, because that is the real cost, not the build.
  • The vendor's roadmap is heading where you are heading anyway.

Build when

  • The process is a genuine differentiator or is unusual enough that products fight you.
  • Integration with your own systems is the hard part, and you would be building that glue regardless.
  • The data is too sensitive or too central to hand to a category of SaaS you do not fully trust.
  • You have, and will keep, the capacity to own it. Be honest here.

The middle path

Often the right answer is buy the platform, build the thin layer. A low-code platform or a well-chosen framework for the 20% that is yours, sitting on bought infrastructure for the 80% that is not. That keeps the maintenance burden proportionate to the value you are actually adding.

The cost people forget

A built tool needs dependency updates, security patches, a person who understands it, and a plan for when that person leaves. Budget for five years of that before you decide building is cheaper.

All posts

Let's talk about what you're running.

A 30-minute call, no slides. Tell us where it hurts and we'll tell you honestly whether we can help.