Mopping the floor after moving in.

The Rule of 100, and why testing late costs 100x more.

Walked into my society today. Two men mopping the corridor. Water everywhere. Foam. Real effort.

Made me stop for a second.

The building is already up. People already live here. Cars parked. Kids playing. And now someone is trying to clean the floors while everyone uses them.

Half the work goes back into itself. You mop, someone walks, you mop again. Water spreads. The job feels endless.

Then it hit me.

This is exactly what product design without proper QA looks like.

Ship, then discover

You build the product. Squads code the features. Designers hand over Figma files. Engineers translate them. Everything shows up on staging. Someone clicks “ship.”

Users arrive

Now the bugs start showing up.

A filter that behaves differently on mobile. A form that fails in Safari. A payment flow that breaks with two cards on file. Little things, sometimes big things, almost always things that could have been caught earlier.

The team scrambles. Hotfixes. Emergency deploys. Support tickets. Everyone who was building next quarter’s roadmap is suddenly cleaning up last quarter’s shipping decisions.

Mopping while everyone walks over it.

The Rule of 100

There is a documented rule for this. It comes from IBM’s Systems Sciences Institute and it is called the Rule of 100.

The math is brutal:

Bug caught at design: about $100
Same bug in development: about $1,000
Same bug in QA testing: about $1,500
Same bug in production: $10,000+

Same bug. Same fix. Different phase. 100x the cost.

For a team averaging 30 production bugs per release, that is $300,000 to $750,000 per release cycle in avoidable rework. Multiply across a year and you can see why poor software quality costs U.S. companies an estimated $2.41 trillion annually.

That is the visible cost. The invisible one is worse.

For enterprises, a single hour of critical application downtime averages over $300,000.

You are not paying for the fix. You are paying for the timing.

What good teams do differently

The teams that ship clean don’t test more. They test earlier.

Three things they seem to share.

QA reads user stories before development begins. Ambiguity gets flagged during sprint planning, not on release day. Cheapest possible catch.

Design decisions get quality review before they harden into architecture. A pattern that looks fine on one screen might break on twelve. Catch it at the pattern stage, not after twelve components already exist.

They measure Defect Removal Efficiency, not just bug count. DRE is the percentage of defects caught before release. The US average is 85%. Best-in-class teams hit 99%+. That gap is where most enterprise pain lives.

None of this is new. What has changed is that AI-assisted development lets teams ship faster than ever. If your QA still happens after code, you are just multiplying the cost per bug

Where Oranje fits

We built The Oranje Co around this specific gap.

Quality control should not be a phase at the end. It should be a layer of the system, running from design decisions through to production code. Governed velocity: speed with an audit trail.

We have been running this with clients. Patterns codified before implementation. Component decisions reviewed against the system. PRs landing in the client’s own folder structure with QC built into the loop. Bugs caught at design get fixed for effectively $0. Almost none reach production.

Oranje is in beta now, with our enterprise launch coming soon. 🍊

Mopping the floor after moving in.

Ship, then discover

The Rule of 100

What good teams do differently

Further reading

Reach Us