I Shipped a Game With a Team of One and Three AI Tools. Here's What It Taught Me About Running an Efficient Organisation.
I Shipped a Game With a Team of One and Three AI Tools. Here's What It Taught Me About Running an Efficient Organisation.
Where AI agents saved months, where they quietly cost me days, and the three operating rules I'd now bring into any finance team or small organisation.
Last week I launched a game. It's called Age of Startups, a free browser simulation where you start a company with one laptop and try to take it to an IPO. Its message is one I believe: you can build something without outside investment, run it well, and occasionally get lucky.
That turned out to be a fair description of how the game itself was made. No investment, no hires. One person, and three AI tools in clearly defined jobs: Claude as planning partner, Claude Code as the developer, and Google Gemini for images, video and music.
This isn't a post about games. It's about what happens to the work when most of the "doing" is handed to AI agents, because the lessons transferred almost exactly to how I think about running a finance function or a small organisation.
|
293
Code commits across just 24 working days, most of them in a final 15-day push
|
153
Automated tests running on launch day, written and maintained by the AI developer
|
|
614
On-screen text strings translated from Korean into Australian English in a single day
|
3 in 27,000
Simulated games where the in-game books didn't tie to the cash on screen, found the day before launch
|
The org chart of a team of one
The easiest way to explain how it worked is as an organisation chart:
| Role | Done by | What I kept |
| Planning | Claude wrote and maintained the design document and the work instructions | Direction, feedback, every final decision |
| Development | Claude Code built, tested and logged its own work | Checking what had changed |
| Art and sound | Gemini for illustration, video and music; Claude for icons and sound effects | Art direction and final choices |
| Balancing | Simulated "robot players" ran hundreds to tens of thousands of games | Fixing the numbers, and deciding when to stop |
| QA and release | Automated tests, replay checks, builds and deployment | Nine-plus rounds of hands-on playtesting, and approval for anything going live |
Looking back, the biggest change wasn't what the AI did. It was what I did. Over the project, my time moved from approving each step to verifying what had changed. That shift is the whole story.
Where the efficiency was enormous
One source document, one editor. The design document was the single source of truth, and only one tool was allowed to change it. The developer could read it but not edit it. With that in place, the developer would work for twenty minutes or more without a single question. I'd set the work in the evening and wake up to a report. In the final 15 days, that rhythm produced more than 270 commits, and over 40 on the busiest days.
Testing at a scale no person could. I can't play a game hundreds of times to see whether it's fair. Robot players can. They gave me tables: bankruptcy rates by industry (between about 22% and 58% on normal difficulty), how often an IPO was possible, how often investors said yes. Instead of guessing, I was making decisions from a distribution.
Specialist work absorbed into the team. Translation, code protection, release records, a privacy-safe play-logging server. Each of these would normally mean a contractor, a quote and a wait. Here they were simply tasks on the list.
Where it quietly cost me days
Some things still need human eyes. I'd been testing on a fold-out phone. On an ordinary phone held sideways, some text had shrunk to five or six pixels, and I didn't catch it until late. The phone layout was rebuilt from scratch. A family member then found that the in-app browser inside a popular messaging app hid the top line of the screen. Several rounds of playtesting were almost entirely about screens.
A misunderstanding at speed is expensive. I asked for everything to go "into a hamburger button". I meant cards and tabs; the planner understood a system menu, and the developer, running on its own, had already started building it. I stopped it, re-explained, and we re-issued the instruction. The lesson: the more autonomously your team runs, the faster a wrong instruction travels. One sketch would have saved an evening.
You have to check the tools, not just the output. The robot players had bugs of their own. Until those were fixed, their numbers couldn't be trusted. One sensible-sounding balancing rule raised bankruptcy rates by more than 20 percentage points and had to be reversed. Automation doesn't remove review. It moves it.
The moment I'd show any finance team
The game keeps proper books: every week, the closing cash in its cash flow statement should equal the cash on screen. The day before launch, a check accidentally ran at thirty times its normal size, around 27,000 simulated games. In three of them, the two figures differed by between $7 and $96.
The AI developer re-ran those exact games, traced the cause (an expense the screen capped at zero cash but the ledger recorded in full), confirmed the issue pre-dated the latest changes and didn't affect play, and then did the part I liked best: it reported the problem instead of fixing it, because the fix was outside that day's scope. I deferred it to the first patch.
A person might well have written that off as rounding. A reconciliation caught it, and a clear scope rule stopped a last-minute fix from creating a bigger problem. That's exactly what you want from month-end.
Three operating rules I'd bring into any organisation
1. Fix the source document before you automate. Agents work well only when there's one agreed version of the rules and one person who changes it. In a finance team that means policies, procedures and the month-end checklist written down and owned. If the instruction is vague, AI doesn't slow down to ask. It goes the wrong way faster.
2. Move people from doing to verifying, and automate the verification. What made the AI's work trustworthy wasn't faith in the model. It was the checks: tests, replays and that cash reconciliation. Finance already knows this habit as the daily bank rec and the analytical review. Most organisations just haven't applied it to AI-produced work yet.
3. Put approval gates only where the action can't be undone. Going live, deleting live data and wording on the legal pages needed my explicit sign-off. Everything else ran on its own. That's segregation of duties and a delegation framework by another name. It's also why I fixed the game's numbers and launched, rather than tuning forever. Like a budget, at some point you lock it in and manage to actuals.
So what does it mean for headcount?
Claude's rough guess, and it's nothing more than a guess, is that a traditional small studio would have needed five or six people over six to nine months to ship the same scope. I'm not suggesting anyone replace a team with three subscriptions. The point is where the bottleneck went. In this project, it stopped being "how many people do we have?" and became "how clear are my instructions, and how good are my checks?" One project proves nothing on its own, but I'd expect the same shift in any team that hands more of the doing to AI.
One last thing I'd encourage: be honest about who made what. The game's credits list the AI tools separately from people. If an AI generated the music, it says so. The same standard belongs in a management reporting pack or a board paper.
Which parts of your week could run while you sleep?
PFL provides senior-level outsourced finance, management reporting, and AI automation for Australian NFP, NDIS, and SME organisations. The free Finance Function Health Check looks at where your manual work sits, which processes are ready for automation, and where the approval gates need to stay.
Book your free health check →- Age of Startups — the game described in this post (v1.0, released 4 November 2026)
- Anthropic — Claude Code overview
- Google — Gemini
- Cloudflare Pages
Project figures (commits, tests, translation counts, simulation results) are from the project's own version history and work log as at 5 November 2026.
Comments
Post a Comment