Scaling Laws was playable in the second week of August. I published it on 30 August, at half past three on a Sunday afternoon, after telling people it was shipping "today" since the previous Monday. This is what happened in between, written down while it is still uncomfortable to write.
What twenty-nine days produced
The first commit landed on 2 August 2026. The first public build went out on 30 August. In between there were taxi shifts, ten to twelve hours a day, and the evenings after them.
Scaling Laws is an AI company tycoon. You start on 1 January 2022 with twelve million dollars, no product and no team, and you run a frontier lab through the four years that followed. Twenty-two real hardware generations carry their real ship dates and launch prices. An accelerator bought on the day it launches is worth about half of what you paid, that same day, and it loses another quarter every time a better one ships.
That one fact is the whole game. You are not buying upgrades. You are timing them.
Speed came from one decision made on day one: the rules live in a layer that imports nothing from the engine. No Unity types, no scene, no MonoBehaviour. That means the entire economy can be tested in under a minute without opening the editor, and it is the only reason a game of this density could be written in a month of evenings.
The build was finished in week two
Not polished. Finished, in the sense that mattered: a player could start a company, design a model, train it, release it, watch the market respond, run out of money, and reach an ending. Every part of the loop closed.
I did not publish it for another three weeks.
Here is the honest list of what those three weeks contained. A font two pixels too small, and then two hundred and three more like it. A grants system that worked correctly and fired roughly once every hundred in-game days, so most players would never have seen it at all. A tutorial that dimmed itself when your cursor was on the text it wanted you to read. A rent slider whose full travel was exactly one billion users on the first frame of a company that had none.
Some of that was worth doing. The grants system was genuinely broken as a design, and the slider was unusable. But I could not tell the difference while I was doing it, and that is the part worth writing down. There is no signal inside the work that tells you which kind of evening you are having.
What the fear actually was
I expected it to be fear that the game was broken. It was not. I had 888 automated tests for that, including one that plays a full campaign and fails if a reasonable player cannot survive it.
It was fear that it would be fine, and nobody would come. A broken build is a problem you can fix. Silence is not a problem, it is an answer, and it is the answer you cannot argue with. As long as the build sat on my machine, the question stayed open.
That is a stupid reason to delay a release for three weeks and it is the true one.
Six hours before publishing, three faults
None of them could have been caught by a test. All three were things my own tools were hiding from me.
The game opened in a window exactly the size of your screen
Not slightly too big. Exactly. The title bar sat above the top edge of the display and the game's own bottom bar, the one holding the clock and every tab, sat behind the Windows taskbar. The window could not be resized, because I turned that off eight months ago and never thought about it again. I had never seen it once, because the Unity editor draws your game inside its own window with its own title bar. The first thing every player would ever see was the one thing I was structurally incapable of noticing.
The build called itself version 1.0
The changelog said 0.1.0. That is not bookkeeping: the game stamps its version onto every bug report a tester files through the in-game form. Every report from launch day would have arrived filed against a release that does not exist.
A sentence in my README was not true
It said a company that ships one model and coasts is insolvent inside three years, and that an automated test fails the build if that stops being true. The test checks that the company is not still trading after eight years. Nothing had ever measured three. I had been repeating that number in public for weeks because I wrote it once and it sounded right.
The third one is the one that still bothers me. The first two are mistakes. The third is a confident public claim with nothing behind it, made by someone whose entire pitch is that the numbers are real. Documentation is code that nobody tests.
The first numbers back
The build went out free, for Windows, at 75.9 MB, on itch.io, IndieDB, Game Jolt and as a GitHub release.
| Measure | First days | What it tells me |
|---|---|---|
| itch.io page views | ~130 | Small. Expected. Nobody knows this game exists. |
| Views converting to downloads | ~48% | The number I actually care about. |
| Feedback reports received | 0 | The one I wanted most, and it is empty. |
A conversion rate near half means the page is describing the game accurately to the people who arrive at it. If ten thousand people had looked and two per cent had downloaded, that would be a bigger number and a worse result, because it would mean the page was promising something the game is not.
Zero reports is the honest disappointment. I built a form, put a button in the pause menu, wired it to carry the build number and how far into the campaign you were, and wrote on the store page that one sentence about where you got confused is worth more to me than a hundred downloads nobody opens. I meant it arithmetically. So far the box is empty, and that is a result too.
Where the not-quitting comes from
This is the twelfth project I have started and the second that survived. The eleven before PC Workman are dead in the ordinary way: abandoned somewhere between interesting and hard.
Before Radom there was a warehouse in the Netherlands and a forklift. I was barely making the month work. Twice I was put out of agency housing with effectively no notice, and the second time was just before Christmas. I have written elsewhere about being fired on the 22nd of December after five months of building in public that nobody watched. I am not going to dress that period up. It was not character-building at the time. It was just bad, and the only thing I had that was mine was a folder of code on a laptop that ran at 94 degrees.
What I took out of it is narrow and I think it is true: the work being public is what made it survivable. Not because anybody was watching, because for a long time nobody was. Because a public commit history is the one thing that cannot be taken away from you by a phone call from an agency. It is yours, it is timestamped, and it is still there in the morning.
That is also why everything I build is open source. It is not a licensing preference. It started as the only way I could prove to myself that the last six months had actually happened.
What I would do differently
Ship in week two. The three weeks bought a better first impression and cost the only thing that matters at this stage, which is other people's hands on it. Nothing I fixed in that time was worth three weeks of not knowing whether the economy is interesting to anyone other than me.
The city is next: a surveyed blockout across 2048 metres, houses on subdivided plots, offices you rent before you can buy them. It is not in this build and I would rather say that here than have anybody go looking for it.
Scaling Laws 0.1.0 is free for Windows. If you play it, the useful thing to tell me is not whether you liked it. It is the exact minute you stopped understanding what the game wanted from you.
Questions people ask about this
Why do solo developers delay shipping a build that is already finished?
Because polishing and avoiding feel identical from the inside. Both involve opening the project, finding something imperfect, fixing it, and producing commits. The difference is only visible from outside: polishing improves what a player will notice, avoiding improves what only the author will ever see. In this case the build was playable three weeks before it was published.
What faults are most likely to survive until the day you ship?
The ones your tools hide from you. The Unity editor draws your game inside its own window, so the real window is the one thing an author never sees. Three faults were found six hours before release and no test could have caught any of them.
How many downloads should a first indie build expect?
The conversion rate is a stronger signal than the download count. Roughly 130 page views with about 48 per cent converting says the page is honest about the game. A large view count with low conversion would be a bigger number and a worse result.
How long does it take to build a playable game alone?
Twenty-nine days here, in evenings after ten to twelve hour shifts, producing 174 public commits and 909 automated tests. The speed came from keeping the rules in a layer that imports nothing from the engine, so the whole simulation tests in under a minute.