Before you add accounts and a database, ask whether the state could simply live in the link. For a lot of turn-based or shareable products, it can.
The default for a new product is a back end. Sign-up, a database, an API, a server to keep running and a pile of user data to protect. Sometimes all of that is necessary. Often it is there because it is the default.
There is another option for some products. Put the whole state in the URL, after the #, and let people pass it to each other.
Why the part after the # is different
Everything after the # in a web address is called the fragment. When a browser loads a page, it sends the address to the server without the fragment. The fragment stays in the browser, where the page's own code can read it.
That means you can put data there, and the server that hosts your page never receives it. Your hosting can be a plain static site. There is no account to create, no database to run and nothing on your side to breach.
How BreakFriend works
BreakFriend is a fort duel you play with a friend over texts. You build a fort on a floating island, then fire at theirs. It is a small game from Break n Break, my games studio.
There are no accounts and no game server. Each move is a link.
When you finish your turn, the game packs everything into a few hundred characters after the #: both forts, both players' sunstone (the game's currency), the names, and the shot you just took. You send that link to your friend in any messaging app. They open it, watch your shot play out, take their turn and send a new link back.
Play it free at breaknbreak.com/breakfriend.
Three details that make it work
Putting state in a link sounds simple. A few details make the difference between a demo and something people can rely on.
Pack it tightly. BreakFriend does not put readable text in the link. Each fort piece is packed into two bytes: its type, column, row and health. The whole game is then encoded in a URL-safe alphabet. That keeps a full game short enough to paste into any chat.
Make replays identical. The friend needs to see the same shot you saw. So the simulation that flies the shell uses only basic arithmetic, a square root and a fixed time step, with whole-number inputs. That keeps the arc the same on any phone. And as a second guard, the link carries the result of the shot as well as the shot itself, so even a tiny difference between devices cannot change the outcome.
Check the link arrived whole. Links get cut short when they are copied, wrapped or pasted into the wrong field. BreakFriend adds a small checksum at the end. If the link is damaged, the game says so and does not load a broken game.
One more detail that is easy to miss: the first byte is a version number. If the format changes later, old links can still be recognised and handled instead of quietly misread.
It works for solo play too
BreakFriend also has a solo mode against computer forts. To carry a solo game to another device, it compresses the saved game and puts that in a link of about 700 characters. Open it on your phone and the game carries on where you left off. No sync service, no login.
Why founders should care
This is not just a trick for games. The same idea fits a surprising number of products:
- A shareable calculator or configurator. The inputs ride in the link, so the person you send it to sees exactly what you saw.
- A quote or estimate draft. The client opens a link with the line items already in it.
- A filtered report view. The filters and date range are in the link, so a shared view opens the same way for everyone.
- A turn-based workflow between two people. Each step produces a link for the next person.
What you get:
- Nothing to breach. If you never store it, you cannot leak it.
- No sign-up wall. People use the product the moment they tap the link.
- Very low running cost. A static site with no database is cheap and hard to take down.
- It works anywhere links work. Texts, email, chat, a QR code.
I wrote about the wider version of this thinking, keeping data on the device unless there is a reason to move it, in local-first by default.
Where it breaks down
This approach has real limits. Be honest with yourself about them before you choose it.
Size. Links have practical length limits. Some apps and older systems trim long URLs, and a very long link is hard to copy without damaging it. BreakFriend's links stay short because a game is small. A document, a photo or a long history will not fit. If your state keeps growing, this is the wrong design.
Cheating. The link is the state, so anyone who understands the format can edit it. A checksum catches accidents, not someone who reads the code and recomputes it. For a friendly game between two people, that is an acceptable risk. For anything with money, rankings or prizes, it is not. You would need a server to check moves, or signed links that only your server can create.
Losing the link. There is no copy anywhere else. If someone deletes the chat or loses their phone, the game is gone. No password reset will bring it back. For a quick duel that is fine. For anything people would be upset to lose, offer a way to save it, or use a server.
Privacy is not secrecy. The server never sees the fragment, but the link is still sitting in your browser history and in the chat where you sent it. Anyone it is forwarded to can open it. Never put anything in a link that you would not put in a text message. No passwords, no health information, no customer data.
Rules have to live in the code. Without a server, the page's own code is the referee. Every device must run the same rules the same way, which is why deterministic simulation and version numbers matter so much.
When I would use it
I would reach for state in the link when:
- The state is small and stays small.
- Two or a few people pass it back and forth.
- Losing it is an annoyance, not a disaster.
- Nobody gains much by cheating.
- Not requiring an account is a real advantage.
If most of those are true, try it before you build a back end. You can always add a server later for the parts that need one, such as leaderboards or saved history. Going the other way, removing a database people already depend on, is much harder.
The safest user data is the data you never collect.
How do you decide when a feature needs a server today? I would like to hear where you have drawn that line. Email me if you want to compare notes.
#SoftwareArchitecture #Privacy #ProductDesign #GameDev