A roadmap is a promise made to time rather than to quality.
This is not a criticism of roadmaps. For a team with obligations to stakeholders, dependencies across functions, or a product that integrates with other products, a roadmap is necessary. The calendar coordinates people. Without it, nothing ships at all.
But there is a category of promise that a roadmap cannot make, and that is the promise that what ships will be finished. A roadmap can promise dates. It cannot promise that the work will be good when it arrives on those dates.
Quietfield does not have a roadmap. We have a release condition. It is this: the work ships when it is finished, and not before.
Finished is a specific word. It does not mean complete in the sense of containing every planned feature. It means that every part of what we have chosen to include has been thought through, tested against real use, written carefully, and checked. The privacy policy is filed, reviewed, and accurate. The extension handles the edge cases we have found. The copy has been read aloud and corrected. The product page says what the product does without saying anything untrue. The design is consistent with the system. Nothing was shipped to make the calendar.
I learned the cost of the alternative at scale. When you are building something used by tens of millions of people, you learn very quickly what happens when you ship before the work is finished. You learn it in support tickets. You learn it in the posts people write when they find the thing you thought was minor. You learn it in the erosion of trust that accumulates slowly across many small shipments that were mostly right.
Mostly right is a very expensive standard to maintain. You spend more effort managing the consequences of mostly right than you would have spent getting it right before shipping.
The counterargument is well-rehearsed. Shipping early gets you real-world feedback. Waiting for finished means waiting forever. Perfect is the enemy of good.
These arguments are correct in the context for which they were developed: consumer software at scale, where the cost of one wrong feature is small relative to the information you gain from shipping it. For a small studio building privacy tools for people who care about the details, the tradeoffs are different. Our users are not a forgiving majority tolerating minor imperfections in exchange for free software. They are a specific audience who can tell when something was shipped before it was ready.
We also do not have the engineering capacity to manage the consequences of mostly right. A team of one or two cannot both build the next thing and manage the technical debt of the last thing that shipped too early. The path forward is to slow down enough to ship things that do not require emergency remediation.
This means we announce nothing until we are close to finished. We do not tweet about upcoming features. We do not run a public beta that trains users to expect the product to be different in six months. We do not take pre-orders or run waitlists. We tell people when the thing is ready, and then the thing is ready.
What we lose by not having a roadmap: the marketing value of talking about what is coming, the community of people who want to feel involved in the process, the possibility of feedback from users before launch.
What we keep: the ability to change direction until the last moment without having to manage disappointed expectations. The freedom to decide that a feature we planned should not ship. The standard that when something leaves this studio, it is finished.
The calendar is not the brief. The work is the brief.