When the spreadsheet is load-bearing, buying will not help

Four spreadsheets and a shared inbox quietly became the system of record. The question is not which tool to buy — it is which of the four holds the real number.

Nukes AI

Platform team

Nobody decided that the operation would run on four spreadsheets and a shared inbox. It arrived one workaround at a time, and by the time anyone looked properly, the workarounds were the process. The instinct at that point is to go and buy something, and buying is the right answer rather less often than the market suggests.

Read the spreadsheet first

A spreadsheet the operation depends on is not a mess to be replaced. It is a working specification, written by the people who do the job and refined against every awkward case they have met. It records what the company actually does, which is rarely what the process document says.

The columns that look redundant are usually the interesting ones. Somebody added each of them because a case turned up that the earlier columns could not express.

Buying replaces the wrong part

The part that hurts is rarely the part a product replaces. Buying gives you a better table, better permissions and a mobile app. It does not give you the reason your team keeps a second sheet, which is almost always a rule the product cannot express.

A product embeds a view of how the work should be done, and that view was not formed inside your operation.

Where the two views agree, the product is a bargain. Where they do not, the gap gets filled by a workaround, and the workaround is a spreadsheet.

Where a product fits well

Anything that is the same in every company should be bought without a second thought — payroll, ticketing, accounting, source control. There is no advantage available in doing them differently, and somebody else carries the maintenance for the rest of time.

Where it does not

The processes that are specific to how this company competes are the ones a product will fit worst, and they are also the ones worth being good at. That is the whole test, and it is a commercial question rather than a technical one.

The integration is the project

Most build-versus-buy estimates compare the licence to the build and stop there. The real cost of a bought tool is the work of getting data in and out of it: a nightly export, a mapping that drifts, and an integration that has to be rewritten whenever the vendor changes an endpoint.

Configuration has a ceiling

Every configurable product has a point past which further fitting is done in scripts, custom fields and a consultant. Past that point you are building, at a higher price, on foundations you do not control.

Build the difference only

The shape that usually works is neither answer in its pure form:

buy the commodity underneath
build the part that is genuinely yours
own the data in a store you control

A Postgres database that both halves read from keeps the option to replace either one later, which is the thing an all-in purchase quietly sells.

The cost nobody quotes

Software that is built has to be maintained by somebody who is still there. That is the honest argument against building, and it is a staffing question rather than an engineering one. A team that cannot answer it should buy, and should expect to keep the spreadsheet.