The part you cannot hire

By ·

You can hire someone to go and find out why your system does what it does.

What you cannot hire is not having to.

Nobody designed it to be incoherent. The founders built it while the business moved under them, and it worked. Then there were things only they knew. Then there were more of those things than two people could keep in their heads.

That is when the req gets written. Two senior engineers, costed and waiting for a signature. Salary, employer contributions, pension, a start date. This is a good page, and every number on it is checkable.

What it does not price is the months before you can trust the answers they give you.

Because somewhere in that system is a rule the business decided on purpose, and beside it is a rule that is only what happened: a workaround from a migration that nobody took out. The code runs both the same way and does not say which is which. Working that out is not onboarding. It is archaeology, and it runs in both directions: the new engineers spend their first months digging, and the people who already knew spend them explaining.

Nor does it price the morning one of them resigns, when the answers leave with them and the page gets written again.

That is not a failure of the hire. It is what a moving business does to a system that has no way of telling you where it moved and why.

Hiring does not buy you time. You spend it first, on a bet: that they stay, and that you were right to trust them.

I know that page from the other side. I approved systems I could not read, and I was right to trust the people who built them, and I still never had a way to check.

That is the part we built Ficus to change. It is the infrastructure a product gets built on, and it carries the business model with it: the entities and the rules that govern them, declared, beside the code that runs them. That is the part that says which is which.

Plenty of teams already do that much — domain-driven design has been saying so for more than twenty years. What it does not give you is a check. The model stays true because people keep it true, from memory, in review.

So the platform reads what is actually running and holds it against what was declared. It has three answers: they agree, they have come apart and here is where, or nobody has measured this yet. We do not promise a system stays coherent. We measure whether it is.

We pointed it at our own backend and it came back red. It certified what it had measured and named what it had not, and we published it that way. We would rather be told than reassured.

Somebody will still know the system best. They stop being the only copy of it: the CEO, the CFO, the VP of Engineering and the engineer are reading the same thing, and it is the system that says it.

You would still write the req. The system would still move. What changes is which half of it they build: the product on top, which is the half that is yours, and not the infrastructure under it, which was never anybody's differentiator.