Shipping inside customer constraints and change windows
Updated
Security review, frozen Fridays, and the Tuesday 2am window: planning delivery around constraints instead of fighting them.
Customer constraints feel like friction until you plan around them; then they become the delivery schedule itself.
The short answer
Map every constraint early, rehearse the full path in staging, ship slices that fit the window, and test rollback before you need it.
The constraint map
| Constraint | Plan |
|---|---|
| Security review | Submit data-flow, PII, auth docs in week one; expect findings |
| Change windows | Slice work to fit; rehearse build-to-rollback end to end |
| Frozen periods | Ship before or after; use the freeze for docs and hardening |
| Data residency | Process where the data lives; move logic, not data |
| Access approvals | Request service accounts day one; they take weeks |
Worked example: the Tuesday window
A fictional retailer (fictional) allows changes Tuesdays 1-4am with the ops lead on call. The FDE rehearses the deploy-verify-rollback path three times in staging, ships a read-only slice first, then the write path with shadow comparison. Two windows, zero incidents, rollback never needed but proven twice.
Checklist: constraint-ready shipping
- Constraint map in the brief, not discovered mid-project.
- Staging mirrors production as closely as allowed.
- Rollback tested, one command, timed.
- The customer team holds the runbook during the window, not you alone.
Related reading
Straight answers
Frequently asked questions
What is a change window?
The agreed slot when production may change: often a weekday night with rollback staff on call. Outside it, nothing ships.
How do you survive security review?
Data-flow map, PII inventory, least-privilege auth and scan-window plan submitted early. Findings are normal; budget fix time.
What if the window is tiny?
Shrink the slice, rehearse the path in staging, and make rollback one command. Small windows reward small ships.