Ten minutes on where drift comes from and how Ficus works, with the full transcript.
Nothing broke. The surface holds. But underneath, what you designed is quietly becoming a different thing. By the time you can see it, everything is standing on it.
That is drift.
Your backend works. But your team is working around it.
It started clean. Everyone agreed on the boundaries. Then you needed to ship. You needed users. You needed revenue. And all three had the same deadline. Good intentions don't survive that. So somebody took a shortcut: writing straight into another service's tables, because the clean way would take two weeks. Then another. Each one justified, each one permanent.
By year three, it is a deploy that needs one specific person awake, a module quietly routed around, features that take longer than they used to. A part of the system that only one engineer can touch. And a question nobody can answer: does it still mean what it was supposed to?
Systems don't break. They decay.
Producing code just got much easier. But understanding what it means is still somebody's job. Google measured three and a half million of its own code changes: what AI wrote was reverted no more often than what people wrote. The cost showed up as maintenance instead, and deeper review did not reliably catch it. They measured the code. The architecture was outside the study.
Drift does not bill you as an outage. It bills you as maintenance — and on a system in production, every feature ships through it. Chainguard asked twelve hundred engineers and technology leaders where their week goes: building was less than one day of it. Four in five called maintenance a major drain on their time.
Most stacks are held together by conventions and discipline. Both of those are things people carry: you are already making the system hold, by hand, every week.
There are three ways to make that last. You can try to encode the discipline — contract tests, a schema registry, ownership checks — and it holds for exactly as long as someone keeps it up. You can put more people on it, and what you buy is more maintenance. You can even rewrite it: agree the boundaries again, build it again, clean. But year three comes round again, for the same reasons: nothing is watching the new one either.
There are two questions here, and engineering uses one word for both. Does the system still do what you told it? That is coherence, and your CI/CD pipeline answers it. Is what you told it still true for the business? That is correctness, and that is a judgment, not a check.
That judgment gets left to your tests. In some teams it is a whole job: developers own the code, QA owns the business rules. It works, until the business evolves. A refund rule changes in a meeting, reaches the code as a ticket, and the test that held the old rule gets edited until the build is green, whether or not the code now does what was decided. From then on, the old rule lives only in the QA lead's memory, and the pipeline is green and wrong at the same time.
You can't out-discipline drift. So we stopped trying.
We built Ficus for teams that already run a backend: a production backend built around a business declaration. It does not wrap what you run: your system moves onto it in phases, one well-bounded part of the business at a time — first the part that costs you most to keep running, or the next market you open — while the parts that have not moved yet keep running where they are. Each part is measured from the day it moves.
The declaration is the contract your business grows on, written into files you can read. One half says what your words mean. Customer. Order. Invoice. What each one is, and what has to stay true of it — like a closed quarter's billed amount, which does not change because an old invoice was edited. The other says how the business is organised: its processes, the services behind each one and how they scale, and the checks that tell you they still hold. The first becomes your database schema; the second, your services and the infrastructure under them.
It is not documentation of what you have. It is what the installation is built from and what it is measured against, so a rule changes there, dated, in version control. Ficus builds the infrastructure around the declaration.
Getting there is the setup. Your people agree what your business means, and before anything is installed, the declaration is checked: no word may mean two things, every reference must point at something declared, and no two services may depend on each other in a circle. Rules test all of that on their own, and then we go through it with you; once the installation is up, your team can re-run those rules at any time. Then that first part is ported onto it — and this time, something is watching it.
How long the declaration takes depends on how clearly you already know your domain; once it is written, installing it is the quick part, and reaching the first deployment is meant to take a week or two. Porting your logic and moving your data is the real work, and most of the logic follows that first deployment. Code already in Python largely carries over as it is; code in another language is translated as it moves. That work includes how the parts that have moved talk to the ones that have not yet, and it is agreed with you, case by case.
The setup ends when the installation runs in your own cloud and its handoff report comes back green on your system. After that, the annual pays for the releases that keep your installation aligned as Ficus evolves. Whether you renew or not, everything already installed keeps running in your cloud, with your keys.
Your code lives on top of what Ficus builds, and it stays yours: product, plumbing, the next market — whatever the business needs, built freely, on a structure that holds it to what you declared. When you need a new module, Ficus generates it from the declaration — model, API and tests — and opens it as a pull request your team reviews. Underneath, it all runs on Django, Postgres and other standard open source. Say a parcel network, a travel business that reconciles bookings, payments and refunds every day, and an insurer that pays claims against a policy: each declares a different business and gets a different system; all three grow on the same structure, and all three are held to what they declared.
With Ficus, the ground a senior team assembles by hand across many repos arrives as one installation: the API, the admin, the async layer, a record of every write and who made it, an isolated database for each subsidiary, country or customer you serve that needs its own, and the end to end suite that runs against it. Once your logic is on it, your engineers' week goes into the product you sell, not into the ground it stands on.
What runs is measured against your own business processes, not a list of machines. Every minute, the checks you declared are read against the live system — for example, that every line item in the catalogue still has a price. Your CI/CD pipeline can be green while one of those checks is red. And a check that cannot read its answer does not show green: it says why — the ledger is empty, the figure is unknown, nothing is wired to measure it.
Each signal answers one question. The checks say what is failing right now, and the moment one turns red, they raise an alert. The drift index turns the last seven days of builds, tests, deploys and health into one score, every hour. The audit reads the code against the declaration, and will not sign a handoff while anything is red. The health report puts the quarter on one page for the CFO — what was billed, what was collected, how long it took to get paid — with each module's numbers under it. Your team's own AI assistant can ask the installation how it stands, read-only, over MCP. So the state of the system stops living in one engineer's head, and whoever answers for it stops needing their word.
Whether Customer, Order and Invoice still mean what the business needs them to mean is a judgment no instrument can make. Every change to them is dated, attributed and versioned in the declaration, and the measurements against it are kept. In a regulated business, that is the change history an auditor asks to see.
We asked our own backend for its handoff report, and it refused to issue one. Its own audit had found one place where the code and the declaration disagreed — a field declared to point at an invoice — and it would not sign until someone verified it.
The CEO who signs the budget, the CFO who reconciles, the CTO who answers for it: all three read the same declaration and the same numbers, so business and engineering have to agree on the definitions, and both can see when the system stops honouring them. Drift still happens. The system does not heal itself: it measures its own, and puts a number on it before it becomes the rewrite.
Change nothing, and nothing will break. You will go on dragging it, every week, and paying for it as maintenance. Or you let the system hold to what you decided. It starts with your domain, written down by you, with us, and an installation prepared for your case. Send us a plain description of your business through the contact form at ficus.center — no code, no data, nothing under NDA. We will send back a first draft of your declaration, and once it is right, we can install it, so you see your own business running on Ficus.
Your code will change. Your system shouldn't.