Most of web3 is a normal product with a hard back end.
The contract is the easy part to talk about and the smallest part of the work. What decides whether anyone uses it is everything around it: keys, gas, failed transactions, and a wallet flow that does not lose people at step one.
Onboarding is the product's hardest screen
Seed phrases, network switching and a first transaction that needs gas the user does not have. Most web3 products lose the majority of their users before anything on-chain happens, and that is an interface problem long before it is a protocol one.
Transactions are slow, public and sometimes fail
A pending state that lasts minutes, a failure that still costs money, a reorg that undoes what the interface already confirmed. Products designed around the assumption that a write succeeds immediately break constantly, and the recovery path is where trust is won or lost.
Deployed logic is difficult to change
A contract in production is close to permanent, and the upgrade patterns that soften that come with their own trust tradeoffs. This inverts normal product development: the parts you would usually iterate on are the parts you have to be right about first.
Reading the chain is its own infrastructure
Serving a history, a balance or a leaderboard means indexing, and indexing is a real system with a real failure mode. Teams that budget for the contract and treat the read path as a detail find out otherwise once there is data.
Product first, chain where it earns its place
The first question is which parts genuinely need to be on-chain. Usually it is fewer than the initial plan assumes, and the product gets faster, cheaper and easier to use for every part that comes off it.
Designed for the failure path
Pending, failed, stuck and retried are designed as real states with real copy, because in this domain they are ordinary rather than exceptional.
Security review is not optional
Anything holding value gets reviewed by people whose job that is. We will tell you when a build needs an audit we are not the ones to perform.
None, stated plainly. Nemo has not shipped a web3 product, and there is no adjacent work here worth stretching into a claim. This page describes how we would approach the domain and what we think is actually hard about it. If you need a studio with shipped on-chain work, that is a fair requirement and we are not it today.
Questions we getHave you shipped a web3 product?
No. This is the one industry on this site where we have no relevant work to point at, and it would be easy to blur that and we are not going to. Our position is that most of what makes these products succeed or fail is ordinary product engineering, which we do have a record in.
Do you write and audit smart contracts?
We build the product around them and work with your contract engineers. For anything holding meaningful value, a specialist audit from a firm that does only that is the right call, and we will say so rather than take the work.
Does our product actually need a blockchain?
Often not, and we would rather establish that in discovery than after a build. When the honest answer is that a database would serve users better, that is the answer you will get from us.
Discover how partnering with Nemo can drive your success and prepare you for what's next.