Every Setting Is a Promise

You have heard it in a demo. The screen you are looking at does not quite do what your business does, and the answer arrives before you have finished the question: it is fully configurable. You will be able to set that up however you like.

It is reassuring because it sounds like the vendor is handing you control. What is actually happening is that a decision has been moved. Nobody in that room has to work out how your business does the thing, because the settings panel will find out later, from you, on your own time.

Sometimes that is exactly right. Often it is a decision being deferred to the person least equipped to make it, dressed as a feature.

This is not a criticism we get to make from the outside. Our first project was a small one, taken on straight out of a corporate world, and we approached it with the belief we had absorbed there: that what a customer wants is configuration. Give them the switches. Let them decide.

It is a comfortable belief for whoever is building, which is the first clue that something is off. It means never being wrong about a customer's process, because you never committed to one. It also means the customer opens a panel of switches nobody has ever set in that combination before, and finds out what works by trying.

The corporate version of this has a familiar shape. Software sold as configurable, then a consulting engagement to configure it, then years of somebody maintaining a configuration that is really code wearing a different hat, held in a place where none of the tools that make code safe can reach it.

Adding a setting is a promise that the software will behave sensibly with that setting on, and with it off, and in combination with every other setting already there. Ten independent switches is a thousand or so combinations that are all supposed to work. Nobody has tried them. Most of them will never be used by anybody.

That promise gets paid for in three places. It is paid by whoever maintains the software, who now has a much larger surface to keep standing. It is paid by whoever uses it, in a panel that has grown past the point where the right choice is obvious. And it is paid, most expensively, on the day a combination that was never tried turns out to be the one your business needs.

Set against that, the thing being avoided is often twenty lines of code that say what this business does. Written down once, tested, and unable to drift.

The useful question is not how much should be configurable. It is which things change often enough that waiting for a developer would be absurd, and which things have to be right.

A mortgage origination business we worked with sits exactly on this line. Their landing page needed bond calculators, and the calculators are the thing the whole page is for. So the words went into a content system they edit themselves and the arithmetic stayed in code. Nobody can accidentally change a repayment figure while updating a heading, because those two things do not live in the same place.

That looks like a technical detail in a project summary. It is the whole architecture, and it took a conversation about which parts of the business change weekly and which parts have to be defensible.

There is a stage past a settings panel where a business is not configuring software any more, it is programming it through a form. The individual changes all looked reasonable at the time. What accumulates is a set of decisions living somewhere with no tests, no review, and no way to tell which of them anybody still needs.

The bill arrives as an upgrade that will not go through. A medical equipment business came to us after two previous development partners had customised their software to the point where it could no longer take a new version. The third attempt worked because it changed nothing inside the bought software at all. Everything standard stayed standard, and the two things that genuinely did not exist were built alongside it, where they could be maintained on their own terms.

Configuration is not the villain in that story. Losing track of how much of it there was, and where it lived, is.

The clearest case runs the other way, in a product where one tier is deliberately left out of the settings panel.

A portfolio platform for advocates offers three tiers. The first two are curated templates with presets, which is to say a bounded set of choices somebody has already checked look good together. The third is built from nothing for one person, with its own scroll behaviour, its own opening and closing, and layout mechanics carrying far more levers than a settings panel could hold and stay usable. It is not turned into a template afterwards, and it is not built so that it could be.

Exposing that tier as configuration would produce a panel nobody could operate and a promise nobody could keep. Leaving it as a build is what lets it be sold honestly and priced properly. The two template tiers are better for having fewer choices, and the third is better for having none.