Table of Contents
I wasn’t trying to build a tool. I was writing a sword-and-sorcery story.
The project started as fiction — a pulp fantasy series born from a collaborative TTRPG session I ran through Discord with an AI game master. The session gave me narrative bones: a character, a tomb, a cosmology. I spent a few days with Claude Code turning that into prose, then a world bible, then character arcs, then outlines for sequels.
Then I decided to adapt the whole thing into a tabletop RPG campaign.
The scope creep that wasn’t
If you’ve ever run a tabletop game, you know the prep work. I needed a GM guide, a player-facing rulebook, a bestiary, house rules, a hex map, a magic system, location keys, NPC dialogue, encounter tables. These are all just documents — and Claude Code is very good at documents. Within a day I had over a dozen styled HTML pages covering the full campaign: a living world system with faction clocks, a sanity mechanic, a sorcery system with corruption risk, and a complete session-zero packet.
None of this required me to write code. It was creative work — worldbuilding, game design, editorial decisions. Claude handled the translation into formatted, consistent, ready-to-use documents. I focused on what the systems should do and how the world should feel.
Then I needed dungeon maps.
The gap that generic tools leave
Dungeon mapping software exists. Dungeon Scrawl, Dungeon Draft, a dozen others. They’re good at what they do. But what I wanted was specific enough that none of them quite fit:
- Maps in a particular old-school aesthetic — graph paper, cross-hatched walls, minimal icons
- Room descriptions, trap placements, and feature details baked into the map data — not a separate document
- A GM view and a player view toggle, so I could share maps without spoiling secrets
- Export to Fantasy Grounds, which has its own module format
- And eventually: the ability to say “generate me a temple to a forgotten serpent god” and get a playable dungeon with interesting choices, loops, and secrets
No single tool does all of that. More importantly, no generic tool should — these are my specific needs for my specific campaign. A product that serves thousands of users can’t optimize for one person’s workflow. That’s the right call for the product. It’s just not great for me.
So I built my own.
Two weeks of vibe coding
The first version was a Python script that rendered static SVGs from JSON. It worked, but editing meant hand-writing coordinate data in a text file. Within hours that became a browser-based editor — vanilla HTML and JavaScript, no framework, no build step. Just a file I could open and start drawing.
From there, features accreted in the way they do when you’re building for yourself: cave walls with organic edges, automatic layout so rooms don’t overlap, corridor routing with L-bends and diagonals, octagonal rooms, a room key export. Each feature showed up because I hit a friction point in actual use, not because it was on a roadmap.
The AI generation came in on the same day the editor went interactive. I added a small Express server to proxy Anthropic API calls, and then four generation modes: create a full dungeon from a prompt, add a single room to an existing map, polish an existing dungeon by filling gaps and adding secrets, and stock rooms with monsters and wandering encounter tables.
The whole thing lives in a single HTML file. That’s a deliberate choice — Claude Code can read the entire application in one context window, which means every change has full awareness of everything else. No build tooling, no module boundaries to navigate, no framework abstractions between intent and implementation. The AI generates creative content — names, descriptions, features, connections — and JavaScript handles all the spatial reasoning. That separation is load-bearing: LLMs are good at inventing a room called “The Drowning Gallery” with a trapped mosaic floor, and terrible at computing whether it overlaps with the room next to it.
By the end of two weeks I had a 4,700-line interactive dungeon editor with AI generation, multiple export formats, and a Fantasy Grounds pipeline. I’d also generated and played through several dungeons with it. Total lines of test code: zero.
The part that isn’t about code
Here’s what I keep coming back to: I’m a software engineer. I can build tools. But the interesting thing about this project isn’t that I wrote 4,700 lines of JavaScript — it’s that the JavaScript was incidental to the actual work.
The actual work was creative. Writing fiction. Designing a game. Building a world. The tool emerged because I needed something specific and building it was faster than compromising with something generic. That’s a sentence that used to only be true for developers, and only sometimes. Now it’s becoming true for anyone willing to describe what they want clearly.
I’ve watched non-technical colleagues use Claude to build internal dashboards, data transformation scripts, and workflow automations that would have been a Jira ticket six months ago. Not because the AI made them into programmers — but because the gap between “I know exactly what I need” and “I have the thing I need” collapsed. The tool doesn’t require you to think in code. It requires you to think clearly about your problem.
What this means for generic SaaS
Every dungeon mapping tool I looked at was good software solving a general problem. They have users, revenue, roadmaps. I’m not predicting their demise.
But I am noticing a pattern: the more specific your needs, the less a general tool serves you — and the cost of building something specific is dropping fast. The economics of “good enough for most people” get harder when “perfect for me” takes an afternoon.
This doesn’t kill SaaS. It kills the long tail of SaaS — the tools that survive not because they’re great, but because the alternative was hiring a developer. When the alternative is a conversation, the calculus changes. The tools that survive will be the ones where the value is in the data, the network, or the integration — not in the UI that wraps a workflow you could describe in three paragraphs.
What I’d do differently
Commit more often with real messages. The git history of this project is a string of commits like “fexies” and “faets” and “qol” — classic vibe-coding archaeology where the code moves faster than your discipline. It doesn’t matter until it does, and then you’re reading diffs trying to remember what “cave wall corridors” actually changed.
I’d also separate the generated content from the tool earlier. The dungeon JSON files, the campaign documents, and the editor are all in one repo. That made sense when it was just me iterating, but it means the “tool” and the “content” can’t evolve independently.
What’s next
One thing I haven’t written about yet: during this project, Claude Code acted as a research agent — browsing OSR game design forums, synthesizing video content into design principles, pulling best practices from review sites. The results directly shaped the campaign design. That’s a different kind of AI collaboration than code generation, and it deserves its own post. Soon.
For now, the dungeon editor works, the campaign is ready to run, and I have a fiction series with one finished story and outlines for five more. What started as “I want to write a pulp fantasy story” turned into a complete creative toolkit — not because I planned it, but because each step made the next one obvious, and the cost of building was low enough that I never had to stop and ask whether it was worth it.
That’s the shift. Not “AI writes code for you.” It’s that the distance between wanting something and having it got short enough that you stop reaching for generic tools and start building exactly what you need.