Founder Notes — Chapter 4 An iPhone, a Rubik’s Cube, and a stapler are all useful. Put them in one case and you probably get something worse at all three jobs. At one point, we nearly did the
Founder Notes — Chapter 4
An iPhone, a Rubik’s Cube, and a stapler are all useful. Put them in one case and you probably get something worse at all three jobs.
At one point, we nearly did the software version of that with intrade.bar.
Our plan was to put the new trading platform inside the personal account on zylo.io. One ecosystem. One website. One account. Games, trading, and digital services would sit together, and users could move between them from a single entry point.
On paper, it looked elegant. We even spoke about it publicly, because we believed in it.
Then we began to build it.
zylo.io is a new website. It still needs to earn familiarity and trust. intrade.bar already has an audience that knows where to find it and what to expect when it opens. Asking those users to enter through a different site would mean giving up an advantage we had spent years building.
More importantly, someone who comes to trade wants a trading platform.
Not a game. Not a VPN. Not a guided tour of everything else we plan to make.
Imagine opening the address you know and being asked to understand why a space fox and a privacy service are standing between you and the product you came for. We might call that a connected ecosystem. The user might call it an extra step.
That distinction changed the decision.
An ecosystem should not force users to use the ecosystem.
A player should be able to go straight to the game. Someone looking for a VPN should reach the VPN. A trader should arrive at intrade.bar. If they become curious about the other products later, the connection should be there for them to discover.
So we dropped the idea that intrade.bar had to live only inside the zylo.io account. It should keep its own site and familiar entry point. We still want the products to be connected through Zylo and its shared economy, but that connection should make their experience better, not turn the front door into a test of how well they understand our diagram.
It is a fair question. We described one structure, then changed it. Other mechanics and visuals have changed too. If the plans keep moving, what is a roadmap for?
I think of it like a route in a navigation app. It tells you where you are going and which roads you expect to take. If a bridge ahead has been dismantled, you choose another road. You do not drive into the river because a line on the map said to keep going straight.
Our direction is to build products that are useful in their own right and connect them through Zylo. The people who come for a game, a trading platform, or a digital service should not have to study the entire ecosystem before using the thing they wanted.
That is the strategy. The exact interface and entry point are ways to carry it out. When we learn that one of those choices makes a product harder to use, changing it is not a betrayal of the roadmap. Refusing to change it would be stupid stubbornness.
That does not make every new idea a strategy. We should be able to explain each revision. Here, we designed for a neat ecosystem when we needed to design for the person opening intrade.bar.
CosmoFox should remain a game people can enter and enjoy. Our next game needs to stand on its own, as we discussed in the previous chapter. intrade.bar needs to be clear to the traders who already know it. ZYLO should earn a real role inside these products, not merely appear beside their names in a presentation.
Those commitments have not changed.
The original plans gave us a starting point. They should not stop us from making better decisions about the products we meant to build.
We are not changing everything every week. We are gradually replacing assumptions with knowledge.
