Launch Control: The Point of No Return

We just did a major launch and you know what? No one noticed. Yet!

And that’s just how we wanted it to be.

It's like a secret marriage between our production backend and the upcoming big release. No announcements. No invitations. We're saving the fanfare for the public launch events later on.

Until we do tell everyone, we have a big "undo" button we can push if we've made a mistake. Why would you ever not want that safety net?

🚀 Meanwhile, I still see people taking software to market in rocket launch mode. Big bang releases with customers primed to hit refresh at 6pm exactly.

This can lead to spectacular glory, spectacular failure, or—more likely—days of firefighting issues that never surfaced in testing.

🎅 When I was at Opera Software, we launched the first Opera for Linux on Christmas Eve (the big celebration day in Norway). Nice idea in theory—giving our users a Christmas present.

But as software companies often do, we forgot their focus would not be on us that day.

There is this expectation from software companies sometimes that our launches are big events in our customers’ diaries. It generally is not.

​​You get a brief window to make an impact, but then you need everything working flawlessly. A failure at that moment damages confidence in your ability to provide a stable platform. Too many radical changes at once hurt your customers' ability to maintain stable workflows without constant retraining.

🏁 The best you can do for your customers and yourself is a phased approach. Improving gradually, with carefully prepared releases and constant forward momentum.

For space launches, the testing and cost required to prevent failure is astronomical.

We don’t have to do things that way. Instead:

🖖 Separate your changes. Make database, backend, and frontend updates independently. Split major changes into smaller iterations.

🧪 Test relentlessly along the way. You can still do big public launches, but ensure the underlying changes are released and validated in smaller chunks first.

⚖️ Compatibility is king. Never negatively impact your customers' APIs or workflows without clear migration paths.

🔐 Empower your gatekeepers. Give your QA and Ops teams authority to ensure stability before anything goes public.

↩️ Keep that undo button ready. If something still goes wrong, rewind. This is your safety net.

Launching software should not mirror launching rockets. We don't need all-or-nothing stakes. Make smaller iterative changes, maintain your rollback capabilities, and save the fireworks for when you're absolutely certain everything works.

Your customers, as well as your staff, will thank you!