The most common question I get from outside engineers when they look at our release cadence is some version of "how?" We are a small team. We ship a new casual puzzle game roughly every 30 days. We ship it to the browser, with no app store, no install, no sign-up. The games run on devices ranging from a 2026 flagship phone to a five-year-old low-end Android, and they load in under three seconds on the latter. The natural assumption is that we have a wizard build system doing all the work. The reality is less glamorous: we have a strict, weekly-milestone pipeline that we follow religiously, and the discipline — not the tooling — is what makes 30 days reproducible.
This article is the full walkthrough. I want to show what happens each week, what the engineering decisions are, and where the time actually goes. If you have ever wondered what a casual puzzle pipeline looks like under the hood, this is it.
Week 1 — Prototype and Core-Mechanic Validation
The first week of any new game is the week that decides whether the game gets made at all. By the end of day seven, we either have a playable prototype that demonstrates the core mechanic feels good, or we kill the project and start a different one. This is non-negotiable. The most expensive failure in casual game development is not shipping a bad game. It is shipping a game that took 90 days to discover it was bad at day 7.
The prototype is intentionally minimal. It is a single mechanic — drag-and-pour for a color sort, swap-and-match for a match-3, draw-and-connect for a line puzzle — built on top of our shared engine scaffolding, with placeholder graphics and no progression system. The build is opened on three reference devices: a low-end Android (currently a 2021-era 2 GB RAM device), a mid-range phone, and a desktop browser. The question we are answering is narrow: does the core loop feel satisfying in the first ten seconds? If the answer is no, no amount of polish or content will save the game. If the answer is yes, we move on.
A prototype exists to answer one question. The question is never "is this game good?" It is "do players want to do this again?" If the prototype cannot answer that in seven days, the prototype was too ambitious.
The engineering work in week one is almost entirely input handling and feedback. The mechanic has to feel responsive on a low-end device, which means we write the input pipeline against a 30 FPS target from day one, not a 60 FPS target. The WebGL renderer we use is a custom lightweight wrapper over the WebGL 2 API — not a full game engine, because full engines carry overhead we cannot afford on a 2 GB device. The prototype renderer is intentionally worse-looking than the final game will be. We are testing feel, not art.
Week 2 — Content Production and Level Design
Week two is the longest week, because it is where the game becomes a game. The core mechanic has been validated; now we build the content it lives inside. For a casual puzzle, content is mostly two things: levels and tuning values. We aim for a 60-level campaign at launch, with another 60 in the immediate post-launch pipeline. Levels are produced by a level designer working in a custom editor that exports to a JSON schema the runtime reads directly — no code change required to add a level.
The tuning values are the harder part, and they are owned jointly by the designer and the player research team. Every level needs target bands for first-try win rate, mean attempts to clear, and D1 return rate. The designer authors the level; the researcher signs off on the target bands; engineering wires the telemetry to capture the bands in production. We do not ship a level whose target bands have not been defined. This is the single biggest difference between a 30-day pipeline and a "throw it over the wall" pipeline. Every level ships with measurable acceptance criteria.
On the engineering side, week two is mostly tooling. The level editor needs to export valid JSON, the runtime needs to load it lazily (more on that below), and the in-game analytics hooks need to be wired to fire on first-try clear, retry, and abandon. By the end of week two, the game is playable end-to-end from level 1 to level 60, on a low-end device, with telemetry flowing.
Week 3 — Optimization: Performance, Compatibility, Low-End Devices
Week three is where the pipeline earns its keep. The game works. Now it has to work everywhere, fast, on devices that should not be able to run it. This is the week where the bulk of the engineering judgment calls happen, and it is the week most easily skipped by a less disciplined team — because the game "works" by the end of week two, and the temptation is to ship it.
WebGL Rendering Optimization
Our renderer is WebGL 2 with a hand-rolled fallback to WebGL 1 for the oldest devices in our target set. The optimizations we apply are not exotic, but they are non-negotiable. We batch draw calls aggressively — every gem on a Royal Matcher board that shares a sprite sheet is drawn in a single call, not one call per gem. We use texture atlases for the entire UI kit, so the GPU is not switching texture bindings between UI draws. We avoid render-to-texture passes for any visual effect that can be faked with a shader, because render-to-texture is one of the most expensive operations on a mobile GPU. The goal on a low-end device is to keep the GPU at or below 50% utilization at the median frame, leaving headroom for the JIT-compiled JavaScript that drives the game logic.
Asset Compression
Asset budget is the single largest determinant of load time on a throttled connection. We ship every visual asset in WebP format, never PNG, because WebP provides comparable quality at roughly 25–35% smaller file sizes on the assets we use — a comparison well-documented by Google's WebP developer documentation. Backgrounds and hero images are additionally served as AVIF where the browser supports it, with WebP as the fallback. The savings on AVIF over WebP are another 20% on average for photographic content. Audio is shipped as Opus in a WebM container, never MP3 — Opus achieves transparent quality at 64 kbps where MP3 needs 128 kbps, halving our audio payload.
The total initial payload budget for a launch build is 1.8 MB compressed, including the engine. Anything above 2 MB triggers an immediate audit. The audit is not a formality — we have killed features in week three because they pushed the payload over budget and could not be justified against the size cost.
Lazy Loading Strategy
The third optimization, and arguably the most important, is lazy loading. The initial bundle contains only what the player needs to see the title screen and play level one. Everything else — additional level packs, settings UI, alternate themes, premium content — is loaded on demand, in the background, after the player is already playing. This is what lets us ship a 60-level game with a 1.8 MB initial payload instead of a 9 MB one. The lazy loader uses the Intersection Observer API to prioritize content the player is about to interact with, and falls back to a simple time-sliced background fetch on browsers that do not support it.
The fastest asset is the one you do not ship. The second-fastest is the one you ship after the player is already playing.
The one failure mode we watch for in lazy loading is the "stall" — the moment a player completes level one faster than the network can deliver level two. Our mitigation is a pre-fetch budget: the next two level packs are always pre-loaded in the background the moment the player starts the current level, and a small inline loading indicator is shown if the player clears faster than the prefetch can keep up. The indicator is rare on broadband, common on throttled 3G, and never blocking — the player can always start the next level the instant the data arrives.
Week 4 — Launch: CDN, Monitoring, Feedback
Week four is the week where everything either comes together or falls apart. The game is built. It is optimized. Now it has to be shipped, monitored, and improved. The launch process is itself heavily automated, but the monitoring and feedback loop are intentionally human.
CDN Distribution
Every game ships behind a global CDN. We use multi-CDN routing — primary and fallback providers — with edge nodes in every region our analytics shows player demand. The build is uploaded to a versioned path on object storage, and the CDN is invalidated on launch. The reason for multi-CDN is not paranoia. It is the empirical reality that single-CDN outages happen, and a casual puzzle that is unplayable for an hour during peak is a casual puzzle that lost a meaningful chunk of its D1 cohort. The cost of a second CDN is trivial against the cost of that loss.
Telemetry and Monitoring
Three things are monitored from minute one of launch: error rate, median time-to-interactive by region, and D1 retention by cohort. Error rate is the most operationally important — any error rate above 0.5% of sessions triggers a paging alert, and a build with an error rate above 2% is automatically rolled back. Median TTI by region catches CDN or peering problems before players report them. D1 retention by cohort is the longer-horizon signal that tells us whether the game is actually landing. None of this requires a sophisticated data team. It requires a dashboard, an alerting threshold, and an engineer on call.
Feedback Collection
The last piece is the one most pipelines skip: structured feedback collection. We ship an in-game, one-tap feedback prompt that fires after level 5 and after level 30, asking a single question with a five-point scale. The feedback is routed into the same dashboard as the telemetry, and the researcher reviews it within 24 hours of launch. The point is not to react to individual feedback. It is to spot patterns — a level that loses 30% of players, a control scheme that confuses players in a specific region, a translation that reads wrong in Bahasa Indonesia. The 30-day pipeline does not end at launch. The 30-day pipeline ends when the first week of feedback has been read and folded into the next 30-day pipeline.
What the Pipeline Buys — And What It Does Not
The honest summary is that a 30-day pipeline does not buy you a better game. It buys you a faster answer to the question of whether the game is good. The discipline of week-one prototyping kills bad games early. The discipline of week-two measurable acceptance criteria prevents shipping un-tuned content. The discipline of week-three optimization prevents shipping a game that fails on low-end devices. The discipline of week-four monitoring prevents shipping a game that fails silently in production. None of these make a mediocre game great. They do, however, make it possible to ship a great game on a schedule that lets you ship the next great game the month after.
If there is one thing I would want another team to take from this article, it is this: the pipeline is the product. The specific 30-day breakdown above is what works for us, for our catalog, for our device targets. The parts that transfer — the prototype-first validation, the measurable acceptance criteria per level, the explicit payload budget, the multi-CDN and rollback threshold — are the structural commitments, not the calendar. Any team that adopts those four structural commitments will ship better games, on whatever cadence they choose. We just chose 30 days, because it forces the discipline to actually be a discipline.