Where quality breaks in complex software.

By the time software problems are visible, most of the damage is already done.

Early on in a project, everything looks reasonable. Then, close to the finish line, things start to wobble. Features don’t line up the way everyone expected. Fixes introduce new problems. Deadlines start to slip, and pressure builds on top of the team that’s making it all possible. 

Suddenly, the last 10% of the project takes longer than the first 90%. Leaders are asked to account for outcomes that felt sound when the decisions were made, but are suddenly difficult to defend.

When that happens, testing strategies are often questioned. Not enough regression. Not enough automation. Not enough time at the end.

In my experience, however, these aren’t the right questions we should be asking.

Most late-stage problems aren’t caused by bugs that were missed. They’re caused by decisions made months earlier, without enough shared context. Assumptions go unchallenged. Rules quietly contradict each other. Teams execute exactly what was asked for, then discover too late that the pieces don’t actually fit.

Quality doesn’t break at the end of a project. It breaks much earlier, when teams start moving fast without a clear, shared understanding of how a system is supposed to work and why.

That belief shapes how I think about quality at REDspace, and why we focus less on catching problems at the end and more on preventing them before they become expensive.

Why late-stage testing has limited leverage.

In most organizations, testing shows up too late to change outcomes.

Quality assurance is typically treated as a validation step. Features are designed. Code is written. Decisions are locked in. Then, near the end of the process, QA is brought in to confirm that everything works as expected. Test cases are written. Checklists are followed. Issues are logged and prioritized.

On paper, this feels orderly and controlled. The problem is timing.

By the time testing begins in earnest, most of the important decisions have already been made. The structure of the system is set. Assumptions are baked in. Tradeoffs that should have been debated earlier are now difficult, expensive, or politically risky to revisit.

Testing at this stage is like inspecting a building after the walls are up and the drywall is in place. You can spot cracks and patch visible issues, but changing anything structural requires tearing things apart. The earlier those decisions are examined, the more leverage you have. The later you wait, the more expensive every fix becomes.

This is why so many projects feel stable until they suddenly are not. Problems don’t surface gradually. They accumulate quietly, then appear in groups, when timelines are tight and options are limited.

To compensate, teams often lean harder on process. More test cases. More documentation. More rigour at the end. But checklists cannot replace understanding. They can confirm whether something behaves as specified, not whether the specification itself makes sense.

None of this is a criticism of QA teams. These practices exist for good reasons and reflect real constraints around staffing, timelines, and budgets. But when testing is treated as a final inspection instead of an early examination of the structure, it can only react to problems, not prevent them.

How REDspace thinks about quality earlier in delivery.

At REDspace, we approach quality differently because we think about timing differently.

For me, quality work starts long before there is anything to test. It starts when decisions are still cheap, assumptions are still negotiable, and the shape of the system is still forming.

That means being involved early, even when there is no interface to click and no feature that feels finished. Instead of waiting for work to arrive fully formed, I spend that time understanding how the system is supposed to behave. Where data comes from. Which rules matter. Which constraints should never be broken, even as features change.

That early context becomes the foundation for everything that follows.

Rather than treating testing as a final inspection, we treat quality as an ongoing examination of structure and intent. The goal isn’t to catch every possible issue. The goal is to make sure the most important decisions are sound before the team builds too much on top of them.

In practice, this shifts what quality work actually looks like. We focus on:

• Understanding the assumptions the system is built on, not just the features it exposes
• Protecting the rules that everything else depends on
• Surfacing contradictions early, before they turn into rework
• Helping teams navigate tradeoffs while there is still time to make real choices

This changes the role of QA entirely. Instead of reacting to problems after they appear, we help teams avoid dead ends in the first place. When a developer is unsure how something should work, we can point to the underlying rules that already exist. When a feature request conflicts with earlier decisions, that tension shows up early, when it can still be discussed rather than patched over.

Bugs still matter, of course. But they are rarely the most expensive failures. Misunderstandings are.

This way of working requires trust and collaboration. It only works when quality is treated as part of delivery, not something layered on afterward. But when that foundation is in place, teams move faster with fewer surprises because they are building on shared context instead of hidden contradictions.

What early QA changes are about delivery risk.

Approaching quality this way does more than reduce defects. It changes how decisions are made and when they’re made.

• Fewer surprises when the stakes are highest.
  Examining assumptions early surfaces problems while there are still options. This can feel like extra effort upfront, but it consistently avoids the late-stage scrambles that happen when issues only appear near launch, after timelines and commitments are already locked in.

• Decisions are challenged before they become expensive.
  Quality becomes a way to pressure-test ideas, not just validate finished work. That sometimes means slowing down a conversation early, but it prevents teams from spending months building something that quietly contradicts earlier decisions.

• Tradeoffs are visible while choices still exist.
  When quality is embedded early, teams can explain the real downstream impact of a decision before it is made. Clients gain clarity while alternatives are still on the table, rather than learning about complexity and cost after the work is underway.

• Less rework driven by misunderstanding.
  Many costly fixes are not caused by technical failure, but by different interpretations of intent. Aligning early around structure and assumptions reduces the kind of rework that feels avoidable in hindsight but was invisible at the time.

• Stronger trust across delivery.
  When quality is part of the conversation from the beginning, it stops feeling like a gate at the end. This approach only works with collaboration and trust, but when it does, teams move faster overall because they are not constantly correcting course under pressure.

Taken together, this shifts delivery from executing requests to shaping outcomes. Quality stops being something teams scramble to protect at the end of a project and becomes a way to protect time, trust, and long-term value throughout it.

The leverage most teams miss.

Quality is often treated as something you measure at the end of a project. In practice, it shows up much earlier in how teams think, ask questions, and make decisions while the structure is still taking shape.

When assumptions are examined before solutions are locked in, contradictions surface while there is still leverage to address them. Fewer surprises make it to the finish line, not because teams worked harder at the end, but because they thought more clearly at the beginning.

In other words, quality shows up long before the final test run. It shows up in the decisions teams make when change is still possible.

About the author

Jonathan Terry leads quality engineering at REDspace and has spent more than a decade helping teams build and ship complex digital products across large organizations.