Two years on Web3, and what I got wrong with 21BJ and Sp3llbound

In May 2025 I shut down two projects in the same month: 21BJ, a fantasy card game for mobile I had been working on since April 2023, and Sp3llbound Studios, the Web3 development studio started in June 2024. Twenty four months on the first, eleven on the second. Nothing sellable at the end of either.

The mistake was not technical. The code worked, the builds shipped, the game was playable. The mistake was building for a market I assumed instead of testing, and then continuing to build after the numbers said it was not there.

Why two years never produced a market

Because I never tested the market: I assumed it. In 2023 Web3 gaming was a premise circulating everywhere in my environment, and I treated it as settled fact instead of as the riskiest hypothesis in the project.

21BJ was a fantasy casino with no real gambling. On paper it resolved a specific tension: casino gameplay without the risk of losing money. In practice I never found the people who actually felt that tension. People who want the thrill want real money. People who do not play something else. The audience sitting exactly in the middle was one I had imagined.

Sp3llbound came after, and it was the worse mistake: instead of questioning the premise, I doubled it. I decided the problem was execution rather than direction, and opened a studio to execute better. I built a larger structure on top of a hypothesis I had still never verified.

The three signals I ignored for twenty four months

It was not a sudden collapse. It was three small things, repeated for months, each with an explanation ready so I would not have to look.

Users signed up and did not come back. I explained it with onboarding. I rebuilt onboarding three times. It was not onboarding: they had no reason to return.

I always had to add a sentence to make the problem land. Every time I explained the product, it took thirty seconds of setup before the other person nodded. When a problem is real you do not need the setup: the person interrupts you to say they have it too. If you have to explain the problem, they are not feeling it.

I only worked on features. Not distribution, not pricing, not talking to people. Features were the comfortable part: measurable, controllable, and they gave me the feeling of having done something by the end of the day. Distribution and pricing were where I could find out I was wrong, so I kept postponing them.

The common thread: every signal came with an explanation that moved the problem onto something I knew how to fix. I know how to fix an onboarding problem. I do not know how to fix a market problem. So every time, my brain picked the first version.

The question that ended it

I put it like this: if I started from zero today, knowing what I know now, would I start this project again?

No. Not either of them.

And if the answer is no, every extra day is a choice I would not make. It is not a failure: it is realising I was still paying for a decision made eighteen months earlier rather than making a new one. The months already spent were gone in every scenario. The only thing still in my control was to stop adding more.

The question works because it separates two things that usually stick together: how much you have already invested and how much it is worth investing from now on. The first is a historical fact, not a reason.

The practical checklist for shutting down without doing damage

Once I decided, I did things in this order. Sp3llbound had co-founders, so step zero was putting it in writing between us before communicating anything outside.

1. Turn off payments before anything else, so nobody pays for a service that is ending. It is the step with the most legal and reputational consequences if you get it wrong.
2. Tell active users with a specific date, not a vague "soon". A date lets people organise. A "soon" leaves them hanging and gets you emails for weeks.
3. Give them a data export without making them ask. If someone has to open a ticket to get their own things back, you have turned a shutdown into one final bad experience.
4. Keep the domain and a page explaining what happened. It costs ten euros a year and stops the only result about you being an expired domain full of spam.
5. Write down what did not work, while you still remember it clearly. This is the step everyone skips and the one that matters most. Two weeks later you only remember the comfortable version of the story, the one where the market was not ready.

Step five is why this article exists. It is also why 21BJ and Sp3llbound are still on the projects page with the same space as the live ones.

What I kept

Almost none of the code. What stayed are three habits I still use.

Talk to people before building, not after finishing the first version. Measure the return and not the signup: how many come back the following week is the one number I never looked at in 2023. And put an expiry date on every bet: if by that date a specific thing has not happened, I close. The date gets decided while you are clear headed, at the start, not when you are already in up to your neck.

I came from physics, and the stupidest part of this story is that physics had already taught me those habits. A hypothesis is worth nothing until you test it, and data does not negotiate. I applied that to the code for two years and never to the market.

The same three habits are what made it possible to build and sell Bitzuma in five months, a few months after shutting these two down.

Frequently asked questions

How long did it take you to realise 21BJ was not working?

About a year to suspect it, another twelve months to admit it. The delay was not in understanding. It was in accepting that the months already spent were not an argument for continuing.

Was shutting down two projects at once a coincidence?

No. Sp3llbound existed to execute the same premise as 21BJ better. When the premise fell, they fell together. That is the risk of building your second project on top of the unverified hypothesis of your first.

Do you regret working on Web3?

Not the sector, but the method. The problem was not choosing an uncertain market. It was failing to treat it as uncertain, and therefore not testing first the thing that could bring everything down.

How do you decide whether a project is worth it now?

The first two weeks go into finding people who already have the problem and are using something inconvenient to solve it. If I cannot find them, it does not start. I wrote about it in from co-founder to solo founder.