My drinks stall sold thirty-seven cups. I had only bought thirty.
For a moment I was pleased with the money on the screen. Then I looked at the stock counter. Somewhere in the code, seven drinks had appeared from nowhere. Running a business would be much easier if that were allowed.
I’m making a small browser game with AI: you run a drinks stall, buy supplies, choose a price, and try to keep enough money for the next day. I want it to be something people studying IGCSE Business can play while learning. The first version is an HTML file with the styling and JavaScript inside it, so it can open in a browser without an installation.
I started by describing the game in ordinary language. Give the player a budget. Let them buy ingredients and cups. Add customers, weather, and an end-of-day summary. The AI produced a working screen much faster than I could have built one myself. There were buttons to click and numbers that changed. It already looked enough like a game that I wanted to keep adding things.
Then the stall sold those extra seven drinks.
I asked the AI to make sales stop when supplies ran out. That led to another question: which supplies? Having fifty cups would not help if there were only enough lemons for twenty drinks. I needed to decide how much of each ingredient one drink used. Even a very small stall needed a recipe before its stock figures meant anything.
The price slider caused a different problem. In an early version, raising the price was an easy way to make more money because roughly the same number of people kept buying. I could charge an unreasonable amount for lemonade and still have a queue.
That made me think harder about the customers. Who were they supposed to be? Students with a little spending money? People passing through a park on a hot day? I could ask the AI to make demand fall when prices rose, but I still had to choose how strongly it should fall. Those choices became assumptions in the game. A neat graph would not make them automatically true.
Some parts were easier to check. If the stall paid £30 in daily rent, sold each drink for £5, and used £2 of ingredients and packaging per drink, it would need to sell ten drinks to break even, assuming no other costs or waste. I could work that out on paper and compare it with the game. If the two answers disagreed, there was something to investigate.
I also wanted cash and profit shown separately. Buying a large batch of supplies could leave very little cash, even though some of those supplies would still be available tomorrow. A single green number labelled “money” would hide that. It took a surprisingly long explanation to describe what each number on the screen was meant to include.
This is the part of vibe coding I find most interesting. I can ask for a feature without knowing every line of code needed to build it. But I have to be specific about what should happen. “Make a realistic business game” leaves an enormous amount for the AI to guess.
For now, I’m keeping it to one stall. Pricing, stock, fixed and variable costs, and cash flow already give the player plenty to think about. Later I would like to add simple market research, so players can ask customers what they want before spending money on a new drink.
At the end of each trading day, I want the game to ask what the player would change tomorrow and why. Someone might lower the price. Someone else might keep it and buy less stock. The explanation matters, especially if they can point to something that happened during the day.
It is still being built. Before I add another flavour or make the stall prettier, I need to try a day with no customers, a day with no cups, and a day when the player spends nearly everything before opening.
The no-cups test should be straightforward. I am checking it anyway.
Note: The game is in development. The specific development episodes in this post are illustrative simulations, not verified test results.