• 

• 

Token Cart Tycoon

Inspiration

I wanted to create an educational game that explains what operating an AI product actually involves without requiring the player to already understand the dynamics, economics, or lingo. I also have an obsession with the old game called Hot Dog stand. I had to come up with a way to make the old game relevant again and all the sudden the light in my head lit up.

It was time for Token Cart Tycoon to be created, and Sol was ready for the challenge.

I have always enjoyed classic management games, like Hot Dog Stand, where the player studies the news, predicts demand, buys supplies, and then discovers whether their decisions worked. I wondered what that structure would look like for a modern AI startup. Instead of managing ordinary inventory, the player would need to manage compute, RAM, GPU capacity, model quality, subscriptions, customer trust, and their own ability to keep functioning as a founder. For me this seemed like so much fun. I just love when learning is fun.

That idea became Token Cart Tycoon: a cozy-chaotic strategy game in which an AI company begins with a hot dog cart, one laptop, $500, and five subscribers. It wasn't a perfect science at first, but GPT 5.6 Sol and I were ready to start creating and testing.

The first prototype was intentionally small, but playing it revealed an important problem: it was cute and responsive, but the choices did not require enough strategy. That realization shaped the final project. I wanted players to make predictions, commit limited resources, and then understand exactly why their startup succeeded or struggled.

What it does

Token Cart Tycoon simulates the first 30 days of an AI startup.

Each day, the player:

1. Reads a market, supply, technical, or trust signal in The Token Times.
2. Forecasts demand and compares it with the startup’s available capacity.
3. Adjusts subscription pricing, model tier, and burst-compute policy.
4. Purchases infrastructure such as RAM, GPU capacity, caching, or monitoring.
5. Chooses where to spend the founder’s attention and opens the app for the day.

The resulting operations report shows demand, served and dropped requests, latency, revenue, inference costs, subscriber growth, churn, trust changes, and incidents.

The systems are deliberately interconnected. A better model can improve product quality while consuming more compute per request. Marketing may attract new users, but promoting an app before increasing capacity can cause latency, dropped requests, churn, and lost trust. Caching improves efficiency, monitoring limits outage damage, and raising prices can improve unit economics while reducing demand.

The objective is not simply to make every number increase. The player must build a company that can survive its own growth.

How I built it

Token Cart Tycoon is a dependency-free, one-page browser game built with semantic HTML, modern CSS, and vanilla JavaScript modules.

I used GPT 5.6 Sol Medium to build it with Codex in the ChatGPT Desktop app. Sol separated the serializable simulation state from the interface so the economic and operational systems could be tested independently of the browser.

When collaborating with Sol, we came up with news, incidents, upgrades, founder actions, and model tiers are data-driven, making the game easier to balance and explain.

The project includes:

• Forecast-driven demand and subscriber behavior
• Persistent RAM and GPU infrastructure
• Multiple model tiers with different quality, cost, and throughput characteristics
• Pricing and subscription revenue
• Caching, monitoring, and burst-compute systems
• Conditional outages, trust incidents, and market events
• Founder sanity and competing attention costs
• Responsive desktop and mobile layouts
• Reduced-motion support
• Repeatable simulation tests

I avoided paid APIs, runtime AI calls, downloaded artwork, third-party services, and unnecessary dependencies. The submitted game is completely static, allowing judges and players to open it immediately without credentials, secret keys, quotas, or backend availability. Its visual identity was created with original CSS artwork, typography, interface elements, and simple shapes.

I collaborated with OpenAI Codex using GPT 5.6 Sol Medium throughout development. Codex helped translate my concept into a maintainable architecture, implement and test the interconnected simulation systems, improve responsive behavior, perform browser QA, prepare the deployment, and document the project. They also helped me create my demo video from start to finish and created all of the artwork with me for the game.

I made all the key human decisions: the original concept, educational purpose, hot dog cart metaphor, 30-day format, starting resources, strategic direction, visual tone, scope, intellectual-property restrictions, and final approval of the gameplay and presentation.

Challenges I faced

The largest challenge was making the game educational without being too complicated or turning it into a spreadsheet.

Every mechanic needed to be understandable on its own while still affecting other parts of the company. Compute was especially challenging. Treating it as a simple resource bar did not accurately communicate infrastructure planning, so I redesigned it as persistent capacity. When capacity is insufficient, the consequences now appear as latency, dropped requests, churn, trust loss, and missed revenue.

Another challenge was event repetition. The original prototype could show the same cards too frequently, making the game feel arbitrary. I replaced that behavior with a shuffled 14-card news deck and state-dependent incidents that cannot repeat immediately.

Balancing was also difficult. Growth needed to feel rewarding, but reckless growth needed visible consequences. I used repeated simulations and browser playtests to tune the relationship between demand, pricing, capacity, costs, churn, trust, and founder sanity. Founder sanity is an important dynamic.

Finally, I needed to keep a fairly information-dense management interface readable on both desktop and mobile. This required careful prioritization of forecasts, controls, resource meters, and daily results.

What I learned

The most important thing I learned is that educational mechanics work best when the lesson appears as a consequence of the player’s own decision, and that Sol is an amazing collaborator.

A warning that says “check your capacity before marketing” is easy to ignore. Watching half of your requests fail because you promoted the app before buying infrastructure makes the same lesson immediate and memorable.

I also learned how strongly AI product decisions depend on one another. Model quality, compute consumption, pricing, trust, support, growth, and founder capacity cannot be optimized independently. Every advantage has an operating cost, and every shortcut creates risk somewhere else.

That became the central lesson of Token Cart Tycoon:

Demand is not the same as success. A sustainable AI product must be able to serve the users it attracts.

Built With

• codex
• css
• html
• javascript
• sol