An idle game about running your own AI coding shop: tap to prompt, hire AI agents, ship products, sell the company. Built by five people and their AI assistants, and the premium purchase inside the game is the real tool that built it.
Inspiration
All five of us build software with AI agents every day. Each of us runs our own coding assistant through PAPI, a plan → build → review framework with looped cycles, one shared board, one repo, one decision tree. When the Shipaton needed an idea, the honest answer was right in front of us. We made the life we already live playable.
Idle games were the natural fit. They are games about systems running while you decide where your attention goes, which is exactly what working alongside a team of AI agents feels like. So the game became what we do: you run a vibe-coding shop, agents burn tokens to ship client jobs, and you grow from tapping prompts yourself to running a whole studio. The satire is affectionate because we live it, and the game itself was built by AI assistants end to end.
What it does
You see a coding terminal. Tap to prompt, the job ships, you get paid, the next job starts. Spend Cash to install AI agents at your office desks, a cast of cats in human clothes, each adding a prompt every second so the work keeps moving between taps. Harder jobs need more prompts and pay more.
The game changes as you grow. You start as a Solo Coder tapping prompts by hand. Once your agents take over the prompting, your job becomes managing tokens, cash and the roster, and buying tools on the Tool Bench. At Established Company you unlock Product Studio, where up to three products earn Cash every minute. Five company stages run from Solo Coder to Software Business, each opening more desks. At the top you can sell the company, keep your Prestige Points, and spend them on permanent skills named after real coding skills like Git and TypeScript.
When a job finishes you choose: ship it and keep the agent moving, or have the agent review the work first, which lowers the chance of a hidden bug surfacing later. Bugs that do surface become incidents that cost you Reputation and slow the team down.
The premium purchase is PAPI itself, the real tool this team used to build the game: one-time, optional, and the game is fully playable without it. PAPI owners earn more while away, prompt faster, and never watch an ad on a rewarded claim. Ads are optional rewarded videos only. No banners, no interstitials.
How we built it
Five contributors, each driving their own AI assistant (Claude Code, Codex, OpenCode, GLM), all shipping into one repo at once. The catch: each assistant lives in its own context window and none of them can see the others', so PAPI's board was the only shared memory. Work not written to PAPI did not happen.
Everything moved through plan → build → review → release cycles governed by live Active Decisions, superseded rather than overwritten so the reasoning trail from the first wireframe to the shipped build is intact. Teammates cross-reviewed each other's builds, because each assistant has different blind spots. The stack is Expo, React Native, TypeScript and Zustand, with versioned local saves and a deterministic integer economy. RevenueCat lives behind one typed wrapper, and notifications are wired to OneSignal through a provider-neutral layer.
The whole build is public. Every task, build report, learning and decision is browsable at https://getpapi.ai/projects/vibetycoon
Challenges we ran into
- We entered late, and Google Play's clock cannot be compressed. The decision to enter landed on August 18. New-account rules demand twelve testers opted in for fourteen continuous days before production access is even available. Closed testing started August 31, we went live September 26, and the deadline was September 30.
- The entry gate almost didn't exist. A live RevenueCat purchase is mandatory to enter, and when we started, the RevenueCat dashboard wasn't set up at all. That became the critical path for the first month.
- The bugs only real economies reveal. On day one, every profile's tokens hit zero with nothing to replenish them. And the first rewarded-ad build would have granted rewards for ads that never played. Both were caught in review, not in production.
- The tutorial taught a retired surface. It pointed new players at a job board the shipped loop had already replaced with a prompt codebox. The first five minutes and the actual game disagreed.
- The store build lagged the code. Four days before the deadline the store was three releases behind main, so the final week was a sprint to get the shipping build current.
- The first-session economy is the hardest thing to tune. The first hire's price swung wildly in a day before settling into a curve that lets a new player afford their first agent at the right moment.
What we learned
- The first session is the whole game. The day-one token drain mattered more than any late-game feature. Fixing the opening loop became the standard for what ships.
- Offline earnings need a cap. If the game earns too much while closed, coming back stops mattering. We tuned the cap so returning is still the best decision a player can make.
- The tutorial has to teach the loop the player actually has. Ours taught a job board the shipped game had replaced. We only noticed by watching the first five minutes as a player would.
- Feel is measurable. Checking the real font and spacing on every button in every state turned "it feels off" into a list we could fix and test.
- Motion reads as polish only when it is small and optional. Every animation ships with an off switch for players who ask for less movement.
- Verify from the save file, not the screen. Pulling the save database off a device proved the token math exactly and disproved a suspected bug that screenshots would have muddied.
Built With
- admob
- android
- claude
- expo.dev
- firebase
- getpapi.ai
- mobile
- react-native
- revenuecat
- typescript
- zustand



Log in or sign up for Devpost to join the conversation.