I built BOTTLENECK in 17 days. The journalism took longer than the code.

A queue becomes a brief

In April, I kept returning to the same problem while building BOTTLENECK: how do you make a queue matter to someone who can close the tab? A map can locate a chokepoint. A chart can show the collapse in traffic. Neither makes the reader responsible for deciding what passes through it.

I wanted to put that responsibility inside the interface. In BOTTLENECK, you are a maritime coordinator with three transit slots a day, ten days to work through, and two thousand ships waiting. Oil, food, gas, fertilizer, containers, military escorts. Every choice uses capacity that something else needs.

The game reached production on 27 April 2026. The build and launch materials took 22 sessions across roughly 17 days. The launch codebase contained about 15,600 lines across 72 source files, with English, Polish, and Spanish versions. Those are production figures from that build, rather than a running count of the project today.

I directed the journalism, game design, art direction, sourcing, and review. Claude Code generated the code under that direction. I read, audited, corrected, and re-prompted what it produced. The interesting part of those seventeen days was how much thinking had to happen before an instruction was ready to become code.

Human direction, AI execution

I worked in sessions. Each began with a written brief: what already existed, what needed to change, which references to follow, what to leave alone, and how to judge whether the result worked. The prompts grew into documents of a few hundred lines, with numbered changes, an order of implementation, and checks to run before calling the session finished.

I would inspect the codebase, identify what was missing or wrong, write a session prompt, and hand it to Claude Code. Then I reviewed the changes and played the game. What broke, drifted, or felt false became the next brief. The work moved through that loop repeatedly.

The session documents carried the creative direction. A request for a more serious interface was too loose. A description of the welcome screen, its exact opening text, the hierarchy of information, the palette, and what the player should understand before pressing the first button was something I could evaluate.

This demanded a different kind of concentration. I had to make decisions explicit that I might otherwise have left for a conversation with a developer or designer. The more precisely I described the intended experience, the easier it became to see where the implementation had missed it.

The session documents carried the creative direction.

From prototype to journalism

The first sessions built a single HTML file of roughly three thousand lines. That was enough to test the queue, the decisions, and the endgame. Session five moved the prototype into a Next.js application, separating the interface from the game engine so the work could keep growing.

The next sessions established the map and visual atmosphere: a dark navy surface, shipping lanes, contour lines, and radar-like dots. But the important turn came in session eight. The welcome screen still behaved like a science-fiction mission briefing. It made the player feel like they were entering a command fantasy. I rewrote it to establish the journalistic frame and the human cost of the decisions.

After that, the reporting became more visible throughout the experience. Dispatches linked to original articles. Dossiers gave the interests reacting to the player more context. Analytics opened into sourced information. Real maritime transit data became part of the endgame comparison.

The later sessions were less glamorous: mobile redesign, translation fixes, source corrections, and launch checks. A game can look complete on the desktop where you built it while remaining confusing on a phone or breaking in another language. Those versions were part of the work, too.

The model is an editorial decision

BOTTLENECK draws on more than 125 linked sources and maritime data from Windward, Lloyd’s List, and other named providers. The work of the journalists behind that coverage makes the game possible. The articles remain accessible through the game’s reporting archive and source panels.

That does not mean every number in the simulation is a reported fact. Three daily slots, the ten-day run, the forty modeled ships, and the weights connecting decisions to consequences are choices in a designed system. Published reporting informs that system. It does not remove the author from it.

This distinction matters most in the cascade: how a cargo decision changes pressure on fuel, food, water, or the people and institutions watching the queue. A weight in the code can look like a neutral technical value. In a newsgame, it is also a statement about how the world works. I had to decide what those relationships should express and examine what happened when a player acted on them.

The same applied to political framing. I gave Tehran, Washington, the shipping industry, affected populations, and the player’s credibility a place in the system. I wanted competing interests and consequences to remain visible. The interface had to sustain the difficulty of the situation rather than turn it into a fantasy of effortless command.

Making the reporting reachable

The journalism sits at several depths. Someone can play through the queue and feel the constraint. They can also open the dispatches, inspect the analytics, read the dossiers, and follow links to the underlying coverage. The action creates reasons to look more closely.

The endgame brings the two layers together. It records the player’s choices, compares their transit history with the historical data used in the project, and opens the view onto consequences beyond the strait. The comparison needs to be read as a way into the reporting: the player has operated a simplified system, not reproduced the conditions faced by real people.

I also added a READ THE REPORTING panel, collecting articles encountered during the run. Finishing the game should leave a route back into the journalism. The attention the game earns can carry someone toward a source they would never have opened from a headline alone.

The visual language serves that route. Oversized type, dark surfaces, sharp corners, and mechanical transitions give the interface a specific atmosphere. On mobile, ship decisions became swipe gestures. Across both versions, I kept bringing human consequences closer to the decision itself, where the player would have to see them.

The bugs were part of the argument

One launch check found an inversion in the relationship between toll payment and Tehran’s response. Another found incident timing shifted by a day. A further correction stopped an extra end-of-day change from affecting the final verdict. These were implementation bugs with editorial consequences: the game could tell the player something different from what I had intended.

Source review also changed the work. An article had the wrong outlet label. Links needed repointing. Wording around a ceasefire proposal needed correction. Dates needed reconciling. A working button or a successful build could not settle any of those questions.

Translation exposed another class of failures. A mismatched Polish key could crash a screen. English strings appeared in translated views. Spanish currency formatting needed attention. At launch, the interface contained 792 translation keys in each of three languages. Matching the number of keys was useful, but reading and playing the translated interface still mattered.

Even typography produced a hidden failure. A Tailwind color token named base collided with the existing text-base utility and disrupted a pull quote at a particular breakpoint. The screen looked right in one view and wrong in another. That is the kind of detail a broad instruction to check the design can miss.

The launch audit used parallel AI checks across code, logic, sources, translations, and interface behavior. They helped surface defects. I still had to judge the corrections and what they meant for the experience. AI assistance did not make review optional; it gave me more working material to review.

What the code could do

Claude Code implemented the state machine, day cycles, slots, incidents, cascade calculations, and interface components. It built the canvas map, helped carry the design across screens, implemented localization, and worked through bugs under direction.

The launch application used Next.js 16, TypeScript, Tailwind CSS 4, and next-intl. The simulation ran in the browser, with ten engine modules, a Canvas 2D map, and synthesized Web Audio. Keeping the game logic separate from the interface made later changes easier to specify and inspect.

The ability to generate that implementation changed what I could attempt. It did not decide which articles belonged in the project, how a choice should feel, or whether a consequence was fair to the reporting. Those decisions remained mine, including when the generated result looked convincing enough to tempt me to accept it too quickly.

What changed about my work

The clearest change was the distance between an editorial decision and a working version. I could decide that dispatches should be tied to the progress of the game, describe the behavior, and test the result while the thought was still fresh. That made it possible to work on the form through repeated encounters with the thing itself.

It also made the brief more important. Story memos, edit notes, and design instructions have always been part of my work. Here they became the means of building. When the direction was vague, the output drifted. When the direction was precise, I could evaluate it and move forward.

I would not turn one project into a promise that every newsroom can make a game in seventeen days. The time depends on the scope, the reporting already available, and the person directing it. BOTTLENECK relied on substantial work by other journalists and on my own accumulated editorial and design practice. The build clock does not measure all of that.

What I take from it is a practical possibility. A journalist can carry an idea further into a working form, test it, and take responsibility for the decisions inside it. That possibility interests me because I want reporting to reach people through more kinds of encounters.

I will keep building. The next one is already in the brief stage.