Build or Buy
We sell a white-label platform, so treat everything here with the scepticism that deserves. What follows is our honest reading of when licensing software is the right decision, when building your own is, and the documented cases where the white-label model has gone wrong — including for reasons that would apply to us.
Start with the finding that matters most
The largest exchange failures in the industry's history — Mt. Gox, QuadrigaCX, FTX — were not caused by the trading engine. They were custody and governance failures. Mt. Gox lost keys and concealed the loss. QuadrigaCX concentrated sole key control in one person who died. FTX moved customer assets to an affiliate.
This should reframe the whole build-or-buy question. The decision you are agonising over — whose matching engine, whose order book — sits well down the list of things that actually destroy exchanges. Where the assets sit, who can move them, and who checks, sits at the top. A platform choice that improves your custody posture is worth more than one that improves your latency, for almost everyone reading this.
It is also, in fairness, the argument that most favours our architecture. Weigh it accordingly.
The straight comparison
| Dimension | Build in-house | Licence a platform |
|---|---|---|
| Time to first live trade | 12–24 months, realistically, for something you would trust with real money | Weeks to a few months, dominated by your licensing rather than the software |
| Cost profile | High fixed cost, front-loaded, and it does not stop at launch | Lower entry cost, ongoing fee, and a share of your success if royalty-based |
| Total cost at scale | Can be cheaper once volume is high and the team already exists | Royalties compound. At sustained high volume, this is the model's weak point |
| Control over roadmap | Complete | Partial. You are one voice among the vendor's customers |
| Talent required | A standing engineering and security team, permanently | Integration and operations capability, not core platform engineering |
| Security burden | Entirely yours, including audits you commission and pay for | Shared, but you still own your configuration, your keys and your custody |
| Regulatory posture | Nothing to explain about third parties | Your regulator will ask about vendor dependency, oversight and exit |
| Differentiation | Real, if your edge is genuinely in the trading mechanics | Limited at the core. Differentiate on market, service and distribution instead |
When you should not buy from us
There are situations where licensing any third-party platform, ours included, is the wrong call. If you are in one of them, we would rather say so now than eighteen months in.
Your edge is the mechanism itself
If your product thesis is a novel matching model, a settlement design nobody else has, or a market microstructure you intend to defend, that is your company. Do not outsource it. Licensing a generic engine to express a specific mechanical edge is a contradiction.
You already have the team
If you employ a competent exchange engineering group with security depth, the economics invert quickly. Their marginal cost is already sunk; a royalty is not. Buying to save time you do not need to save is just a tax.
Very high sustained volume
Basis-point royalties are pleasant at launch and painful at scale. Model your fee at your three-year volume target, not your first-year one. If the number offends you, that is useful information and you should act on it now rather than renegotiating later from a weak position.
Your regulator will not accept the dependency
Some regimes — Hong Kong's VATP rules are the clearest example — expect a licensed operator to demonstrate genuine control over its critical systems. That is answerable with escrow, documentation and audit rights, but if your supervisor takes a hard line, find out before you sign, not during the application.
Where the white-label model has actually failed
These are structural failure modes with documented history in this sector. We are naming them because a vendor that pretends they do not exist is not a vendor you should trust.
Vendor lock-in with no source access
The most-cited structural risk in the sector, and it is levelled directly at the largest incumbent providers. Where a platform is closed-source and SaaS-only, a change in pricing, a change in strategy, or the vendor's own failure leaves the operator with no continuity path — migration means rebuilding, under time pressure, with a live customer base. Industry commentary is consistent that the right diligence question is simply whether you get source access, and that a vendor's reluctance to discuss it is itself the answer.
Our position: ask us this question directly and hold us to the answer in the contract. Escrow and exit terms belong in the agreement, not in a sales conversation.
Compliance responsibility misunderstood as transferred
The recurring commercial failure is an operator believing that buying a "compliant platform" makes them compliant. It does not, in any jurisdiction on our regulation index. Software can enforce a KYC threshold; it cannot hold your licence, file your suspicious transaction reports, or answer to your supervisor. Operators who discover this during an examination rather than before one tend to discover it expensively.
Our position: we say this on the compliance page too, because it is the single most common and most damaging misconception about what we sell.
Shared-tenancy blast radius
Where a provider runs many customers on shared infrastructure, one customer's incident, one customer's regulator, or one customer's compromise can reach the others. This is a design decision, and it is worth asking any vendor to describe theirs precisely — not what they call their tiers, but what is physically shared between two customers.
Our position: isolation per customer is why we deploy the way we do. It is also why we are not the cheapest option, and we would rather be straightforward about that trade than hide it.
Roadmap divergence
Over a few years, a vendor's product direction and one customer's needs drift apart. The customer wants a feature that serves their market; the vendor prioritises what serves the majority of its book. Neither party is behaving badly and it is corrosive anyway. The usual endpoint is an expensive fork or an expensive migration.
Our position: there is no clever answer to this. It is a genuine cost of the model. Ask about it at renewal, every time.
Where it has worked
The pattern in the successful cases is consistent, and it is not about the technology.
Distribution already exists
Firms that arrive with customers — a broker adding a crypto line, a fintech with an installed base, a regional player with licensing and brand — are the clearest wins. Their scarce asset is the customer relationship, not the engine, and buying the engine lets them spend their time on the thing only they can do.
Regulatory clock is the binding constraint
Where a licence has a launch condition or a market window is closing, twelve months of platform engineering is not available at any price. Buying converts an engineering schedule into a procurement decision, which is a much more controllable thing.
Testing a market before committing
Proving demand on licensed software and then deciding whether to build is a sound sequence. The mistake is inverting it — building first, then discovering the market was not there. The option value of not committing engineering capital early is real.
Custody is the actual problem to solve
Given where the historic failures came from, an operator whose main risk is custody design is better served adopting a non-custodial architecture than building a custodial one badly. This is the strongest case for our specific approach and we think it holds.
A note on live references
We are not going to fabricate case studies. MiddleMint's escrow core has been built and fork-tested against real stablecoin contracts on a public testnet, and the cost thesis held under stressed gas assumptions. It has not yet run a production book of third-party customer funds, and we will not imply otherwise — a vendor's first customer has to come from somewhere and pretending otherwise is how this industry earns its reputation.
What we will do is show you the test results, walk you through the architecture with your own engineers, and support an independent security audit before any real money moves. If you need a vendor with a decade of production references, that is a legitimate requirement and we are not it yet. If you want to see the work and judge it yourself, we will open it up.
Still deciding?
We will run through this analysis against your actual numbers — volume, jurisdiction, timeline, team — and tell you if you should build instead.
Have that conversation