Web3 Development for Products, Not Pitch Decks
On-chain products that hold no keys, read clearly to non-traders, and ship with the code in your hands.
We build and run our own on-chain products, which is a different discipline from building one for a launch. It means we have already met the parts that only appear in production: an RPC provider having a bad day, a wallet that changes its behaviour on an update, a user who has no idea what a nonce is and should not have to.
The decisions that matter first
- Custody. Whether your product ever holds a user's keys or funds changes the regulatory picture, the insurance picture and the engineering picture. Our default is that it does not.
- What actually needs to be on chain. Most of a Web3 product is ordinary software, and putting something on chain because it sounds better is how projects buy irreversible bugs.
- Upgradeability. Contracts that can be changed need a governance story; contracts that cannot need certainty before deployment. Both are defensible, silence is not.
- Who pays for gas, and what the interface says when the network is congested and the fee doubles between quote and confirmation.
What we build
- Product front ends over existing protocols: staking, portfolio and market interfaces that a non-specialist can use without a tutorial.
- Smart contracts where the product genuinely needs them, written plainly, tested against the failure cases rather than the happy path.
- The unglamorous half: indexing, on-chain reads that stay fast, transaction states that survive a refresh, and a clear message when a chain reorganises.
- Token and treasury tooling for teams who have shipped the product and now have to operate it.
What it costs
- 6-12 weeks for a product front end over an existing protocol
- audit budgeted separately, before anything holds value
- 0 of your users' keys in our custody
The product has to be usable by someone who does not care that it is on chain. That is the whole test.
Frequently asked questions
Do we need a token?
Usually not, and the question is worth resisting until the product works without one. A token adds regulatory exposure, market dynamics you now have to manage, and a second full-time job. When it is genuinely part of the mechanism we will build it; when it is a fundraising instrument looking for a product, we will say that too.
Which chain should we build on?
Where your users and your liquidity already are, which is rarely the chain with the best developer marketing. The choice affects fees, finality, tooling and who can integrate with you later. We work across the main ecosystems and will give you the trade-off in writing rather than a preference.
How do you handle security?
Non-custodial by default, so the worst case is bounded. Beyond that: contracts kept as small and readable as the product allows, tests written against the ways things actually fail, an external audit for anything holding value, and monitoring after deployment, because a contract is live software that people are financially motivated to break.