← Back to Dev Log
DEV LOGFebruary 202610 min read

TESTFLIGHT LESSONS:
WHAT REAL OPERATORS TAUGHT US IN WEEK ONE

The first week of beta is always the most brutal and most useful. Here is what we learned from early Operators running the Protocol — what worked immediately, what needed rethinking, and what assumptions were wrong.

There is a specific anxiety that comes the night before real users touch your product for the first time. Not the demo version. Not the version you've shown to people who are being polite. The actual version, on their actual devices, with no one standing next to them to explain why something looks broken or what they were supposed to do there.

I spent seven months building TheForge. I had run the Protocol on myself for four of those months. I knew what every button did, what every quest type meant, how the rank progression worked, what the XP formula was. None of that knowledge transferred to Operators who downloaded it cold. The first week of TestFlight taught me things I could not have learned any other way.

WHAT WORKED IMMEDIATELY

The rank system landed. I had been worried that F→SS progression would feel arbitrary or unfamiliar — that Operators would not understand why they were starting at rank F or what moving to E would require. The opposite happened. Within hours of the first installs, Operators were asking how many XP they needed to rank up, whether the gear drops at rank milestones were already implemented, and when Cycle 2 multiplayer would let them compare rank with other Operators. The LitRPG framing was not confusing — it was immediately legible to anyone who had ever played an RPG, which is most people under forty.

The Comfort Loop identification in onboarding also worked better than expected. I had built the onboarding to be short — five minutes maximum — and had worried that it was too brief to capture meaningful Comfort Loop data. Operators disagreed. The directness of the questions (“What behaviour do you return to when you should be doing something harder?”) was not off-putting. It was clarifying. Several Operators said they had never articulated their loops in those terms before and that the act of naming them in onboarding was itself useful.

Push notification timing held. The System sends the daily quest brief at a time the Operator sets during onboarding. Most habit apps default to 9am. I had built it to be configurable from day one, which turned out to be important — a significant portion of early Operators set their brief for 6am or before. They wanted it before the Comfort Loop had time to activate in the morning window.

WHAT NEEDED RETHINKING

Onboarding completion time was wrong. My estimate of five minutes was accurate for someone moving through it at pace, but most Operators spent longer on the Comfort Loop identification step — not because it was confusing, but because they were actually thinking about it. I had built a progress indicator that showed five steps remaining at the point most Operators were still on step two. Two people dropped out here. I removed the progress indicator. Completion rate improved.

Quest difficulty calibration at rank F was off. I had built the initial quests to be achievable by anyone, regardless of starting fitness or existing habits. The intention was accessibility. The effect was that the first quests felt trivially easy to Operators who were already partially functional — people who exercised occasionally, had some routines, and were looking for a system to build on what they already had. They found rank F quests insulting. They were right. The rank F to E curve needed to steepen significantly for the System to feel like it had teeth from day one.

The XP display needed to be more prominent. Completing a quest and earning XP is the core feedback loop of the Protocol. I had placed the XP counter in the profile screen, behind a tab. Operators wanted to see it on the home screen, immediately, with every completion. This is a basic game design principle I had underweighted because I was worried about the interface feeling cluttered. It did not feel cluttered. It felt absent.

THE ASSUMPTION THAT WAS COMPLETELY WRONG

I had assumed that the primary user concern would be the app being too demanding. That Operators would find the quest load too heavy, the discipline requirements too strict, the Chaos Engine injections too disruptive. I had built safety valves into the system: difficulty reduction options, quest deferral, opt-out windows for the Chaos Engine.

Not a single Operator used any of them. The feedback in week one was unanimous and in the opposite direction: Operators wanted the system to be harder, not easier. They wanted consequences for skipped quests beyond XP loss. They wanted the Chaos Engine to inject more frequently. They wanted the rank gates to be stricter, not looser.

This was the most useful thing the first week taught me: the people who seek out a system like TheForge are not looking for a system that accommodates their existing behaviour. They are looking for a system that refuses to. The market for self-improvement tools that are actually strict is larger and more motivated than the market research suggested — because the people who would answer “softer, please” in a survey are not the people who install a LitRPG habit app.

Every design decision made to protect the user from discomfort was a decision made for a user that was not actually using the product. The Operators who showed up in week one wanted to be held to a standard. The job of the System is to set one worth holding.

Week two of beta incorporated all of this. The System is harder now. Completion rates went up.

JOIN THE BETA

BE AN OPERATOR.
SHAPE THE PROTOCOL.

Your feedback goes directly to the one person building this. Register for TestFlight access and run the System before public launch.

Register as Operator →