This is the first entry in our Developer Spotlight series — recurring conversations with the people building on Jest: what they made, how they made it, and what surprised them about messaging as a platform.
There’s a dungeon in your text messages.
Barrowdeep, the debut release from Boglight, is exactly what its developer says it is: “A dark fantasy idle dungeon crawler. Build a party, send them into the dungeon, and check in when you can.” No download, no signup form — the game arrives the way everything on Jest arrives, as a tap in a thread.
Here’s what makes this spotlight different from every studio profile you’ve read: Boglight is one person, they’re staying anonymous for now, and Barrowdeep exists as an experiment — a test of a simple question.
Can anyone make a game now?
The answer, apparently, is yes. Barrowdeep was vibe-coded with Claude. The art was generated with Flora. And it shipped not through a store submission queue, but onto a platform where distribution is a text message.
For most of gaming history, two walls stood between “person with an idea” and “person with players”: production (you need a team) and distribution (you need a publisher, or a store’s blessing and a UA budget). Barrowdeep is what it looks like when both walls come down in the same year — AI tooling took down the first, and messaging-native distribution took down the second.
And players are showing up. Barrowdeep went live at the start of the month, and the early signal is the kind you want to see: of the first day’s players, more than half came back the next day. An idle RPG whose whole premise is “come back and see what your party found” might be the most messaging-native genre there is — the game’s re-engagement loop and the platform’s re-engagement surface are the same shape.
We asked the developer about building a dungeon crawler for the Jest platform, and for your messages.
Q: So — who is Boglight?
A: Boglight is me! I’m the designer and owner, and I’m not much of a coder. I have a background in digital art, design, and mobile game advertising. I have been making ads for games for years and always wanted to design a game for me to play. I barely know basic javascript so the game dev hurdle was huge. I’ve been using a lot of AI tools as they have evolved over the years and thought it would be worth seeing if I had what it takes to build a game from scratch with only an AI agent to help me.
Barrowdeep is built almost entirely by directing Claude: I write the design docs, play the build, and flag what’s broken or what should change; Claude writes the code, runs the tests, and ships it. Eight hundred and fifty-plus commits since mid-July, and I haven’t written a line of TypeScript. If you’d told me a year ago I’d be shipping a full idle RPG, I would say, “huh?!”
Q: Where does the name come from?
A: A boglight is a spooky phenomenon when glowing lights appear in the sky above a bog. It is often referred to as “will-o-wisps” or “corpse candles.” It’s a big thing in European folklore. I believe in the American Southwest the equivalent might be the “ghost light.” When I started making Barrowdeep, I really wanted to embrace the weird and unknown in my games’ stories and worlds. So, “Boglight” felt like a perfect fit.
Q: Pitch us Barrowdeep in a sentence.
A: Barrowdeep is a dark-fantasy idle dungeon crawler; you build a party of heroes (a mouse knight, a bigfoot berserker, a grey-alien sorcerer, whatever the dungeon coughs up), gear them up, and send them down a barrow that keeps getting fought, looted, and leveled whether you’re watching or not.
Q: Walk us through the build. What does “vibe coding a dungeon crawler” actually look like?
A: No game engine! It started as the simplest HTML proof of concept and grew from there. Currently, it’s Vite + React + TypeScript, Tailwind for styling, Zustand for state (one store, sliced by system: combat, economy, roster). Combat is DOM + CSS animation, no PixiJS or Phaser; a UI-driven game like this didn’t need a renderer, and it kept the bundle light. The whole sim runs on a fixed logical tick so the same party + dungeon + elapsed time always produces the same result; that determinism is what makes offline earnings honest (we compute them analytically instead of replaying ticks) and will make async PvP possible later.
Payload: our blocking load comes in comfortably under Jest’s recommended target. Most of the weight is pixel art and one of a few randomized boot-splash illustrations; the JS itself is a small slice of that. Same story on the save side; Jest gives each player 1 MB of synced key-value storage, and our saves are a few KB. We pin that with a regression test that stuffs a full inventory and stash and asserts the serialized save stays far under the cap, so a future feature can’t quietly blow the budget without a red build.
First commit to live: July 15 to launch submission on August 1; seventeen days. We hit v1.0.0 with our full launch content gate on day 17. We’re about a week into launch week as I write this, still iterating daily.
Q: Why an idle dungeon-crawler for a messaging platform? Designed for platform or adapted to it?
A: Honestly, both, in that order. The game concept (party-based idle crawler) came first, as a fairly generic web-game design doc. Jest is what it got adapted to, and the adaptation mostly meant deleting things rather than adding them. Our original plan had us building auth, cloud save, payments, and a referral system ourselves. Jest’s SDK gave us all four for free: a stable player ID that survives guest-to-registered, a synced key-value save store, in-app payments, and a referral module with an entry-payload mechanism. So the tech plan got smaller the moment we targeted Jest specifically.
But the fit runs deeper than “convenient SDK.” An idle game’s whole premise is progress happening while you’re not looking, and a messaging platform’s whole premise is reaching you where you already are. Jest wants to see real re-engagement mechanics before a game goes live; dailies, appointment mechanics, a reason to come back — and our multi-day dungeon arc basically was that already; we just had to surface it as SMS/RCS instead of inventing our own retention hooks. It felt less like bolting a game onto a chat app and more like the two designs were solving the same problem from opposite ends.
Q: What surprised you most about messaging as a platform?
A: How much of a design surface the message itself is. I came in thinking of notifications the way I always had; a string field. A line of copy you write once, ship, and never look at again. On RCS you get a real image card, which means every message is a little piece of art with a headline attached. That reframed the whole thing for me: it’s not a copy task, it’s an asset task, and I’m an artist before I’m anything else.
So we made custom art for ours. Painted cards in the same pixel-art hand as the rest of the game; the loot piling up unattended at camp, a companion locked in a cage deeper in the barrow, the thing waiting at the bottom of your dungeon, the party asleep by the fire. The point is that a text you get on a Tuesday afternoon should look like it came from Barrowdeep and not from a marketing tool. It’s a piece of the game arriving in your messages, which is a much stranger and better feeling than a banner.
And once you’re treating it as a real surface, generic copy starts to feel embarrassing. Ours read live game state before they send: your hero’s actual name, the actual dungeon you’re stuck on, the actual number of unclaimed rewards sitting at camp, whether your idle haul has capped out. “Whatever guards the Gobwarrens is still standing. Wren is ready.” is a fundamentally different message from “come back and play!” It’s your party, your dungeon, your unfinished business, and it’s true. The nice side effect is that it changed how we design features. Every new system now gets asked “okay, what does this look like as a text?”, and honestly that’s a fun constraint to build under.
Q: What was harder than you expected?
A: Balance. Genuinely, boringly, balance, and it does not stop being hard. I assumed it was a week of tuning at the start and then you’re done. It’s the whole project.
Here’s the thing though: I thought we had it. We had a headless simulator running modelled players over 150 simulated days, probes for the economy, the difficulty curve, the gear curve. Every number came back defensible. I felt good about it.
Then we launched and I read the Jest chat.
That chat is the single best QA tool I have ever had access to, and it is free, and it comes with the platform. Players sit in there and narrate everything that happens to them in real time. Not bug reports, not survey responses, just people talking. On day two I watched one player post that they were party level 100 doing trillions of damage, while a few messages later someone else was level 22. Same game, same two days. Somebody posted a ring they’d found with ten trillion HP on it, purely because they thought it was funny. Somebody else mentioned offhand that potions were what finally got them past the early wall, which told me the rest of them had no idea potions existed. So much incredibly valuable QA information.
Q: How do your away-progress messages perform compared to push notifications in your past projects?
A: So here’s the number that made me sit up. Our early D1 is running around 54%, with D2 near 44%. Those are rough launch-week estimates, not audited figures, and I expect them to settle. But the benchmarks they’re sitting next to are not close: RPG averages about 30% D1, strategy about 25%, simulation about 30%, and mobile games overall land near 27%. We are roughly double the category on day one, and our D2 is still above what most games get on day one.
I don’t think that’s because our game is twice as good as everyone else’s. It’s the channel and the platform. The away-progress message is a text. It shows up in the same thread as messages from actual people, with no permission gate to fail and no tray to get buried in. That removes the two things that killed push for us on past projects before a single word of copy ever got read.
It also raises the bar on what you’re allowed to say, which I think is a feature. A lazy push is noise you scroll past. A lazy text is a text. So we write ours as dispatches from the dungeon, what the party did while you were gone and what dragged them under, rather than a nudge with a fake exclamation point. Content, not a poke.
Q: Barrowdeep just launched. What are you watching in week one? What number matters most to you?
A: Retention. Daily (or better) return rate is the number, and everything else is downstream of whether people come back. Practically I’m watching return rate in the days after a player’s first real session, how many guests convert to registered (registration is what makes notifications reachable at all, so it’s a gate on the entire retention story), and load time, since a slow first load is churn before the game even gets a chance to be a game.
The one I’m watching hardest this week, though, is tutorial completion by stage. We instrumented every beat of the prologue the day before launch, and it’s the clearest picture we have of where a brand-new player decides this isn’t for them.
Q: What are three things you would tell new players?
A: They don’t drink potions. This is the big one and it isn’t close; only about a quarter of the players who’ve ever started a dungeon have ever used a potion. Potions are the thing that gets you through the first real difficulty spike, and if you never touch them the game feels roughly twice as hard as it actually is.
They hoard gold. I’ve watched players sit at a boss gate for days with tens of thousands of unspent gold in their pocket. The gate isn’t a patience test, it’s a shopping problem. If you lose to a boss twice, go buy something. Every tool for breaking a wall is already in your bag.
They forget to close the game. And honestly? They’re not wrong to; it’s very addicting to watch your party progress. But it’s an idle game — you can start a dungeon and come back later, or come back tomorrow to check in.
Q: What is next for Barrowdeep and for Boglight?
A: Short-term it’s all onboarding; streamlining the early gameplay, balancing the endgame, and closing out the last few launch checklist items. Getting a new player to their first great loot drop is worth more than any amount of new content right now. After that: Prestige mode, PvE Arena with Leaderboard, Events, and more content! And more Boglight games on Jest, honestly.
Q: Advice for the next person — not team, person — considering this?
A: Put your storage, auth, and payments behind your own internal interface before you write a single Jest-specific line. For us that turned SDK integration into a three-line change. You’ll also end up deleting a surprising amount of planned backend work, and that’s a gift, not a compromise.
Take the re-engagement requirement seriously from day one instead of retrofitting it. If your core loop doesn’t already give players a reason to come back, notifications won’t manufacture one for you. If it does, Jest hands you the delivery mechanism for free.
Run their testing tools early and often. Mock mode, the emulator, sandbox users, the Simulator. Ours caught real bugs we’d never have found playing our own game, and recording the self-review pass forced me to watch my own onboarding as a stranger would. That was uncomfortable and useful.
Look at the actual economics before you assume you know them. Developers keep 90% and Jest takes a flat 10%. Jest eats 100% of the message delivery cost as well. I’ve bought a lot of mobile users in my career and I’ve never seen a channel priced like that.
And the real one: being early is an advantage, not a risk. You are not the ten-thousandth game in a storefront where nobody will ever scroll far enough to find you. The platform is new enough that a good game gets noticed, the people building it answer their messages, and the stuff you find while building actually makes it into the docs. I’d take that trade over a mature app store every single time.
Barrowdeep is live now — jest.com/g/barrowdeep — tap in and start delving.
Barrowdeep isn’t interesting because an AI wrote the code. It’s interesting because the game is good — good enough that more than half of its first players came back the next day. The vibe coding is how it got built; it’s not why anyone plays it. If you’re going to vibe-code a game, do what Boglight did: use the AI to move fast, and use yourself to know when it isn’t good enough yet.
You don’t need a studio or a publisher to put a game in front of players anymore. The developer docs are open to everyone — and if one anonymous developer and an AI pair-programmer can ship a dungeon crawler into the inbox, the question isn’t whether you could. It’s what you’d build.
Welcome to Jest, Barrowdeep.