When a startup begins, many technology decisions are made with one clear priority: make it work. We build an MVP with the resources we have. We use a single server because it's enough. We choose a simple architecture because we need to move fast. We postpone automation and handle some processes manually. These aren't necessarily bad decisions; in many cases, they're exactly the decisions a company needs to make while it's still trying to validate its business.

The problem comes later.

The product works, customers arrive, operations grow, and what we originally built to validate a hypothesis starts supporting a real business. That's when a situation I've seen many times appears: we know something needs to change, but we can never find the right time to change it.

There's always a more urgent feature, a customer who needs something, a commercial opportunity, or a quarterly target. The rebuild gets pushed back once again. Until the cost of waiting starts to exceed the cost of change.

The MVP Did Its Job

There's something unfair about the way we often talk about technical debt. We look at a solution built several years ago and say: "This was poorly designed." But we're judging a past decision using information that didn't exist at the time. Maybe that architecture allowed the company to launch six months earlier. Maybe it avoided hiring five people before the business had any revenue. Maybe it helped validate a market no one even knew existed.

That's why one of the questions I'm most interested in isn't "Why did we build it this way?", but:

Does it still make sense to do it this way today?

A decision may have been right in 2023 and become a problem in 2026. The quality of the original decision didn't necessarily change.

The business did.

The Real Problem Is Finding the Right Time to Change

When a company grows quickly, there's a constant tension between two types of work. On one side, there's everything that helps the business move forward: new features, new products, customers, and integrations. On the other, there's everything that allows the company to keep moving forward in the future: architecture, security, automation, infrastructure, data, and processes.

The first usually has a visible return. The second often doesn't. If we assign five developers for three months to rebuild part of the platform, someone will eventually ask what new functionality we'll have at the end of those three months.

And the answer may be: none.

That's why these decisions are uncomfortable. We're taking capacity away from something that could generate revenue today and investing it in preventing a problem that may not have happened yet. The mistake is evaluating only one side of that equation.

"We Have Technical Debt" Is Not a Business Argument

If a CTO needs resources to solve a structural problem, saying that the architecture is outdated, that there's technical debt, or that the company should adopt a more modern pattern isn't enough. The problem needs to be translated into business terms. We need to understand the operational risk we're taking, how much manual work it creates, what it means for security, how many people are required to sustain operations, which growth opportunities we're limiting, and how much an incident could cost.

That shift in language is fundamental. The NIST Cybersecurity Framework 2.0, for example, introduced Govern as one of its six core functions, specifically to connect cybersecurity management with organizational context, strategy, and risk. In March 2026, NIST also published the final version of SP 1308, a guide that explicitly connects cybersecurity, enterprise risk management, and workforce decisions.

The conversation then stops being:

"Technology needs three months to refactor this."

And becomes:

"What level of risk and cost are we willing to accept if we don't make this change?"

At that point, the conversation no longer belongs only to Technology.

It's a business decision.

The Cost of Not Changing Can Also Be Calculated

Not every technology problem can be translated perfectly into dollars. But many of them allow us, at the very least, to build scenarios. Suppose an operation processes 100,000 cases per month. Three percent become exceptions requiring manual intervention, and we need 10 people to handle them.

That's 3,000 exceptions per month.

Now suppose the business grows tenfold and reaches one million cases per month. If nothing changes and the exception rate remains at 3%, we go from 3,000 to 30,000 manual cases per month. If productivity remains constant, we could go from needing 10 people to needing approximately 100.

Let's use a deliberately hypothetical number so we can do the math: a total annual cost to the company of USD 30,000 per person. The organization required to handle those exceptions would then grow from approximately USD 300,000 to USD 3 million per year. Now imagine that redesigning and automating part of the process could reduce the exception rate from 3% to 0.5%, and doing so requires four developers working for five months.

Now we have an interesting discussion.

We're no longer asking:

"Is it worth spending five months improving something that already works?"

We're comparing the cost of that investment with the operational cost we may accumulate if we don't make it. The numbers in this example are hypothetical.

The calculation shouldn't be.

Put Both Sides on the Table

I don't intend this to be an exact financial formula, but I find it useful to frame the decision this way.

Cost of Change

Development + migration + implementation risk + opportunity cost

versus:

Expected Cost of Not Changing

Incremental operating costs + headcount growth + incident risk + opportunities we can't capture + the future cost of making the change later

Not all of these components can be measured with the same level of precision. The cost of five developers working for four months is relatively straightforward to calculate. The impact of an architecture that could prevent the company from launching a new product two years from now is much more uncertain.

But uncertainty doesn't mean zero.

