Build or buy: what it costs to connect to onchain markets yourself
Every good engineering team looks at onchain markets and thinks: we could build that. They are right. The question is what it costs, how long it takes, and what you are not doing in the meantime.
The markets are public and the code is open. Nothing stops a bank or fintech from connecting to them directly, and some should. This post sets out what that build involves, puts numbers on it, and says plainly when building is the better choice.
The figures are our estimates, based on what we have built ourselves and what platforms tell us they budgeted.
What you are actually building
The first version looks small: connect to one lending market, let customers deposit, show a balance. A capable team ships that prototype in weeks. The work that follows is what fills the next year.
- Each market is its own integration. Lending and trading venues each have their own contracts, quirks and upgrade schedules. The second market is not a copy of the first.
- Each network multiplies it. The same market behaves differently across networks, and customers expect you to support more than one.
- Multi-step actions have to be made safe. Swapping, rebalancing your portfolio, depositing and borrowing in one customer action means bundling steps so they all succeed or none do. A loan against a tokenized fund, with reinvestment and exit, is 37 separate transactions across three venues if you build it step by step.
- You need a way to charge. Taking your own fee inside a transaction means writing, auditing and maintaining a contract.
- Customers should not pay network fees. Hiding them means running your own fee-sponsoring service.
- Data is a second product. Rates, prices, positions and transaction history have to be read from the blockchain, stored and kept correct for reporting.
- Then it changes. Markets upgrade, new assets launch, networks appear. Each change is work for a team that has to stay on staff.
The numbers, side by side
| Build it yourself | Use Compass | |
|---|---|---|
| Team | About 5 engineers with onchain experience | 1 or 2 of your existing engineers |
| Time to first customer | 12 to 18 months | Days for the integration, plus your own reviews |
| Upfront cost | About $2.5M | Usage-based, no build cost |
| Yearly upkeep | About $1M | Included |
| Adding a second product | A new build | Same integration |
| Adding a market or network | A new integration each time | Already connected: 20,000+ venues on five networks |
| Who maintains it when markets change | You | Compass |
We assume five senior engineers with onchain experience at about $300k each per year, fully loaded (salary, benefits, equipment and overhead). Over 12 to 18 months that is $1.5M to $2.3M in people, plus roughly $300k to $500k for independent security audits and infrastructure. Upkeep assumes three of those engineers stay on, plus a re-audit each year.
The two costs that never make the budget
The upkeep. The $2.5M is the number teams plan for. The $1M a year afterwards is the one that hurts, because it never ends and it buys nothing new. It is the price of standing still while the markets underneath you change.
The wait. For every $100M of customer money that could be earning yield, each year spent building leaves roughly $4M on the table at a conservative 4% yield. An 18-month build on that base costs more in missed yield than in salaries. Your competitors' customers are earning it in the meantime.
When you should build
Building is the right call more often than vendors admit. It makes sense when:
- You need one market and one product, and that will not change. A single integration is manageable, and a layer in between adds little.
- The integration itself is your edge. If how you route, price or structure the product is what customers pay you for, own it.
- You already employ the team. Protocol engineers, a security function and round-the-clock operations are sunk costs for you, not new hires.
When you should not
- You expect more than one product. Yield now, loans next year, tokenized assets after that. Each is another build.
- Onchain engineering is not what you sell. Your customers chose you for your app, your brand or your licence. That is where your engineers should be.
- Speed matters. A product live this quarter teaches you more than a perfect one in eighteen months.
Five questions to settle it
- How many onchain products will we offer in two years?
- Do we employ engineers who have shipped onchain products before?
- What does each quarter of delay cost us in customer yield and in customers lost?
- Who on our team will own this when a market we depend on changes?
- Is the integration what our customers pay us for?
If the answers are "more than one", "no", "a lot", "nobody" and "no", you have your answer.
Weighing a build? Bring us your plan. We will tell you which parts Compass replaces, which it does not, and what your team would still own.
Ready to build?
Start at docs.compasslabs.ai, or talk to us at compasslabs.ai.