Common questions before the call: system vs framework, what the annual fee actually buys, deployment, how drift gets measured, custom logic, migrating away, and pricing.
A starting point gives you the first week. It scaffolds a project and then leaves: it doesn't provision your cloud, it doesn't isolate tenants at the database level, it doesn't validate anything after day one, and two years in it can't tell you how far the system has drifted from what you designed.
Ficus is the opposite trade. The first week is a command.
What you pay for is the twenty-fourth month: the releases that keep your installation aligned as the core evolves, and the evidence that says whether it still is.
No. The annual fee is not support. It pays for the successive releases that keep your installation aligned as the core evolves —the measurement layer included: a Drift Index recalculated hourly, a Health Check and an Audit, issued on demand.
Without it, you keep the system and its measurement, as they are today. What stops is the next release.
Django is a building block. Ficus is a complete system built on top of Django —infrastructure, deployment, multi-tenancy, and background processing designed together from day one. Stack: Python 3.13 · Django + DRF + Channels · PostgreSQL (one isolated database per tenant) · Redis · Nginx.
You don't assemble it. You inherit it.
Yes. Ficus deploys into your own cloud account —your data never leaves it. Our deployment automation currently targets Google Cloud; AWS and Azure support is on the roadmap.
Ficus manages provisioning, secrets and configuration automatically.
Today each deployment runs in a single Google Cloud zone, with automatic backups and point-in-time recovery —so your data stays protected and recoverable.
Multi-zone high availability is on the roadmap.
The E2E suite checks that APIs respond as expected, background jobs complete, tenant routing behaves correctly, and real user flows succeed end to end —against the same topology you receive, not a mock.
That tells you nothing broke. It doesn't tell you how far the system has moved.
So the result doesn't stop at the pipeline: it feeds your Drift Index, recalculated hourly against the live system, where drift surfaces whether or not a test failed.
It would be, if the instrument could only ever agree with us. The Audit has six layers, five of them computed live by reading the code against what it declared —a baseline layer is one the installation inherits rather than measures. Only the computed layers can certify —a baseline layer cannot lend its green to the verdict, and an Audit with no computed layer reads amber, not green. Absence of signal is not success.
We run it against our own production system. In July 2026 —when it had two computed layers— the Audit came back red on both, and the Handoff was refused: HTTP 400 —a Handoff cannot be issued with a red status. It refused again on 6 August 2026, on one layer. That same morning, reading amber, it had issued one —the lock bites on red, and only on red.
The instrument has grown since: FA-2026-0001, measured 1 September 2026, reads red —with five of its twenty-one subchecks returning no verdict at all.
A measurement is only worth something if it can return the verdict you didn't want. Ours did.
Yes, read-only. Ficus includes an MCP server your team's own assistant can query: the Drift Index, the latest Audit, live health checks, open criticals, process health by quarter, and receivables.
It is bound to one installation when it starts. It can't write, run actions or recalculate anything —it serves the last measured state, and where there is nothing measured to serve, it says so instead of answering green.
Your agent can ask the system how it stands. It can't change the answer.
The annual fee covers system evolution, reliability improvements, and the measurement that says whether your installation is still aligned —not a support ticket queue. When the core improves, it ships to every client on the same release.
You talk to Daniel or Natalia directly.
The system doesn't stop working —everything that was deployed stays yours and keeps running.
What stops is the alignment: architecture improvements, reliability updates and new capabilities ship to all clients while the fee is active.
Without it, the system keeps running and keeps measuring itself —against the release you stopped on, while the core moves on without you.
Yes. Ficus governs the infrastructure layer —deployment, multi-tenancy, secrets management, background processing, and E2E validation. Your application code lives on top: your data models, your API endpoints, your business logic.
You own and write everything above the infrastructure layer.
Ficus doesn't constrain how you build your product —it constrains how the system runs.
What you deploy runs in your own cloud on standard open-source —Django, PostgreSQL, Redis, Nginx— with no dependency on us to keep operating.
If we ever weren't around, you'd have a working Django application on standard infrastructure any engineer can run —the same answer as migrating away.
You're not betting on us being around —you're inheriting a system that runs without us.
It runs in two phases. The first is ours: we agree with you how your data gets exported, and we turn your draft domain into its production version —entities built to hold all of that data, with nothing lost on the way. It ends at your first deployment, and is meant to take a week or two.
The second is led by your team: porting your application logic and moving the rest. When it starts, the new system does little more than basic CRUD —but on a foundation built to carry everything else.
A week or two buys the first deployment, not the whole migration. How long the rest takes depends on how much of your business lives in your application code —and it is agreed with you before it starts.
Code already in Python largely carries over as it is —often without revisiting the algorithms.
Code in another language is translated as it moves, not rewritten. With AI that is quick when the code is well understood and tested. Code nobody can refactor is hard to move into any language —that is the real condition, not the language.
It's not a rewrite. It's an upgrade.
Through a migration plan written for your system, agreed with you case by case before the work starts. There is no tool of ours in between: what moves when, and how each side reaches the other, is part of that plan.
We don't sell a generic bridge. Coexistence is planned with you, for your system.
Your data and application code are yours from day one. The underlying stack —Django, PostgreSQL, Redis, Nginx— is standard open-source tooling that any engineer can work with independently.
If you move off Ficus, you have a working Django application on standard infrastructure. There's no proprietary data format or lock-in at the application layer.
The migration cost is rebuilding the deployment and infrastructure layer yourself —which is exactly the cost Ficus was built to eliminate.
The setup fee starts at 50,000 EUR and scales with the complexity of your domain: whether you're starting fresh or integrating with an existing codebase, your isolation and regulatory requirements —DORA, data sovereignty— and the scope of the E2E validation suite.
The annual fee starts at 50,000 EUR and scales with how many isolated units the measurement has to cover —a subsidiary, a country, a legal entity. One certification covering N units, not N certifications. Beyond 15 units it is priced per deal.
We cover both in the 30-minute call —there's no point quoting a number before we understand what you're building.