Our job is to make those assumptions explicit so the business can decide what level of risk it's willing to accept.

Four Signals I Look For

There's no universal formula that tells us exactly when something needs to be rebuilt. But there are observable signals that can tell us when it's time to run the numbers again.

1. Marginal Cost

What happens to the cost per operation, customer, or transaction as we grow?

If the business grows tenfold and our costs also grow tenfold — or more — we need to understand why.

2. Capacity Being Absorbed

What percentage of the team's capacity are we dedicating to keeping existing systems running?

Maintenance is normal. But if, quarter after quarter, we need to dedicate an increasing share of the team simply to sustaining operations, it may indicate a structural problem.

3. Dependency on Specific People

Can we operate and modify the system without depending on specific people who know its entire history?

When critical knowledge is concentrated in two or three people, the problem is no longer purely technological. It's also an operational risk.

4. Blast Radius

What happens today if something fails?

An incident affecting a platform with 1,000 customers doesn't necessarily have the same consequences when that same platform has 100,000. The software may be exactly the same.

The risk isn't.

None of these signals, on its own, means we need to rebuild.

They tell us it's time to run the numbers again.

The Same System Can Represent a Different Level of Risk

A solution that was acceptable for an MVP may no longer be acceptable once the company reaches a different scale, even if nothing has technically changed. A new vulnerability didn't necessarily appear. What we have to lose changed. A system with one hundred users and one with one million users can run on exactly the same technology while representing completely different levels of risk. The same applies to availability, fraud, privacy, backups, access controls, and monitoring.

Technology maturity should evolve alongside business maturity. NIST SP 1308 specifically argues that decisions about people, processes, and technology should reflect an organization's risk appetite and tolerance, objectives, budget, and available capabilities. We don't need the same level of controls to validate an MVP as we do to operate an established company.

But we need to recognize when we're no longer that MVP.

Technology Cost Is No Longer Just About Cloud

The way the industry thinks about these problems is also changing. In February 2026, the FinOps Foundation changed one word in its mission: it moved from talking about people managing the "value of cloud" to those managing the "value of technology."

The numbers help explain why.

According to State of FinOps 2026, 98% of surveyed teams now manage AI-related spending, compared with 31% two years earlier. 90% manage SaaS or plan to do so, alongside licensing, private cloud, data centers, and other technology categories. It isn't only how much organizations spend that has changed.

What they need to manage has changed.

The FinOps Framework 2026 also introduced Executive Strategy Alignment as a new capability, explicitly connecting technology optimization decisions with strategy, business outcomes, and executive trade-offs. To me, that evolution reflects a shift we also need to make in technology leadership.

The conversation shouldn't only be about how much our infrastructure costs. It should be about the value we get from our total technology investment and how that cost evolves as the business grows.

Time Is Another Variable in the Equation

There's something else we shouldn't overlook. Maybe doing nothing is cheaper today. That doesn't mean we need to make the change immediately. Suppose we know a platform needs to be rebuilt, but it can continue operating reasonably well for another two years. At the same time, the company has a critical commercial opportunity over the next six months.

It probably makes sense to keep moving. The decision changes completely if we estimate that, within three months, expected growth will double the team required to sustain operations.

That's why asking:

Do we need to change it?

isn't enough.

There's a better question:

How much time do we have before not changing starts to cost us more?

It could be one month, three years, or never. All three answers are perfectly valid.

Not Everything Old Needs to Be Replaced

We also need to avoid turning this logic into an excuse to rebuild everything continuously. The existence of a more modern solution doesn't mean we should adopt it. An architecture having technical debt doesn't automatically mean it needs to be replaced. If something works, has a reasonable cost, doesn't represent significant risk, and doesn't limit what the business wants to accomplish over the next few years, perhaps the best technology decision is:

don't touch it.

Technology shouldn't change simply because something more interesting has appeared. It should change when there's a good enough reason to change it. And questioning a decision only to conclude that it's still the right one isn't wasted time.

That's part of the analysis too.

The Other Half of the Calculation

When we evaluate a technology decision, we usually start with one question:

How much will it cost to do it?

It's logical, concrete, and relatively easy to answer. But it's only half of the calculation.

The other question is:

How much could it cost us not to do it?

Sometimes the answer will be money. Other times it will be risk, speed, people, security, or growth capacity. And sometimes, after putting everything on the table, the conclusion will be that waiting is still the right decision.

That's a good decision too.

Because the job of technology leadership isn't to modernize everything. It's to understand what we need to change, why we need to change it, and how much time we have before not changing starts to cost more than changing.

Sources and Further Reading