When adding one number to the dashboard takes a release
Every mature business system has a dashboard: five, ten, twenty numbers on the front page telling you how the company is doing. And every mature business system has the same conversation once or twice a year: “we’d also need the total of…”. The technical answer is always the same — it can be done — and so is the quote: analysis, development, testing, release. For one number.
The symptom isn’t the number: it’s that the request keeps coming back
Writing a metric into the code is a legitimate choice the first time. By the third request with different content, what the company is paying for isn’t the development of that metric: it’s the fact that it can’t change its mind without calling a vendor.
And the cost isn’t the quote, it’s the delay. Weeks pass between “we’d need this” and “here it is”, and in those weeks the decision gets made anyway — with the numbers that were already there. A dashboard that doesn’t keep up with the business doesn’t get ignored: it gets believed.
This doesn’t mean making everything configurable
The opposite mistake is just as expensive, and harder to argue against because it looks like foresight. You build a platform of parametric rules for cases nobody ever asked for, every parameter becomes one more surface to get wrong, and a year later nobody touches that configuration for fear of breaking something.
The useful boundary isn’t technical: what changes with the business goes outside the code, what changes with the software stays inside. Two questions place almost everything. Has this request come in more than twice? Is the right value different across sites, clients, financial years? If yes, it’s a business decision written in the wrong place. Otherwise it stays in the code, and that’s fine.
An ungoverned parameter is a defect in waiting
Moving a decision from code to configuration makes it editable — and also removes it from every check the code had around it. That’s where these projects fail. What has to be built alongside the parameter:
- Validation at entry. A metric pointing at data that doesn’t exist must be rejected when it’s created, not displayed as zero on the front page. A zero on a dashboard doesn’t say “data missing”, it says “it’s zero”.
- Provenance and as-of date. For every number it must be readable where it comes from and how current it is. Two metrics side by side but aligned to different dates are a wrong comparison presented as a right one.
- Stable order and identity. If renaming an entry moves it or loses its history, the configuration has become another source of instability.
- A guided interface, not a file to edit. If adding an entry requires the right syntax in a text file, the decision hasn’t left the developers’ hands: it has just become more fragile.
How to judge a vendor
The question to ask isn’t what it costs to add one metric. It’s how many of the changes you’ll request over the next three years will require a release. That percentage is the most honest measure of how much a system is really yours.