The most expensive software is the kind nobody can support.
A client handed us an integration with 700,000 permissions and no living author. Here’s what we found, and what we’d want written into the next brief.
A client came to us with a piece of software that worked. That is worth saying first, because it is what made the situation genuinely difficult. It was not broken. It was simply unmaintainable, and the person who built it had moved on.
They had employed a developer directly to build an API integration between two platforms. Sensible decision on paper: cheaper than an agency, direct line to the person writing the code. What they did not get was any commitment to supporting it afterwards, and no requirement that anybody else should be able to.
What we found
The integration had been built in a way that was over-complex for the job. Not wrong, just elaborate. Layers of abstraction that made sense to one person on one afternoon and to nobody since. Reading it took days. The permissions structure alone had grown to around 700,000 entries.
Our first instinct on any inherited system is to patch rather than replace. Replacing is expensive, it introduces new risk, and it flatters the ego of whoever is doing the replacing. Sometimes it is still the right call.
Software that only one person can safely change is not an asset. It is a liability with a nice interface.
The rebuild
We rebuilt it, designed from the outset so that we, as external developers rather than employees, could keep supporting and evolving it as requirements changed. That constraint drove most of the decisions.
By changing the format in which data moved between the two platforms, with our software sitting in the middle as a translator, we got a new API in place and cut the permissions count from 700,000 down to something a person could reason about in an afternoon.
- Every piece of behaviour lives somewhere findable, not distributed across clever indirection.
- The data contract between the two platforms is explicit and documented.
- Permissions are derived from a small set of rules rather than enumerated.
- A developer who has never seen it can get oriented in a day.
What to put in the next brief
If you are commissioning custom software, the requirement that matters most is not on most requirement lists. It is: somebody other than the author must be able to take this on.
Ask what happens if the person building it is unavailable in eighteen months. Ask to see the documentation before final payment, not after. Ask whether the architecture was chosen because it suited the problem or because it was interesting to build.
None of that guarantees good software. But it does mean the thing you own in three years is still an asset rather than a hostage situation.
Three more
worth the time.
It is far easier to talk a client down from bold than to talk them up from safe. So we start further out than the final thing needs to be.
Account management exists to protect the people doing the work from the people paying for it. We took the opposite bet, and it changed how fast things move.
Content architecture is the least glamorous part of a project and the part that decides whether the site is still usable in three seasons.