Of course, not all software is the same — some types are simple and focused enough that they won’t have much of a life after launch.

But software that’s critical to the business and/or is meant to be sold as a product to other customers requires a mindset and an approach that optimize for maintenance, operations, and the ability to build new functionality easily.

From a user’s point of view, it’s only once they have it in their hands that they start thinking about what could’ve been done differently — or new features they now want that weren’t part of the first version. If you haven’t built for that phase, costs can spiral out of control fast.

What you’re really paying for?

Total Cost of Ownership (TCO) in software development refers to the complete lifecycle cost of building, running, and maintaining a software solution. This includes not just the initial development effort, but also the often-overlooked expenses such as:

• Infrastructure and hosting
• Licensing and third-party services
• Developer salaries and onboarding
• Bug fixes and feature updates
• Security, compliance, and technical debt
• Downtime and productivity losses
• End-of-life and migration costs

TCO helps stakeholders understand that the cheapest to build is rarely the cheapest to own. It’s a holistic metric that guides more sustainable architectural and business decisions.

Quality shortcuts come at a price

It sounds obvious: poor quality leads to higher costs. If you buy a house and everything looks good on the surface, but then discover during renovations that the foundation is weak, you often have to fix the basics before you can do what you originally planned. Same thing with software. If the code you’re supposed to maintain was written irresponsibly, it can collapse under its own weight — making changes costly, or in the worst case, impossible.

The cost of «just shipping it»

Many projects and products start at high speed, often following practices like MVP (Minimum Viable Product) or begin as Proof of Concepts. What’s often forgotten is that both MVPs and PoCs are meant to prove the idea has merit — and to do that as quickly and cheaply as possible. But too often this is overlooked, and the PoC gets pushed into production and becomes the foundation for what comes next. That’s understandable — once something “works,” it’s hard to pull the plug.

If you’ve built something users or customers want, you’ve proven the value. They’ll want more, or they’ll start to find bugs. From a business standpoint, it feels wrong to pause and go back to “do it properly.” Users seem happy enough, and it looks like it works.

The issue is: MVPs and PoCs often rely on shortcuts. They’re fine for proving a point, but not for scaling, extending, or maintaining over time.

I’m fully on board with the MVP mindset, but that doesn’t mean you can’t build it in a way that gives you room to clean up those shortcuts later. Creating necessary abstractions and contracts in the code that let you evolve the system isn’t in conflict with the MVP idea — quite the opposite. For PoCs, which I see as technical in nature, they should never go to full-scale production, period.

Data still says we’re struggling

Codescene recently published a report on software quality and the business impact of poor code health. And for decades, the Standish Group has released the Chaos Report, detailing the state of software development globally.

From this year’s report:

• Only 31% of projects are considered successful
• 50% exceed budget or deadlines
• 19% are cancelled altogether

There’s analysis of various factors like process and how much they influence outcomes. And sure, things have improved since 1994 — back then, only 16% of projects were successful. But given that it’s been over 30 years, you’d expect more progress than this.

Technology choices are long-term bets

Steve Jobs once said «You’ve got to start with the customer experience and work back toward the technology – not the other way around.».

Couldn’t agree more. For the user, it’s not about the tech. It’s about what they can achieve — the value delivered, the problem solved. But that doesn’t mean technology choices don’t matter.

There’s risk tied to technology decisions. Things move fast in software. You want tech that looks ahead and will be around for a while. Something becoming “legacy” can simply be a matter of the vendor pulling the plug. You also risk trouble recruiting developers if you pick something too obscure or outdated. Like it or not, developers follow trends — they want to work with tech that keeps them market-relevant.

When starting from scratch, you can pick from the top shelf. So think carefully about where you’re heading and choose accordingly. You don’t need to make every decision up front, but you should at least plan for the different stages and know when and how to adjust as you go. Some technologies are expensive to run, and if you’re launching something with zero users that you hope will scale, you shouldn’t start with tech meant for massive volume.

Staying current – or pay for it later

Not keeping third-party dependencies up to date can get expensive quickly — whether we’re talking about packages (NuGet, NPM, etc.) or platforms (.NET versions, Node, databases…).

If you fall too far behind, upgrades become major projects. The tech world moves fast, and along the way come bug fixes and security patches. If you’re stuck on an old version and suddenly face a security breach — and upgrading isn’t trivial — the business side will feel it, likely in the form of lost trust.

Constraints aren’t limitations – but enablers

Software development sits at the intersection of problem-solving and craft. Great solutions demand creativity. It’s not about picking from a list of pre-made fixes.

That creativity needs balance. Too much of it, and you end up with clever-but-cryptic solutions that are technically impressive but hard to maintain. You’ve technically solved the business problem — but nobody else understands how.

The best thing you can do for a codebase is write it in a deliberate, consistent way. If every developer does their own thing, you’ll have as many solutions as you have developers — which helps no one. People switch jobs. People get sick. People leave.

You need constraints — clear, helpful ones that guide the codebase toward long-term health. It’s not about micromanaging creativity. It’s about giving structure and predictability. That makes it easier to onboard people, share understanding, and move faster with confidence.

Not Invented Here™

Your organization does not have to own everything and hence build everything. This is a very common pitfall. The idea that your organization or your codebase is so esoteric that you can’t use something someone else has built.

The cost of owning code is not one to take lightly. If there are opportunities to build using something else, you should cease that. Sometimes that means you need to do some compromises and might not be the «perfect solution».

You get what you measure

There are endless metrics in software development — but very few that actually lead to better outcomes.

Take code coverage, for instance. Measuring how much code is touched by automated tests doesn’t say anything about quality. You can have 100% coverage and still barely be testing anything meaningful.

The point of automated tests is to prevent regression when you change or add code. So, a far more useful metric might be the number of bugs reported by users — and how quickly those are fixed and shipped to production. That starts to say something real about the health of your software.

Another useful signal: how often you release, and how long a release takes. That shows team agility and software/process flexibility. Combine this with bug metrics and coverage, and you have a good baseline.

But to even have these metrics, you need:

• Code that’s change-friendly and maintainable
• A process that allows adaptation at the right pace
• A DevOps mindset backed by tooling and automation

It all boils down to one thing: the feedback loop. How fast can you move with confidence? That’s what you want to measure.

A crucial piece of this is observability — being able to detect issues in production. Your software needs instrumentation that surfaces how it behaves in the real world. Without that data, developers are flying blind.

Collaborative

Understanding what to build is obviously key. More often than not I’ve seen that this is the root cause of problems. During the agile years of our industry I’ve seen far too many companies violate the first rule «Individuals and interactions over processes and tools».

Most of us build software that’s meant to make it easier for humans to do their work. As technical people, we don’t necessarily bring deep knowledge of the domain we’re building for.

Working closely with domain experts is crucial. And to get it right, this needs to be a continuous process — a rhythm of cross-functional collaboration.

The best tools I’ve seen for making that happen are Event Storming and Event Modeling. They help lower the threshold by providing well-defined building blocks. Both focus on capturing meaningful state transitions in a system and giving them proper names. These transitions usually come from established workflows and domain processes.

My personal favorite is Event Modeling. It’s a bit simpler for everyone to grasp, and it comes with concrete patterns that make the process more focused.

Final thoughts

Building and owning software isn’t simple. You need to be intentional about it.

The challenges are absolutely manageable — but only if you keep your eyes open to the full picture, and invest in what gives you leverage over time.

Structure. Process. Quality. Flexibility. Combine those with clear, open communication and mutual respect, and you’ve got the foundation for a healthy, happy team — which in itself is a huge asset.