A few days ago I posted a product hypothesis about a TTRPG continuity engine. I named the gap honestly. I asked the right validation questions. Then I sat with it overnight, asked the questions of myself, and decided not to build it.
This is the part product writing usually skips. So this post is the part product writing usually skips.
The pain failed its size check
The continuity gap is real. I run two long campaigns and I lose track of things constantly. So do my players. But when I asked myself how much does it actually hurt, the honest answer was: a little. Sometimes a lot. Mostly a little. And often, the missed callback creates space for a better one to land in the moment.
That last bit matters. Forgetting at the table isn’t only a pain. It’s also part of how a session breathes. Players show up for genuine, fun, unexpected moments, and a chunk of those moments come from someone misremembering or improvising over a gap. A tool that aggressively eliminated forgetting would be solving for the wrong outcome.
Any honest version of this product would need to know when to surface things (during prep, basically never during play), and that’s a UX problem at least as hard as the technical one.
The “ingest your messy notes” promise is a demo, not a product
I waved this away in the first post by saying “capture is increasingly solved by other tools.” Sitting with the idea, that’s only partly true. The realistic input stream for any DM I know is:
- Clean transcript from one session
- Half-recorded audio with gaps from the next
- Five bullet points scrawled at 1am for the one after that
- Nothing at all for sessions 30 through 33 because they got busy
A product that needs all of those to flow into a coherent campaign state is doing the hard part of “AI for messy data,” and that’s the part most demos quietly hide. Tolerant of gaps, won’t hallucinate to fill them, can ask “do you want me to skip this or do you want to dictate the missing bit?”: that’s a real product. It’s also not a weekend.
TTRPG audiences won’t pay for plumbing
This one’s the simplest. TTRPG audiences pay for content (modules, art, supplements) or for character automation (D&D Beyond’s whole business). They will not pay for “your notes are searchable now.” That’s a feature, not a product. Without a payment model, the long-term sustainability question gets harder, not impossible, but harder.
The synthesis: not the right swing
None of these are fatal individually. Together, they describe a product with a small pain, a hard input problem, and no monetization path. That’s not a no-go for a personal project. It’s a no-go for a startup-shaped project.
I do want to build something of my own eventually. That ambition is real and not going anywhere. But “I want to build a thing” is not the same as “this is the thing.” When I’m honest about it, this is a project I’d build because it’s adjacent to my hobbies, not because it’s the strongest hand I have to play. The right swing waits for a problem I’m uniquely positioned to solve, with enough size and clarity to justify the years of work.
So the right answer is to not build this one, and to be honest about why.
What I’m building instead
If the continuity engine isn’t the right swing, what is? The honest answer, after sitting with my own criteria: a SNES-style 2D RPG, set in Nuvem (the same homebrew world as the novel I’m working on and one of the D&D campaigns I run), built in Godot, over the course of years.
That probably reads as “wait, that’s a way bigger project.” It is. But it passes the test the continuity engine failed:
- The pain it solves is mine. I want to learn how to make games. Not “should learn.” Not “would be useful.” Want to. The audience that has to care about this game succeeding is one person before it’s anyone else.
- The bet is on learning, not on a single outcome. First games rarely make money. The point is that every game I make after this one is cheaper because the foundation exists. I’m buying optionality, not lottery tickets.
- It compounds with everything else I already love. The novel feeds the world; the campaign playtests it; the game becomes another lens on the same fiction. Three creative streams converging on one IP, instead of three projects competing for the same evenings.
- It’s mine, end to end. Design, code, art direction, story, scope, ship date, what’s in and what’s cut. The thing the staff PM in me has been quietly itching for: a single product where I get to make all the calls and the ones I get wrong are mine to fix.
The first move isn’t building the actual game. It’s a throwaway prototype in Godot to learn the engine, then the real project. Years, not months. Probably bad before it’s good. That’s the deal.
Closing the loop
A few things to leave on:
- The continuity gap insight stays useful, just not as a product. It’s a thing I’ll watch for in my own DMing. When it bites hard enough, I’ll patch it with a small Obsidian skill rather than build a system.
- The “forgetting as feature” insight goes in the back pocket. It’s the kind of thing that’ll show up later in a different post about TTRPG design.
- The first post’s ask still stands. If the continuity gap I described matches your experience and you’ve solved it (or really wish someone would), I’d still want to hear about it. The answer might be “build a small thing for myself and share it.” It just isn’t going to be “build a startup.”
- This post exists. Walking back a public hypothesis cleanly is itself signal. Most product people only publish the wins. Publishing the no, and then naming the actual yes, is sometimes the more honest move.
The lesson, for me at least: the most important part of having a product idea is the part where you decide not to build it. That’s the part where the thinking actually happens. The yes that comes after that is usually clearer because of the work the no did first.