Skip to content
Tilfang
Get in touch

Business model

Enterprise deployments first. Network economics later.

Concept stage · nothing priced, nothing sold

These are hypotheses to validate, not commitments, and no price appears anywhere on this page — at concept stage a number would be a guess wearing a decimal point. What can be stated is the unit the money would attach to, and what has to be true before each stage is reachable.

  1. First

    Enterprise deployment

    One organisation runs the registry, planner, policy layer, and adapter environment inside its own boundary — against its own resources, its own approval chains, and the audit record its auditors already read.

    What it would be charged againstThe deployed environment, sized by the scope it governs: how many capability classes are registered, how many adapters are cleared to act. Not per seat — the people who approve a mission are not the ones who plan it, and per-seat pricing keeps the compliance owner out of the room.

    What has to be true firstOne customer whose compliance owner will sign one narrow scope. It sells into a budget line that already exists — inspection, monitoring, operations — which is why it can be first. Its weakness: it compounds nothing unless each deployment leaves a reusable capability description and a cleared adapter behind.

  2. Then

    Usage-based orchestration

    Once missions repeat, part of the price follows what is used rather than what is installed: missions compiled, resources orchestrated, analysis performed.

    What it would be charged againstThe mission — what the customer asks for, what the plan is bounded by, what the evidence record is filed under. Resources booked and analyses run sit beneath it as second-order units.

    What has to be true firstEnough missions per customer that the line means something other than a licence in instalments. Its weakness is structural: usage pricing taxes the behaviour the concept wants more of, so planning, comparison and simulation have to stay cheap and the price sit where a result is delivered.

  3. Later

    Provider-network economics

    When supply exists beyond one organisation’s own assets, a third-party capability could be booked through the network — and the layer that made it bookable would charge for the booking.

    What it would be charged againstThe booking, plus adapter onboarding and certification as distinct one-off work. Certification means the scope clearance described under Defensibility on the front page, not a regulatory approval.

    What has to be true firstVerified supply: providers whose capabilities are described precisely enough to be matched and governed, and cleared adapters to reach them. That chicken-and-egg problem is why this stage is last, not why the plan is wrong — the first two would produce the supply. It is still the least evidenced part of the model.

Before any of the three

Those three describe a product being sold. The first invoice would not be for a product — and saying so is more useful than making early revenue look like software revenue.

A paid discovery engagement

Bounded work inside one operation: take a recurring objective the organisation already pays for, describe the capabilities it actually needs, inventory which of its own and its providers’ resources could supply them, and write the plan and approval path a governed version would follow. The customer keeps that document whether or not anything is ever deployed.

What it does not proveThat a product exists. It is consulting revenue, tested where the thesis is weakest: whether an operator can describe a real asset in a shared vocabulary. What would turn it into a product is the same work getting faster on the second customer, because the first left a reusable capability class behind. Otherwise this is a services company with a good architecture diagram.

Why in-boundary, and not a network

The resources a first customer would orchestrate are largely already theirs or their contracted providers’, and the approval chains and audit record they answer to sit inside one boundary. A network asks a compliance owner to sign an outbound flow to parties they hold no contract with, before anything has been demonstrated. In-boundary asks for the smaller signature.

What it does not proveThat it scales by itself. It is the shape with no network effect: one deployment makes the next no easier unless it leaves behind a capability class, a cleared adapter and a governance pattern that the next one reuses — three of the six assets named under Defensibility on the front page, and this is the stage that would pay for them.

The stages assume the pilot proves the mission model, and the roadmap says in which order the rest would be earned.

See the roadmapBack to the pitch