The Work Before the Finish Line

Thirty years of developing software and twenty of making games teaches you to recognize the bill before it arrives.

The first shortcuts are rarely dramatic. A build number lives in somebody's memory. A server rule is duplicated in the client because it is faster that afternoon. A release command quietly does two jobs. A decision survives in a chat but not in the repository. Each choice is understandable. Months later, the team pays for all of them at once: in lost context, uncertain ownership, brittle releases, and the slow erosion of player trust.

When I started Wordulate at the beginning of June 2026, I wanted to see whether a new kind of small studio could avoid some of that debt without moving like a large one.

My career included helping lead Words With Friends and Wordscapes. Wordulate is an independent project, but it carries forward what those games and their communities taught me about clarity, habit, skill, and trust.

The original prompt was ambitious and blunt. Build a mobile home for intelligent games, beginning with a word puzzle played on a field of hexagonal letters. Make it free to play, analytics-first, offline-capable, scalable, and server-authoritative where fairness or value is at stake. Keep the code and directory structure unusually clean. Then, before building too far, question the plan relentlessly, one decision at a time.

That last instruction mattered as much as the feature list. I did not want an AI to guess its way toward a game. I wanted a collaborator that could help turn product judgment into inspectable work, while leaving the judgment where it belonged.

Wordulate is still in development and internal validation. This is not a launch story. It is the story of what we chose to build before claiming we were ready.

Fast, but not vague

The earliest work was player-facing: turn the honeycomb idea into a mobile session that could be judged by touch. The board had to answer immediately. Selected letters had to remain legible. Sound, haptics, rewards, the first lesson, progress across a restart, and the Daily Puzzle all had to feel like parts of one game rather than separate demonstrations.

The repository shows the sequence clearly. Early June was product definition and the first-session prototype. By mid-month, the game had a stronger visual and audio pulse. The third week brought an Android tester-build lane, a Firebase-backed launch service, typed API contracts, and the first disciplined split between mobile and backend work. Late June connected Daily play and telemetry to those boundaries. July's internal-device failures across connectivity, persistence, responsiveness, content quality, and startup behavior then shaped the next round of work. The path was not a feature parade. It was a tightening loop between intent, device evidence, and repair.

That work exposed the systems underneath it. A word game asks for trust on every submission. If a familiar word is rejected, if progress disappears after an update, or if a Daily board waits on a network response before acknowledging the player, the technical explanation does not matter. The player experiences one thing: the game broke its promise.

So the team treated dictionary coverage, local responsiveness, content validation, persistence, and server reconciliation as product work. Reports from internal builds became issues. Issues became bounded changes. Changes had to bring evidence back with them: a deterministic smoke test, a validation report, a cold-launch check, or a real-device result.

Codex made that loop faster, but it did not make the loop optional.

A team defined by accountable chairs

The working team is small enough that its roles are better understood as accountable chairs than as a conventional org chart.

Founder/Product decides what game Wordulate is, which risks are acceptable, what deserves priority, and when evidence is strong enough to make the next call. Production coordinates the sequence of work, keeps launch gates visible, and stops a lower-priority improvement from slipping ahead of a trust failure. Client engineering owns the mobile experience, device behavior, local persistence, audio, input, and build lane. Server/shared engineering owns the API, Firebase-backed state, shared contracts, content authority, and operational tooling. The Game Director reviews narrow changes against the intended experience and can approve, request changes, or hold a merge. The Analyst defines launch-health questions and insists that dashboards distinguish real data from empty scaffolding. Marketing protects the founder voice, the public promise, and the line between useful specificity and premature disclosure.

Codex works across those chairs as a practical collaborator: reading the current source of truth, drafting code and documents, running checks, gathering evidence, and carrying review feedback into the next revision. The founder still makes the consequential decisions. Production still controls sequencing. Review still has the power to stop the work.

That separation is not ceremony. It is how a fast-moving project remembers who owns what.

How Wordulate ships

Work begins with a founder decision and a deliberately small lane. Mobile, backend, shared tooling, product, and analytics changes are kept separate unless a contract truly crosses a boundary. Each lane uses an isolated Git worktree, which lets focused changes move without turning one working directory into a negotiation.

Pull requests are intentionally narrow. They state scope, non-goals, validation, risks, and the handoff to the next owner. CI checks TypeScript, content, smoke paths, and lane boundaries. Game Director decisions are recorded against the exact reviewed change.

A backend merge is not considered operationally complete merely because GitHub is green. Changes to app-callable behavior go through internal deployment checks before they are treated as ready for device validation. Internal deployment checks verify the intended environment and contract before traffic shifts.

Mobile work follows a parallel discipline. EAS creates Android and iOS artifacts; Google Play Internal Testing and TestFlight paths make signed-device validation repeatable. A checked-in release ledger keeps build identity reviewable. Most importantly, creating a build is not permission to submit it. Store submission requires a separate, explicit approval checkpoint.

That rule came from experience, not abstraction. Release systems have side effects. The safe response was to make authority explicit in tooling.

Wordulate technical stack

Wordulate's implemented stack is more modest than its long-range architecture documents, and that distinction is deliberate.

The mobile app is React Native on Expo, written in TypeScript and built with EAS. It lives in a pnpm monorepo beside shared types, game-core logic, a typed backend client, the backend service, content tools, analytics templates, and process documents. The app keeps input and feedback responsive locally, persists approved local state, and uses server-shaped commands and reconciliation paths for work that crosses the authority boundary.

The backend is a TypeScript REST service with shared contracts and an OpenAPI description. Firebase Admin and Firestore provide the current launch-track storage adapter, while Cloud Run provides the deployed API runtime. The boundary matters more than the vendor: progression, rewards, and competitive state should be confirmed by the server; the client is responsible for an immediate, resilient play experience.

Firebase Analytics and Crashlytics provide a narrow launch-health path in signed builds. Firebase Performance is used for coarse release-readiness signals, with the implementation designed to avoid sending words, clue text, or player identifiers in custom performance traces. A BigQuery view layer and Looker Studio design exist for launch-health reporting, but empty adapters remain visibly empty until exported rows are reconciled. No placeholder is allowed to masquerade as a metric.

What Codex changed and what it did not

Codex changed the practical surface area of the studio. It could move from a founder decision to a focused PR, hold the relevant contracts in context, update the checklist, run the test suite, inspect a device failure, and return with evidence. It could keep client and server work moving in parallel without asking the founder to become a courier between every conversation.

But speed created its own risk. AI can produce more motion than a person can responsibly review. It can generate documentation faster than a team can discover which document is authoritative. It can make a repository look finished because the scaffolding is thorough.

The answer was not to trust the AI more. It was to build a workflow in which claims had to survive contact with code, CI, deployment, devices, and a human decision.

That may be the most useful thing we have built since June 1. Not an automated studio and not a substitute for taste: a small production system with memory. One where the founder can still change his mind, the Game Director can still say hold, the Analyst can still say the data is not ready, Marketing can still say a claim is premature, and the release tooling can refuse to act without explicit authority.

Thirty years into software development and twenty years into making games, I am not trying to remove the messy human work. I am trying to give it better footing.

Wordulate still has to earn its way into players' hands. The foundation does not guarantee that the game will be good. It gives us a more honest way to find out.