CSS frameworks · Framework 02 of 08
The Tuesday Test
A system earns the right to go live by surviving one ordinary Tuesday. We design from the messy version of your workflow and sign off by walking a real day through it.
Why it matters
Most automation is built from the tidy version: the job that goes to plan. Your business runs on the other version: the 8:14 emergency call, the tech who needs the install moved, the customer who emails twice.
A system that handles the tidy version and breaks on Tuesday costs more than no system, because now someone has to notice it broke.
How we apply it
- Before we design anything, you show us a real Tuesday: the last two handoffs that went wrong, the texts, the tickets.
- The design is written against those, not against a flowchart.
- Before go-live we walk one real day through the built system, disruption by disruption, with you watching.
- Anything that breaks goes back to fix, and we walk the day again. You sign when it survives.
The number
| Measure | Cadence | Baseline |
|---|---|---|
| Failure modes found in the walkthrough, before launch | Per launch | — |
| Failure modes found by a customer or tech, after launch | Monthly, first 90 days | Target zero |
| Walkthroughs to pass | Per launch | — |
Who is accountable
Nothing we build goes live until the walkthrough is documented and you have signed it.
If something the walkthrough should have caught reaches a customer in the first 90 days, the fix is ours at no charge.
Where you meet it
The Sprint, where the first finished piece is tested with you at the day 4 check-in, and every launch report after it.
A common question
The Tuesday Test, asked and answered.
What if we don't have a bad Tuesday to show you?
Then the workflow probably doesn't need fixing yet. The messy version is the evidence that it does.