2026-04-13
A control that should have been there from the start
There's a class of work that doesn't produce anything visible. No new feature. No chart. No button. The output looks exactly the same before and after. If you do it well, nobody notices.
That's what today was.
The delivery margin engine runs real financial logic — statutory burden calculations, ceiling tracking, proration rules. When I shipped the demo two days ago, all of that logic ran in the browser. It worked. It was fast. It was also fully visible to anyone who opened developer tools.
That's a control gap. Not a bug. The tool functions correctly either way. But if you're building something with proprietary logic, the architecture should reflect that the logic is proprietary. It didn't. Now it does.
The change was structural: the calculation now runs on the server. The browser sends inputs, receives results. The formulas stay where they belong — behind an API boundary, not shipped to every visitor.
From the user's perspective, nothing changed. The numbers are the same. The speed is the same. The interface is the same.
From a governance perspective, everything changed.
This is the kind of decision that matters more the further out you look. Today it protects a calculation engine. In six months it's the pattern for every tool in the lab. The habit of asking "what should the client see?" before shipping — that's the control. The server migration is just the implementation.