Business logic is not a specification

By ·

Early in my career I worked at an energy forecasting company.

Sophisticated models. Years of historical data. Serious infrastructure. The kind of system that looks like science from the outside —because in many ways it was.

Every day, we ran price forecasts for the Spanish electricity market. Python, statistical models, C++ applications built on top of a decade of data. They were pioneers in this space —one of the first teams doing it seriously at scale.

And yet, every morning, just before the forecast went out, the founders —scientists who had built the company around their own research— would make themselves a cup of herbal drink, lean back, look at everything —the models, the competitor figures, the signals that hadn't been formalized anywhere— maybe turn to the other and ask: what do you think? And then produce a number.

Not from the models. From judgment. From experience. From something that couldn't be fully formalized.

That was the real forecasting logic.

The system was real. The science was real. But the decision lived somewhere the code couldn't reach.

This is more common than people admit.

We like to believe business logic is something we can fully specify. Define once. Build on top of indefinitely. Like physics —where the equations that governed semiconductors yesterday will govern them tomorrow.

Business logic doesn't work like that.

It changes when you go from 3 customers to 5,000. The system that worked perfectly at one scale breaks not because it was badly built —but because it was built for a business that no longer exists.

It changes when you expand from one region to the entire world. Compliance rules, pricing models, operational flows —all of it shifts.

It changes when you move from B2C to B2B. The same product, a completely different model underneath.

And sometimes it was never fully clear to begin with. What looked like business logic was actually a sediment of decisions that happened to work, and then got frozen.

This is why systems break.

Not because they were badly engineered. But because they were engineered around a version of the business that no longer exists.

The system has to be able to hold whatever the business logic actually is —including when it's incomplete, inconsistent, or still being figured out.

The manager with his herbal drink was not a workaround. He was the system.

The question is whether your backend knows that.