For a long time, the way you ordered a personalised murder mystery from us was: send us an email, get on a call, fill in a Google Doc, wait while a writer hand-wove your guests, weapons and locations into a four-hour bespoke script, then receive a PDF. It was lovely. It was also unscalable.

Word of mouth kept bringing in more orders than two hands could write, so we set out to build something we’d never had before: a real product. Not a redesign of an old site, a from-scratch build of a configurable game that could spin up a unique, playable murder mystery from the inputs a customer typed in on their phone.

This is the story of how that came together, who we built it with, and a few of the decisions we’d make again.

What You Dunnit actually has to do

You Dunnit is a personalised murder mystery game builder. You pick a story, fill in your characters, weapons and locations, and we generate a mystery that’s playable on your phone in under fifteen minutes, or printable, or scaled up to a corporate event with 200+ players.

That sounds simple. But every product surface has to support a few different jobs at once:

A first-time visitor working out whether to buy, needs storytelling, social proof and clear pricing.
A buyer configuring their game, needs a sturdy form-driven flow that doesn’t feel like filing a tax return, and a way to preview what they’re actually getting before they pay.
A gift-buyer, needs a totally different path that ends in a voucher rather than a product.
A host on the night, needs to log in, distribute the game to their players and run it on phones in someone’s living room.
The team behind the curtain, needs CMS authoring that doesn’t get in the way of writing new stories.

None of which a Google Doc and a Stripe payment link can quite do for you.

Why Craft CMS, Craft Commerce and Tailwind

We picked Craft CMS as the editorial backbone, Craft Commerce for the e-commerce side, and Tailwind CSS for the front end. The reasoning was almost embarrassingly practical.

Craft is built for editors, not just developers. We write a lot of new mystery content, seasonal landing pages and how-to guides, and Craft’s matrix fields and entry types let our team compose pages without filing engineering tickets. New story launches, the “How it works” explainer, blog posts (hi there) and FAQ updates all live where the people writing them can edit them.

Craft Commerce sits inside the same system as the content, which matters more than it sounds. Products, variants, pricing, vouchers, line items, discounts — all editable in the same admin our content team already uses, with the same permissions model. No swivel-chairing between a Shopify dashboard, a CMS and a fulfilment tool.

Tailwind, meanwhile, is the only honest answer we’ve found to the question “how do you keep a marketing site, a configurator and a checkout feeling like the same product without writing four thousand lines of bespoke CSS that nobody dares touch six months later?” Utility classes mean every component is built from the same Lego bricks, and design changes ripple through the codebase in hours rather than sprints.

Building on a design system, not just a Figma file

The thing that actually unlocked the build, though, was treating the design as a system from day one rather than a set of mockups we’d hand off and forget about. We worked with Honcho, a specialist design systems agency, to set up a single source of truth: typography, spacing, colour, motion and component patterns living as design tokens in Figma and as Tailwind theme values in code. Same names, same values, both ends.

That sounds like overhead for a product our size. In practice it took weeks off the build. Every new template, gift voucher flow, group game upsell, event enquiry page, was assembled from existing components instead of designed and developed from scratch. When we tweaked a button radius or a heading scale, it changed everywhere at once and stayed consistent. Editorial pages composed by the team in Craft inherited the styling automatically, because the building blocks were already wired up.

If you’ve ever shipped a redesign and watched the third-party checkout page or the blog template drift back to looking weird within a quarter, you know why this matters.

The custom functionality: a mystery, generated

The most interesting engineering on the site is the bit you don’t see: the engine that takes your inputs, a list of guests, character names, weapons, locations, vibes, and turns them into a coherent, playable murder mystery.

This isn’t a fill-in-the-blanks template. The story has to make sense. Suspects need motives that fit their character. Evidence has to rule people in and out as the rounds progress. The murderer has to be discoverable but not obvious. And it all has to be readable on a phone, in a kitchen, by someone who’s two glasses of wine in.

Two pieces make this work.

First, a Google Firebase layer captures script variables in real time as the customer types them into the build flow. As you fill in characters, weapons and locations, your inputs stream into Firebase and are stitched into a live preview of your script, so you can see what your mystery is shaping up to look like before you pay. Once you’re happy, those same variables get passed through to the final, playable game.

Second, a host-side flow handles the night itself: the person who bought the game logs in, distributes it to their players, and the game plays out across everyone’s phones. Splitting the “buy and configure” experience from the “play it on the night” experience let us optimise each one without compromise, the configurator is content-rich and conversion-focused, the gameplay is stripped back, fast and resilient on dodgy 4G.

Commerce, vouchers and the gift problem

A surprisingly large chunk of our orders are gifts. Hen dos booked by maids of honour, birthday surprises, “I want to send my dad a thing he can play with my mum”, and gifts have a different shape than self-serve purchases. The buyer doesn’t know the players’ names. The redeemer hasn’t paid. The two events can be weeks apart.

We modelled both as first-class flows in Craft Commerce, with Stripe as the payment processor. A direct purchase drops the buyer straight into the build flow; a voucher purchase produces a redeemable code that lands in the recipient’s inbox and unlocks the same configurator when it’s redeemed. Behind the scenes both end up in the same fulfilment system; from the customer’s point of view they’re completely different journeys. The shared design system is what let us build the second path quickly without it feeling like an afterthought tacked onto the first.

Scaling from four players to 200+

The other thing we wanted to nail is that You Dunnit is genuinely two products in one suit. A four-friends-around-a-kitchen-table game and a 200-person corporate event are not the same thing. The first is conversational and cosy. The second needs facilitation, name badges, multiple rounds running in parallel and someone-from-IT-friendly logistics.

We separated those flows in the information architecture, distinct landing pages, distinct enquiry forms, different proof points, but kept the brand and the components consistent so it always feels like You Dunnit. The shared system is what made it cheap to keep both flows polished.

What we’d do again

Invest in the design system before the product surfaces. It feels indulgent for week one and pays back from week three onwards.
Pick a CMS your editors will actually use. Craft punches well above its weight here, and having Commerce in the same admin as the content removed a whole category of tool-switching.
Let the customer see what they’re buying. The Firebase-powered live preview was the single change that made the configurator feel like a real product instead of a long form.

If you’re building something with similarly weird requirements, a configurator, a generator, a thing that’s part shop and part product, we’re happy to compare notes. And in the meantime: who killed the duke in the library?

How we built You Dunnit