Talk to an engineer

· 2 min read · BluMargins

Product, customisation, or custom build: how to choose

We sell products and we build bespoke systems, which means we have to be honest about which one a business actually needs. Here is the test we use.

  • products
  • delivery

We are in an awkward position that we think is actually the right one: we license twelve products and we also build bespoke systems. That means on every engagement we have to answer a question most vendors answer the same way every time. Here is how we decide.

Start with what is genuinely different about you

Every business believes its process is unique. Most of the time, about eighty per cent of it is not, and the remaining twenty per cent is where the entire competitive advantage lives. A product covers the eighty per cent well and cheaply. The mistake is not buying a product; the mistake is configuring away the twenty per cent to make it fit.

So the first question is not "what do we need" but "which parts of what we do would we refuse to change". If nothing comes back, buy the product as it stands.

Customisation is a maintenance decision

A customisation is not a one-time cost. It is a permanent obligation that has to be carried through every upgrade of the underlying product. That is fine when the customisation encodes something valuable. It is expensive when it encodes a habit nobody has questioned since the last system was installed.

We price customisations with the upgrade cost included, because that is the number that actually matters.

Custom builds are for systems that are the business

Building from scratch makes sense when the system is the product, when the process is genuinely without precedent, or when the integration surface is so specific that a product would be more wiring than software. It also makes sense when the data is too sensitive or too regulated to sit inside somebody else's schema.

It is the right answer less often than people expect, and more often than product vendors will admit.

What we do in practice

We start most engagements with an architecture read that ends in a recommendation, including the recommendation to change nothing. If a product fits, we say so and we deploy it. If it fits eighty per cent, we deploy it and build the twenty per cent as a proper extension rather than a fork. If nothing fits, we build. The honest answer is worth more to us than the larger invoice, because the second engagement is where the relationship actually starts.

More from the blog

A model is not a product

Most AI projects do not fail at the model. They fail at the retrieval layer that never had the right context, the evaluation nobody wrote, and the guardrail nobody set.

All posts

Bring us the whole problem.

Tell us where the work is stuck, whether that is a model that never reached production, an application nobody can change, a data platform nobody trusts, or a plant the business cannot see. An engineer replies with a first read, not a sales deck.