Software release readiness: how to decide whether to launch

A software release decision should rest on tested scenarios, known gaps and the ability to handle what happens after launch. The target date matters, but it is not evidence of readiness. Before launch, request a short decision record: what works in the specific version, what remains untested, who accepts the risk and when distribution should stop or narrow. This protects users and the time reserved for the next stage of development.

What does the Cities: Skylines II development change illustrate?

In April 2024, Colossal Order and Paradox acknowledged that Beach Properties had been released in an unsuitable state. Their official announcement described compensation and refunds where possible, a focus on improving the base game and postponing a planned expansion to 2025. This is a historical account of the companies' decision, not our claim that the entire team spent a year fixing defects or that every future plan was cancelled.

Our lesson for software buyers is that the cost of an unready release includes displaced work. Repairs, customer support and repeated testing compete with time intended for new capabilities. Counting bugs on launch day cannot capture that cost alone. Identify which processes could be affected, who will handle them and how much capacity remains for future development while the released version stabilises.

Separate completed tasks from readiness for use

A completed task list records what the team implemented, but does not necessarily show what a user can finish. Start with the most important journey: entry, a business action and a result saved and accessible to the right people. Ask for evidence from the version intended for release in the relevant environment. An old demonstration video or a successful screenshot cannot replace checking the journey after recent changes.

Alongside normal operation, test an expected failure: an interrupted connection, missing information, insufficient permission or a repeated submission. There is no need to promise a world without failures. There is a need to define what happens and whether the user can recover without losing work. Establish these requirements during the technology product specification, rather than turning them into a scope dispute on the eve of launch.

Agree which gaps block release

Not every defect needs to stop a release, but the distinction must be agreed. A failure preventing a central task differs from a wording issue that does not change meaning. In a hypothetical example, an order-persistence failure matters more than minor misalignment in a secondary area. Prioritise by user impact, exposure and recoverability, not by how easily a developer can close the ticket or how visible it is in a demonstration.

For every accepted non-blocking gap, record an owner, a workaround and a review date. If the workaround depends on manual handling, confirm that someone is available and authorised to perform it. Otherwise it is an assumption rather than a solution. Explicitly identify untested areas too: missing evidence is not a passing test. The release approver needs to see uncertainty alongside the green checks.

A documented example from our own website release

Julius's October 15, 2026 website release record includes build and lint checks, focused tests and live form checks on both domains. Clearly marked test enquiries were read back from CodeManage, and verification distinguished enquiry persistence from consented Umami measurement. The record also noted limitations, including the absence of cross-page campaign attribution. This is evidence about a specific release, not a guarantee that every possible state was tested or that business performance improved.

The useful lesson is that a release decision can contain successes and limitations in the same document. Confirming a saved CRM enquiry does not confirm a booked meeting, and a technical crawl check does not establish Google rankings. Precisely describing evidence makes it possible to decide whether a remaining gap is acceptable for the planned scope. There is no need to change what a test means to make the version appear more ready than the evidence supports.

Plan for the days after launch

Decide who receives alerts, who can stop a capability and how data created since release will be handled. Returning to an earlier software version does not necessarily restore data to its previous state. Ask the team to explain how it will detect problems and keep the service operating during correction. The plan needs to match actual staff availability, including hours when developers are away from their computers.

Reserve explicit time for observation and fixes before committing all capacity to the next development cycle. Where feasible, begin with a limited audience or process and expand after checking results. That limitation must be a real product decision: who gets access, what they may do and which conditions permit expansion. A beta label neither resolves a critical failure nor replaces a clear explanation of limitations to users.

What belongs in the final decision?

A short record can identify the version, scope, test results, accepted gaps, responsible people and stop conditions. For an AI product, add evidence of behaviour on relevant examples and boundaries on actions the model may take. Our guide to choosing AI developers explains why a successful model connection is not a product-quality test. Check that evidence applies to the configuration being released rather than a different experiment.

Before meeting Julius about software development, prepare the target date, the journey that must work and the business cost of delay or failure. Evidence can support a full release, narrower scope or a focused postponement. For build-duration planning, also read how long an MVP takes. The readiness decision is where the team checks what has actually been achieved by the target date.