We are not a software vendor · when building your own actually pays

Here is a sentence you rarely hear from a vendor: we are not a software company. We build custom software only when it genuinely pays off, and that is rare.

The sentence costs us revenue, which is exactly why it belongs here. The most expensive software a company owns is almost always the software that got built because nobody asked whether it needed building.

The default answer is no

Custom software is not a purchase. It is a commitment. It does not end at delivery, it starts there: running it, patching it, fixing it, adapting it when an interface changes, and holding the knowledge in the heads of people who will eventually leave. Building is the smaller half of the bill.

So the sensible default is: do not build. Anyone departing from that default should be able to say why. Four tests are enough, and all four have to pass. Not three of four.

Test 1: Is this what sets you apart?

Building your own pays off only where your method beats everyone else's. Not differs from. Beats, in a way your customers actually notice.

Accounting is not that. Time tracking is not that. Document storage is not that. Those are solved problems, and building your own there buys you no advantage at all, only maintenance work with your logo on it.

Test 2: Does the standard bend your process for the worse?

Off-the-shelf software forces you to adapt, and that is usually a good thing. Adapting to a proven method is often the real improvement, whereas building your own cements the quirk you should have shed.

So the test is meant seriously: does the standard bend your process for the worse, or does it merely bend it? That question can only be answered if the process was written down first. Anyone who cannot answer it does not have a software problem. They have a process problem.

Test 3: Can you run it for its whole life?

Not: can you get it built. Rather: in five years, will someone understand the source, update the dependencies and find the bug on a Friday evening? And if that person resigns, is there a second one?

An honest answer to that question ends most projects, and it ends them before they cost money. That is the most valuable moment to end them.

Test 4: Is the process stable enough?

Software freezes a way of working. That is its purpose and its risk in one. A process that still changes every few months is not ready for custom software. It is ready for a spreadsheet and a conversation.

The reverse holds too: a routine that has not changed in years and runs many times a day is a good candidate. Frequency and stability, not importance.

What we do instead

In most cases at least one of the four tests fails. What remains is a job that is less spectacular and considerably more useful: connecting the systems you already own so that the work between them disappears.

• Connect rather than rebuild: what the ERP already does does not need building a second time. It needs to become reachable.
• Configure rather than program: a role with clear permissions and a clear job solves a surprising number of cases that would otherwise have become an application.
• Enable rather than tie down: if your team can change the configuration itself, you do not need us for the next change.

The third point is the one that costs us work. It is right anyway, because the alternative is a dependency that eventually gets in the way of both sides.

So when do we build?

When all four tests pass. That happens, and it usually looks the same: a demanding professional routine with no off-the-shelf product behind it, because too few companies have it, yet enough companies that it is worth doing. Regulatory reporting with edge cases is one example. An inspection workflow with its own domain logic is another.

In those cases we build small, document it so another team can carry on, and hand over operations as soon as they can be handed over. Software only we can run would not be an asset to you. It would be a leash.

The point

The question is never build or buy. It is this: what about our way of working is genuinely ours, and what have we simply never questioned?

Answer that question and in most cases you need no new software at all. You need a clean connection between the systems you paid for long ago. And that is far better news than a quote.