How the design and technical suites work

Most software starts with code and grows a specification later, if it ever gets one at all. Here it works the other way around. Every game — and this website — begins as two complete, decided-in-full specifications, and the running app is built from them. Those two specifications are the design suite and the technical suite.

Two suites, one source of truth

The design suite is the entire end-user surface, settled before anything is built: the art direction and color system, every screen and the states it can be in, the layout and interactions, the copy, the accessibility rules, and the asset list. If a player can see it, hear it, or tap it, it is decided here.

The technical suite is the engineering: the architecture and project structure, the engine configuration, the services and data contracts, the build and release pipeline, the testing strategy, and the compliance posture. If it has to be wired up to make the design real, it is decided here.

Together, those two suites are the source of truth. The implementation — the Unity game, or this Next.js site — does not invent anything new; it realizes what the suites already decided. When something is ambiguous, the answer is "what do the suites say?", not "what did someone remember in a meeting?"

Single-source: decide once, reference everywhere

A rule runs through all of it: every value is decided exactly once, in one home, and referenced by name everywhere else. A color is defined once and called by its id; a piece of copy lives in one place and is pulled in by key; a game's privacy and support links are owned by the game and read by this website at build time.

The payoff is that things cannot quietly drift apart. This site, for example, generates a privacy and a support page for every game directly from that game's own record — and a check refuses to build the site if any of those links fail to line up. The store listing, the spec, and the code stay in agreement because there is only ever one copy of the truth.

Born-complete

A repository is only considered "born" once both suites are 100% decided and pass their validators — no placeholders, no "to be decided later," every cross-reference resolving to something real. We call that born-complete. The implementation comes afterward, as a faithful build of a specification that was already whole.

It sounds strict, and it is — but it is also freeing. By the time the app is being built, all the hard product questions have answers. The build is about craft and polish, not about rediscovering what the thing is supposed to be.

Why it matters to you

You will not see any of this directly, and that is the point. What you should feel is the result: games that are honestly described, pages that do not break, support that is always one click away, and a studio that sweats the details because the details were decided on purpose.

This website is itself a worked example. It was built from its own two suites, the same way the games are — so the methodology is not a slide deck, it is the thing you are reading it on.