The Hidden Costs of Untested Systems
Why 'just get it live' is more expensive than you think.
The new system is "ready." The APIs connect. The UI loads. The workflows are mapped. Sort of. There’s just one last thing to do: test it.
But there’s a warehouse team trying to process returns. An ecommerce team juggling four promotions. Ops are already underwater. So testing gets pencilled in as a side-task. Something to do in between chasing BAU issues and responding to the latest pricing fire.
No surprise: it rarely gets done properly.
We see this all the time. A new PIM, an Airtable-based asset tracker, a custom BI dashboard, they get released into production because they technically work. But without structured, end-to-end testing across all the real-world workflows they’re meant to support, those systems don’t deliver what they promised. Instead, they create confusion, workarounds, rework, and, eventually, a quiet return to doing it all in spreadsheets.
And yet, because there's no red flashing alert or obvious cost centre to pin it to, untested systems keep slipping through.
This piece is about what that costs.
Testing isn’t a nice-to-have. It’s operational insurance.
When teams hear "testing," they often picture QA engineers running scripts or developers checking for bugs. But testing operational systems, like a PIM or a returns workflow, isn’t about bug hunts. It’s about trust.
Can your warehouse team run their process without missing a beat?
Can your product team upload data without double-checking it in six places?
Can your ecommerce team go into peak season confident the thing won’t fall over?
That’s what testing needs to answer.
And to answer it properly, you need:
Real data (not dummy SKUs)
Real teams (not just project leads)
Real workflows (not just system demos)
Testing isn't about proving the tech works. It's about proving the humans can do their job without disruption.
Why testing gets cut, and what that actually costs
Testing doesn’t get skipped out of laziness. It gets skipped because no one has time (or capacity).
Most ecommerce teams are already at capacity. Testing doesn’t fit neatly into anyone’s job description. And by the time a new system is "ready," the pressure to ship is already high.
So teams default to the fallback plan: "we’ll test as we go."
But here’s what happens when you do that:
A system gets launched with critical assumptions untested. Product data doesn’t flow as expected. Categories go missing. Reports don’t reconcile. Teams start logging bugs, but those bugs aren’t prioritised. People go back to spreadsheets. New starters get trained on workarounds instead of workflows.
You end up with two systems: the one you paid for, and the one your team actually uses.
You also end up with hidden costs that never get traced back to the skipped testing window: hours lost to manual fixes, overtime during peak, missed sales, bad data, staff churn.
None of that shows up in a sprint review. But it's real. And expensive.
What 'good enough' testing actually looks like
No one has six weeks to stop everything and simulate the entire business. That’s fine. But there’s a difference between perfect and adequate.
We've seen brands make huge gains by setting aside just two or three weeks for structured testing, with clear test cases, defined roles, and sign-off criteria. Not just "try to break it" but "prove this workflow works end to end."
You don’t need perfection. You do need:
Time: Dedicated, protected time where teams aren’t being asked to test while juggling promotions or order volumes.
Focus: Everyone knows what they’re testing, why it matters, and what a pass/fail looks like.
Fallbacks: Clear plans for what happens if the system fails. Not just "raise a ticket" but "how do we keep trading if this goes down?"
Testing also means capturing learnings. Every test is an opportunity to document, improve, and iterate. You might discover gaps in process, missed dependencies, or even entirely new use cases the system could support. But only if you're looking.
Ship fast, but don’t ship blind
We get it. Launching systems is hard. There’s never enough time. The team’s always already overloaded. And yes, some things will always need to go live under pressure.
But when a system gets shipped without proper testing, what you’re really doing is outsourcing the QA to your own team, in live production.
That’s not shipping fast. That’s punting the cost downstream.
Testing isn't a delay. It's an investment in making sure what you've built actually works. And not just in theory. In the real world, with your team, under pressure.
If you want systems that get used, trusted, and scaled, test them properly. Before your team gives up and goes back to spreadsheets.