The Brief
An indie board-game studio with a growing shelf of titles — a word game, a pickleball card game, a couple more in development — and a Kickstarter on the way. They needed a home on the web that could do four jobs at once: show off the games, sell a few things, run a live crowdfunding campaign, and keep working long after the campaign ended.
The trap with a project like this is treating it as a brochure. A few pretty pages, some artwork, a "back us on Kickstarter" button, done. That builds something that looks finished and is obsolete the week the campaign closes.
We built it as a small product instead — one the studio can keep running themselves, that adapts to whatever game launches next.
What "Marketing Site" Actually Meant Here
Under the hood, DinamicaGames.com is four things sharing one codebase:
- A game catalog — every title gets a detail page with artwork, gallery, mechanics, player count, and play time.
- A storefront — PDF downloads, event tickets, and physical copies, all checked out through Stripe.
- A live campaign dashboard — during the Remix Kickstarter, the homepage mirrored real funding stats straight from Kickstarter, refreshing on its own.
- Bespoke game tools — a word validator and a scorecard built specifically for how the games are actually played.
The first two are the studio's bread and butter and need to change without a developer in the loop. The second two are where the engineering got interesting.
The Studio Runs Itself: Headless CMS
Everything that changes often — games, products, prices, artwork, the site tagline, social links — lives in Sanity, a headless CMS. The studio edits content in a friendly admin UI; the site reads it through typed GROQ queries and renders it with Next.js server components.
That separation is the whole point. Adding a new game is filling out a form, not filing a ticket. A price change is a field edit, not a deploy. Each content type — game, product, siteSettings — is a defined, typed shape, so the page that renders it knows exactly what it's getting. Pages revalidate on a short interval, so edits show up within about a minute without rebuilding the site.
The result: the people who know the games best can run the site, and we stay out of the critical path for routine updates. That's the difference between handing a client a website and handing them a tool.
The Storefront, Without the Overhead
The shop sells three kinds of things, and they behave differently:
- PDF downloads — print-and-play games delivered as a file.
- Event tickets — for launch parties and play sessions.
- Physical copies — the actual boxed games.
Rather than wire up a heavyweight commerce platform for a catalog this size, checkout runs on Stripe payment links managed as content — each product carries its link, and the storefront renders the right call to action based on the product type. No cart service to babysit, no payment infrastructure to secure beyond Stripe itself.
The one piece we did build server-side is the part that earns its keep: a Stripe webhook that verifies every event's signature, then — on a completed checkout — captures the customer's contact details into the studio's marketing list. So every sale quietly grows the audience for the next launch, automatically, without anyone exporting a CSV. The frontend never sees this; it just happens, server to server, the moment a payment clears.
The Live Kickstarter Dashboard
This was the favorite part.
While the Remix campaign ran, the homepage didn't just link to Kickstarter — it mirrored it. A live funding total and backer count, pulled directly from Kickstarter's public stats feed and refreshed every ten minutes on the server, with a countdown to the deadline.
The engineering care here is in the failure path. A third-party feed you don't control will eventually hiccup — rate limits, downtime, a changed response shape. So the fetch is defensive: it sets a proper User-Agent, validates that the numbers coming back are actually numbers, and if anything looks wrong, it silently falls back to a known-good snapshot instead of showing a visitor a broken $NaN or a blank where the momentum should be. The page degrades to "still looks great" rather than "obviously broken."
And because it's all driven by one small config block, retiring the campaign after it closed was a one-line change — not a redesign. We built the live mode knowing it had an expiration date, and made sure turning it off was trivial.
Tools Inside the Games
A board-game site is allowed to be playful, and this is where we leaned in.
A word validator lives right on the word game's page. Type a word, find out instantly whether it's legal — settling the table argument without anyone reaching for a dictionary. It checks against the official 170,000-word tournament list, and the engineering trick is that it does so entirely in the browser, offline, with zero network calls per keystroke. The full word list (about 1.7MB) isn't loaded until you actually interact with the checker, so it never slows down the page for someone who's just browsing. Once loaded, every lookup is instant because the whole dictionary sits in memory as a set. The matching logic itself is a tiny pure function — no framework, no dependencies — that we could drop into the game's eventual companion app unchanged.
A scorecard turns the game's golf-style scoring (lowest total wins) into a live tracker for one to three players across as many rounds as a game runs, including tiebreakers. It saves to the browser, so a half-finished game survives an accidental refresh. It's the kind of small, specific tool that makes a product feel made for its players rather than assembled from a template.
Neither of these is essential. Both are exactly the kind of detail that makes people remember a site — and they cost almost nothing to build well because we understood the games first.
One Monorepo, Several Sites
Dinamica doesn't live alone. It's one app inside a Turborepo monorepo that also houses a couple of band sites and a shared design system. The studio's UI components, the Sanity client, the lint and TypeScript configs — all shared packages, written once and pulled into each site.
That's deliberate leverage. When we build something reusable for one project, every sibling site inherits it. A new microsite in this family starts with a working component library and a configured CMS client on day one, not from scratch. It's the same studio-efficiency story that runs through everything we do: build the hard part once, reuse it everywhere.
The Stack
- Framework: Next.js 16 + React 19 + TypeScript, server components by default — deployed on Vercel.
- Content: Sanity headless CMS, queried with typed GROQ projections, rendered with short-interval revalidation.
- Commerce: Stripe payment links for checkout; a signature-verified Stripe webhook for post-sale lead capture.
- Email & leads: Resend for the contact form; a shared intake service that funnels every contact and every sale into one marketing list.
- Structure: a Turborepo monorepo with shared UI, CMS-client, and config packages across multiple sites.
It's a stack chosen for a small studio that needs to move fast and not pay for infrastructure it won't use. No servers to manage, no database to operate, no commerce platform's monthly minimum — content in Sanity, payments through Stripe, everything else static and fast on Vercel.
What This Project Showed Us
Dinamica Games looks like a marketing site. It's really a small product with a content backend, a payment flow, a live third-party integration, and a couple of genuinely custom features:
- Headless-CMS architecture that hands content control back to the client
- Commerce done at the right weight for the catalog — Stripe, no bloat
- A resilient third-party integration that degrades gracefully when the feed it depends on doesn't cooperate
- Bespoke product features built from understanding how the thing is actually used
- Monorepo leverage — a shared design system and tooling across a family of sites
It's the proof that "just a website" is usually a product wearing a brochure's clothes — and that the difference between the two is whether it keeps working after launch day.
Building Something That Has to Sell — and Last?
A storefront that the owner can run, a launch campaign that updates itself, a few features that make people smile — that combination shows up far beyond board games. Makers, small studios, course creators, anyone shipping a product with a launch moment and a long tail after it: the playbook here applies cleanly.
If that's the kind of thing you're building, let's talk about it.