Short answer
We declined all four blockchain-adjacent briefs that came to us in early 2022 because in each one the chain was decorative rather than load-bearing. The NFTs were membership tokens that could just as easily have been accounts in a database, the on-chain transactions were loyalty points a ledger would handle, and the decentralized marketplace was going to have a central operator making most of the decisions. What the blockchain element added was cost, complexity, and a dependence on infrastructure the client did not control. What it did not add was a meaningful improvement over the centralized alternative.
The Web3 conversation is everywhere right now. Studios are pivoting their positioning to catch the wave. Clients are asking whether their product needs an NFT component. We have had four conversations in the past two months with people asking us to build blockchain-adjacent products.
We declined all four. Here is the reasoning.
We Are Not Anti-Crypto
This is worth stating clearly before getting into the skepticism. Blockchain technology has legitimate applications. Decentralized finance, transparent supply chain verification, certain types of provenance tracking - these are real use cases where the properties of a distributed ledger create genuine value that a centralized database cannot replicate.
We are also not dismissing the cultural phenomenon. NFTs have been meaningful for some creators. The DAO model is an interesting organizational experiment. There are builders in the Web3 space who are working on real problems.
Our position is narrower than blanket skepticism: we are not the right studio for projects where the blockchain component is decorative.
The Four Briefs We Saw
Each of the four conversations we had this year fit a recognizable pattern.
The brief started with a product concept - a marketplace, a loyalty program, a membership community, a game. The concept was reasonable on its own merits. Then somewhere in the description, there was a blockchain element that had been added to the concept but was not load-bearing. The NFTs were the membership tokens, but they could just as easily be accounts in a database. The on-chain transactions were the loyalty points, but a ledger would work. The "decentralized" marketplace was actually going to have a central operator making most of the decisions.
The blockchain element in each case added: cost (smart contract development and auditing is expensive), complexity (users need wallets, gas fees are friction, key management is a real support burden), and a dependence on infrastructure the client did not control. What it did not add was a meaningful improvement over the centralized alternative.
When we asked each client why the product needed to be on a chain, the answers were some version of "it is the future" or "our investors expect it" or "it adds credibility." These are not technical answers. They are marketing answers.
What We Told Them
We told each client the same thing: we can help you build the product. The blockchain component, as currently scoped, is not adding value commensurate with its cost and complexity. If you can identify a specific property of a distributed ledger - immutability, trustless execution, decentralized ownership - that your users genuinely need and cannot get from a traditional database, we would build it that way. If you cannot identify that property, we would recommend building without the chain and revisiting the decision when the product has real user data to inform it.
Two of the four clients were receptive. Those conversations are continuing. The other two wanted studios that would build the blockchain component without pushing back on the rationale.
What This Means for Our Positioning
We are not positioning as a Web3 studio. This is a deliberate choice in a market where positioning that way would attract work.
Our reasoning: work we are not aligned with is bad for clients and bad for us. If we build a product we do not believe in architecturally, we are not able to give the client honest counsel. The technical decisions made for the wrong reasons accumulate into systems that are hard to maintain and harder to evolve.
We would rather be a studio that builds the right thing than one that builds the fashionable thing.
If you have a product brief that includes a blockchain component and you want an honest technical review before you commit to the approach, we are happy to have that conversation.
Questions · 05
Frequently asked questions
Does this mean you refuse to build anything on a blockchain?
Our position is narrower than blanket skepticism. Decentralized finance, transparent supply chain verification, and certain kinds of provenance tracking are real use cases where a distributed ledger creates value a centralized database cannot replicate. If you can identify a specific property your users genuinely need, such as immutability, trustless execution, or decentralized ownership, we would build it that way.
What does adding a blockchain component actually cost a project?
Smart contract development and auditing is expensive on its own. On top of that comes complexity your users absorb directly: wallets to manage, gas fees as friction, and key management as a real ongoing support burden. Then there is the dependence on infrastructure you do not control.
What reasons did clients give for needing a chain?
Some version of it is the future, our investors expect it, or it adds credibility. Those are marketing answers, not technical ones. Two of the four clients were receptive when we said so and those conversations continued; the other two wanted studios that would build the blockchain component without pushing back on the rationale.
Why not position as a Web3 studio when it would attract work?
Because work we are not aligned with is bad for clients and bad for us. If we build a product we do not believe in architecturally, we cannot give the client honest counsel, and technical decisions made for the wrong reasons accumulate into systems that are hard to maintain and harder to evolve.
What if I want a second opinion on a brief that includes a chain?
That is a conversation we are happy to have. The useful test is whether you can name the ledger property your users need and cannot get from a traditional database. If you cannot, the practical recommendation is to build without the chain and revisit the decision once the product has real user data to inform it.
