Every System Eventually Wants to Become Configurable

Some of the most important lessons in software come from problems that refuse to stay solved. A new form. A new workflow. A new approval process. A slightly different validation rule. Every request looks unique on the surface, every request requires engineering, and every request slowly makes the system harder to understand.

At some point, I realized we weren't building products anymore. We were building exceptions. That's when I started noticing a pattern that now seems obvious: successful software doesn't become complex because engineers write bad code. It becomes complex because the business keeps learning.

Complexity Is Usually a Business Problem

Most engineers imagine complexity as something technical — legacy code, poor architecture, too many dependencies, too many services. But in my experience, that's rarely where the real complexity comes from. Real complexity comes from success.

A product launches. Customers start using it. Teams learn things they didn't know six months ago. Processes evolve, requirements change, new markets and regulations appear, and special cases stop being special. Eventually the software becomes a reflection of all those decisions — the code isn't creating the complexity, it's absorbing it.

The Hidden Tax Nobody Talks About

The first few exceptions don't hurt, which is exactly why teams ignore them. A stakeholder asks for a small variation, and an engineer adds a condition. A customer needs a special flow — another condition. Someone needs a different review process — another condition. Individually, every change feels reasonable. Collectively, they create a system that becomes increasingly expensive to evolve.

The real cost isn't technical — it's operational. Every new variation requires:

• an engineering ticket;
• prioritization;
• development;
• testing;
• deployment;
• coordination across teams.

A change that should take minutes suddenly takes days, not because the work is difficult, but because the process around the work becomes expensive. That's when you discover something important: the bottleneck isn't engineering capacity. The bottleneck is that engineering has become part of every business decision.

The Day I Stopped Thinking About Forms

One of the biggest shifts in my career happened when I stopped thinking about forms as screens and started thinking about them as descriptions. At first glance, a form looks simple — fields, validation, dependencies, conditional sections, visibility rules, review states, approval paths. But once you step back, you realize those things aren't UI. They're business rules, and business rules change far more often than code should.

The question becomes: why are we rewriting software every time a business rule changes? What if the system could read those rules instead? What if behavior became data?

What Configuration Actually Means

Many people hear "configuration" and imagine a few settings — a JSON file, a feature flag, some admin controls. That's not what I'm talking about. Real configuration starts when behavior itself becomes configurable: not just what fields exist, but:

• when they appear;
• who can edit them;
• what depends on what;
• what validations apply;
• what happens next;
• which workflow path is allowed.

The moment a system starts interpreting those rules rather than hardcoding them, something changes. You stop shipping screens, and you start shipping capabilities.

The Moment a Feature Becomes a Platform

This is the transition I find most interesting. A feature exists to solve a specific problem; a platform exists to solve an entire category of problems. The difference isn't size — it's leverage. When rules, workflows, validations, and behavior become configurable, new solutions stop requiring engineering effort. The system becomes reusable, composable, and adaptable, and the people closest to the business gain the ability to create value directly. That's the moment a feature quietly becomes a platform — and most teams don't notice it's happening until they're already there.

The Dark Side of Configuration

There's a reason many teams never make this transition: configuration isn't free. In fact, it's dangerous when done too early. Every configurable system is secretly trying to become a programming language — and most teams don't realize it until they're maintaining one.

The more flexibility you add, the more complexity you introduce. Debugging becomes harder, mental models become harder, and the platform itself becomes a product that requires maintenance. I've seen teams attempt to make everything configurable from day one, and the result is usually worse than hardcoded software: abstractions nobody understands, rules nobody remembers, flexibility nobody actually needs. Configuration should solve real variation, not hypothetical variation.

My Rule of Three

Over time, I started using a simple rule of thumb. The first exception is an exception. The second exception is a warning. The third exception is usually a pattern. That's when I start paying attention — not because I want more abstraction, but because the business has revealed something important. It has shown where change naturally happens, and if change keeps happening in the same place, that's usually where configurability belongs.

What I Learned

Every successful product accumulates variation. The question is never whether it will happen — it's where that variation will live. If it lives in code forever, every future change becomes more expensive. If it becomes configurable too early, the system collapses under unnecessary abstraction.

The real skill isn't making everything configurable. It's identifying the parts of a business that are constantly changing—and giving those parts room to evolve. The goal isn't to build configurable software; the goal is to understand where change naturally happens—and make that change cheap. The best configurable systems aren't built because engineers love abstraction. They're built because the business keeps evolving.