Partners before the backend
Let them build now.
Change nothing later.
Every month a partner waits for your backend is a month their integration — and your revenue from it — has not started. Think of it as a Figma prototype for your product: except your customers really use it, it remembers what they do, and it becomes the real thing without them changing a line.
Publish the contract and they call it today, with realistic data and their own credentials. When your service is ready it takes over at the same address, and nothing your partners built has to change.
Free tier · No credit card
Partners start
this quarter.
Integration runs in parallel with your build instead of after it. The time to a partner's first live transaction shrinks by however long the backend takes.
Live from the contract alone
They build
it once.
What partners integrate against is the real address with real credentials. Launch day is not a second integration project on their side — or a difficult conversation on yours.
Same URL · same credentials · same scopes
Find the gaps
before you build.
Partners tell you what is wrong with the design while it is still cheap to change, and launch is a recorded, approved release — not somebody editing a setting.
Governed cut-over, on the record
What your partners call today.
Not a fixture file and not a sandbox on somebody else's domain. The API itself, published on its gateway, answering from its contract until your service is there.
Responses are drawn from your own design — your examples, your wording, your identifiers. What partners see in week one looks like your product, not like placeholder text.
A partner creates something on Tuesday and finds it again on Wednesday. That is the difference between a demo that lasts one request and a pilot that runs for months — and none of it needs your service to exist. Each partner sees only their own records — unless your API's data is open to all — just as they will in production.
Each partner gets their own credentials, limited to what they are allowed to call. Not a shared key passed around, and not a request that waits in another team's queue.
Partners will tell you what is wrong with it — that is the point of showing them early. A change that breaks nothing goes to the version they call. A change that would break them becomes a new version beside it, and theirs keeps serving.
Demand first
Let your customers decide
what you build.
Design a product and customers can find it, subscribe to it and use it the same day — against a stand-in that remembers what they do. Nothing has been built yet.
Every subscription is a vote. Put two or three product ideas in front of customers and the one they sign up for is the one you build first — so engineering time goes to demand you can see, not to a guess.
Launch is a release, not a migration.
When your service is ready, you release it and it starts answering in place of the stand-in. You can move everything at once or a piece at a time. Either way the release is approved and recorded, so there is always an answer to who switched it on, and when. Who has to approve is yours to choose — automatically for a two-person pilot, named reviewers for a bank.
The address they call, the credentials they hold, what they are allowed to do, and every request and response they built against.
Nothing they built has to be changed, redeployed or re-issued.
- Test data does not carry over. They start launch day with a clean slate.
- Your real rules arrive with your service. The more your design describes up front, the fewer surprises.
- Complex behaviour is approximate until then. Search, actions and long-running jobs are best judged against the real thing.
Five things. One contract.
For partners to build before your backend exists and keep working when it arrives, five things have to keep saying the same thing: the contract, the gateway's routes, the stand-in's responses, each partner's credentials and scopes, and — when it arrives — your implementation. Every change to the contract has to be carried to the other four, by hand, with nothing telling you when one of them is behind.
Here there is one contract, and the gateway, the stand-in, the credentials and the checks on your implementation are all generated from it. That is why the stand-in remembers without being scripted, and why partners get their own credentials without anybody issuing them by hand. The case for it is not day one. It is every change after it.
Continue
From Mock to Real
Exactly what stays the same at the switch, what changes, and how to move in stages.
Read more →Mock Data
Where the stand-in's values come from, how dynamic mode behaves, and what it costs.
Read more →Delivering it yourself
Everything the assembled route takes, line by line, beside what is already running.
Read more →