Make a Software-Company Sim with a Checkable Revenue Loop

A software-company simulation needs one visible tension: spend the month building toward a release, or use scarce staff time to sell and support customers. Start with two monthly actions, one feature milestone, one existing payer, one waiting trial, and a simple billing close. Those few pieces create a loop a creator can reason through before adding product lines or random events.

Northstar Desk is an original fictional teaching scenario. Its credits, accounts, rules, and three-month comparison are manually calculated design assumptions, not a real company, industry benchmark, AI output, playable build, or tested result.

Start with a game-sized studio

Choose a company small enough that each staff assignment changes something the player can see. Northstar Desk has one in-progress feature, one paying account, one trial waiting to convert, and two staff actions each month. The goal is not to simulate every part of a real software business. It is to make the connection between project progress, customer growth, retention, and cash easy to follow.

Keep the feature progress display blank at the opening. Its release threshold is the single rule that will change between the paper versions, so the opening scene should not reveal a two-point or three-point target. The player sees the work, customer, trial, and action choices first.

Write a loop with explicit action availability

Give each action a cost, a gate, and a visible effect. Assign exactly two action points, then resolve them in the selected order. Build adds one feature point and stops once the feature is released. Sales is unavailable until release; when legal, it converts the one waiting trial before billing. Support protects one paying account that existed at the start of the month from cancellation.

After assignments, release any completed feature. Resolve an eligible sale next. Then cancel an unprotected start-of-month payer, if one exists; a newly converted account cannot cancel until a later month. Bill four credits for every account still active and subtract two credits of fixed studio burn once. Cash changes by active accounts × 4, then −2. There is no debt, tax, late payment, extra cost, random event, or second trial in this teaching model.

This order matters. If Support protected the original account, it remains for billing; if Sales converted the trial after release, that new account also pays this month. Stating the order prevents a spreadsheet-like screen from hiding when a sale, cancellation, or revenue tick happens.

Hand-resolve three months before adding more systems

In v0, the feature needs three Build points. The example assigns Build + Support in all three months. Support keeps the original payer active, while each close adds four credits and removes two. Month 3 releases the feature, but the second action has already gone to Support; the trial remains waiting and Sales cannot happen until a later month.

The fictional objective is at least two paying accounts and at least 18 credits by the end of Month 3. V0 misses both checks: it ends with one payer and 16 credits. That is a result of the chosen rules and action schedule on paper, not a report about real software companies or a measured game balance.

Change one rule and recheck the close

Now change only the release threshold, from three Build points to two. Keep the starting cash, customer, trial, action budget, action effects, billing, and close order exactly the same. Months 1 and 2 still use Build + Support, but the feature releases one month sooner. The next image shows the v1 Month 2 state after that second Build point.

With the feature released, Sales becomes legal in Month 3. Assign Sales + Support: Sales moves the trial into the paying row before billing, while Support protects the original customer. The close now bills two active accounts.

The difference is not “the same schedule with a better score.” The lower threshold changes when Sales becomes available, so the Month 3 actions change from Build + Support to Sales + Support. A reasonable design hypothesis is that a shorter first milestone may make the choice between shipping and growing the customer base legible sooner. This comparison cannot establish that players prefer the shorter threshold, that the economy is balanced, or that a generated game will implement the rules as written.

Turn the rule contract into a focused build request

After the paper trace is clear, give a future prototype one job: display the two actions, enforce release-gated Sales, resolve Support before billing, and show the resulting state. The following starter prompt is unrun guidance, not evidence that Northstar Desk exists as a playable game.

Make a small software-company management game called Northstar Desk from this fictional rules brief. Start with 10 credits, one paying account, one waiting trial, feature progress 0, and two staff actions per month. In each month, assign exactly two actions among Build, Sales, and Support. Build adds one point until the feature releases. Sales is unavailable until release and converts one trial before billing. Support protects the oldest payer that existed at month start; without it, that payer cancels before billing. At close, add 4 credits per active payer and subtract 2 credits once. Show state feedback after each step and restart to the opening state. In version 0 release at 3 Build points; in version 1 release at 2. Make the same starting values visible so a player can compare both versions.

When inspecting a future build, replay the same choices from the same start. Check that Build stops at release; Sales is disabled before release and converts before billing; Support protects the start-of-month payer; a new payer cannot cancel immediately; and cash uses the stated close formula. If a result differs, note the exact transition and revise one rule before adding random events, more features, or extra customer types.

The current Free AI Game Maker page describes plain-English game input, a playable 2D or 3D first version, browser testing, and refinement with follow-up prompts. It advertises free Koins and says to review the displayed cost before each generation; its cost FAQ says to check the selected model, Koin balance, and displayed cost in Workspace. These are general workflow facts, not confirmation of a software-company simulation preset or this finance logic. Free AI game maker

Keep the first loop small: two monthly staff actions, one release gate, one renewal risk, and a close that can be checked by hand. The threshold comparison gives a creator a focused question for a later prototype, not proof of fun or a business forecast. If you explore the idea in a creation workflow, carry the action order and starting state with you, inspect the visible result, and change one rule at a time.

Frequently asked questions