Just hit deploy and you’re done

There’s a particular moment in every software project where someone leans back in their chair, exhales deeply and says, “Well. It’s done.” It’s said with the confidence of someone who has not yet opened their inbox the next morning.

The idea that software becomes “complete” the moment it goes live is weirdly persistent. It’s held by people who should know better and people who definitely don’t, and it offers the same seductive comfort as believing that buying gym membership automatically gives you fitness. If only the universe worked like that.

But software has never obeyed the rules of “finished”. Even the U.S. Defense Innovation Board, who are famously not known for whimsical metaphors, describe software as something that is never truly done and must be “managed as an enduring capability”. They talk about it the way you might talk about a heritage building or a problematic uncle. It’s always going to need work.

It’s always going to need attention.

Developers know this. Designers know it. Anyone who’s ever tried to upgrade an operating system knows it. But for some reason, the myth survives, the belief that the release is the exhale after a long sprint rather than the inhale before the next one.

The comforting deception of “Done”

There’s something very soothing about the illusion of completion. It makes budgets look tidy. It makes roadmaps appear achievable. It reassures board members who would prefer not to hear the word “iteration” ever again.

But the moment you treat software like a finished sculpture, you’ve already guaranteed it will age badly. Software lives out in the world. It reacts to things. Browsers update. Phones change shape. A third-party library quietly rots in a corner. Users behave in ways no rational person could predict. Suddenly your app is coughing like a toddler who has just started daycare, and everyone is wondering who approved the design.

The truth is much closer to what Henrik Warne wrote in his blog about maintenance: software doesn’t have two phases - development followed by maintenance - it’s all the same continuous process. New code becomes old code very quickly. “Maintenance” is just the polite word for “keeping this thing alive because we have unleashed it into reality”.

Software as something that breathes… and sometimes wheezes

Think of software like a garden. You can’t just plant a row of tomatoes and walk away forever. Leave it alone long enough and the bugs move in, the weeds throw a rave, and soon the whole thing is unusable. Software behaves the same way. Ignore it and it decays, even when nothing “breaks” in the traditional sense.

Security “bugs” arrive with alarming enthusiasm. Standards evolve. User expectations creep in and take over like weeds. The world never stays still, and your product is dragged along with it whether you like it or not.

The marriage you didn’t realise you entered

This is where the marriage analogy comes in handy. People joke about “committing to a codebase”, but the comparison is fairly solid. The launch is the wedding day - lots of excitement, many photos, perhaps a small cake. But the real work happens afterward.

If you don’t keep showing up, the relationship suffers. Things get brittle. Things drift. You find yourself one day staring at a giant, expensive mess and wondering how it all fell apart. Some companies even go through the tech equivalent of divorce - a full rewrite - and emerge poorer, wiser, and promising never to let it get this bad again.

It’s not glamorous, but it’s honest: if you want to get value out of your software, you have to contribute to it continuously. If you don’t, the software will eventually pack its bags and find someone who will. Or, more likely, your customers will.

What this means for anyone actually building things

If you’re running a company, leading a team, or founding something ambitious, the mindset shift is simple. You’re not building a product that ends. You’re stewarding a product that grows.

This affects how you plan. It affects how you budget. It affects who you hire and how long you expect them to stay. It means acknowledging that the moment you ship version 1.0, version 1.1 is already knocking politely in the hallway.

It also means resisting the urge to cram in everything at launch, because there will be time later. Iteration is not a punishment, it’s your friend. You don’t need to achieve perfection in the first go, it’s impossible. Even the best teams and the most experienced leaders all discover that something they believed to be true before launch is later revealed to be… extremely wrong.

And you know what? It’s fine. It’s the whole premise of Doing Software Wrong. You will always be wrong in someone’s eyes. A user, a reviewer, an engineer on the internet with a suspicious amount of free time. The point is not to be right forever. The point is to care enough to keep improving.

If you think you’re done, You’re already behind

The release isn’t the end. It’s the beginning of the part that actually matters.

If you claim your software is finished, all you’re really saying is that you’ve stopped paying attention. And in this industry, not paying attention is the fastest path to becoming a cautionary tale.

Celebrate the launch. Enjoy the moment. But don’t imagine for a second that you’ve reached the final chapter. You’ve just turned the page to the part with more footnotes, more deadlines, and more unexpected plot twists.

You’re not done. You never will be. That’s the fun and the frustration of it. If you feel slightly uneasy about everything you’re doing… congratulations. You’re doing software and you’re probably doing it wrong, exactly as intended.