An unusual advantage
For a stretch of months, I shipped changes to a live production system with essentially nobody using it.
In most tellings, that sentence is a failure. No traction, no users, no validation. I have felt that version of it too.
But there is another reading, and I have come to think it is the more useful one. Nearly-zero users is a temporary engineering condition with properties you cannot buy back later, and I tried to spend it deliberately rather than merely endure it.
Production as a workbench
When almost nobody depends on your system, production stops being a place you protect and becomes a place you can work.
The normal calculus of shipping is dominated by blast radius. A change that might break something has a cost measured in people affected, and that cost governs everything downstream: release cadence, review depth, rollout strategy, the size of a change anyone is willing to make. All of that machinery exists to manage risk to users.
Set the user count near zero and the calculus inverts. The cost of being wrong collapses to the cost of noticing and fixing, which is one person's afternoon. That makes a specific workflow available that is otherwise unaffordable: ship, test against reality, fix, ship again, several times in a day, on the real system, under real conditions.
I got a lot of value out of that. Some of my best work came from cycles that would have been irresponsible with an audience... changes I could try because trying was cheaper than analysing.
What only reality tells you
The reason this matters more for live production software than for most categories is that the failures are duration failures and load failures.
A test that runs for thirty seconds proves almost nothing about a system that has to run for ninety minutes. Queues that fill, memory that creeps, clocks that drift, connections that degrade... every one of those is invisible in a short test and decisive in a real event. You cannot unit-test an hour of accumulated network jitter.
So the real bench is a real event, on real hardware, on a real network, for a real duration. Running that repeatedly, and being free to break it, is the thing the empty-production window buys you.
Nearly everything I consider genuinely solid in the product came from that loop. The things I am least sure about are the things I have only reasoned about.
The honest half
I am not going to pretend this is a strategy anyone should envy.
Nearly-zero users also means nearly-zero feedback, and there are whole categories of problem that only a stranger can find. I know what confuses a person who already understands the system. I have very little idea what confuses someone arriving cold, and every guess I make about that is contaminated by knowing the answer.
It also means no pressure, and pressure is a genuinely useful signal. Nobody was waiting on me, so priorities came from my own judgement rather than from anyone's actual need. Some of what I built in that period will turn out to have been the wrong thing built beautifully. I will not know which parts until people arrive.
And there is a psychological cost that is real and worth naming, because a lot of people building things are sitting in exactly this window right now and reading it as verdict rather than phase. Shipping carefully to an empty room, week after week, requires believing in something you cannot yet measure. That is genuinely hard, and no amount of reframing makes it not hard.
Spending it deliberately
What I would say to anyone in the same position: the window is an asset with an expiry date, and the expiry is not under your control.
The day someone depends on your system for their event, all of this ends. Not gradually... the moment a real audience is watching a real service, your relationship to risk changes permanently and correctly. You will never again get to break production on purpose to see what happens.
So the question worth asking while the window is open is not "how do I get users faster." It is "what can I only learn now." Things that are cheap today and expensive forever after:
- Breaking things deliberately to observe how they fail
- Restructuring foundations rather than working around them
- Running the whole system for a full event just to see what accumulates
- Making a change that might be wrong, quickly, because reverting costs an hour rather than an apology
I tried to spend it on those. I did not spend all of it well... a fair amount went on things that felt urgent and were not, which is the ordinary tax on working without external priority.
Where this leaves me
The window is closing, which is what I wanted. Real venues are running real events on this now, and every one of those is a person who will have a bad day if I am careless.
I am glad I did the reckless-looking work while reckless was cheap. The specific decisions I made in that period (restructure this, break that, run it for an hour and see) are decisions I could not make now and would not.
If you are building something nobody uses yet: that is not only a deficit. It is also the only period in your project's life when reality is free. Use it on the things that get expensive.
Then look forward to losing it, because losing it is the point.