How we run a 7-day sprint.
No black box. This is the methodology behind the cadence — the principles, the team, the rituals, and the discipline that let us ship working software every seven days. For the day-by-day calendar, see our process.
Read the sprint playbook.
Drop your email and it unlocks instantly — plus the occasional build log from how we ship. No spam, unsubscribe anytime.
Why seven days works.
Locked scope, every week
Scope is agreed and frozen at kickoff. A week you can't re-plan halfway through is a week you can actually finish — and ship.
Working software, not status
Every sprint ends with a reviewable increment on staging, never a deck. Progress is something you can click, not a percentage on a slide.
Senior ownership, end to end
The people who scope the work are the people who build it. No handoff to juniors, no telephone game between strategy and code.
AI-native compression
Senior engineers wield Claude, Cursor, Codex, and GitHub Copilot to compress research, scaffolding, and test generation — which is how a full feature fits in seven days without cutting rigor.
Lean by design
We run the smallest set of rituals that keep the work visible, and no more. The short timeline is a product of that discipline, not a shortcut around it.
Re-steer twice as often
A weekly loop means you course-correct roughly fifty times a year instead of twenty-five. Shorter feedback cycles compound in your favor.
Small team, clear lines.
We keep pods deliberately small. Fewer people means fewer handoffs, less coordination overhead, and more of the week spent on the actual build.
The WAM Corp pod
A senior lead engineer, one or two engineers, and a product manager who owns both the cadence and the design. AI tools let the PM carry design through to production-ready specs, so most sprints ship without a separate design hire slowing the loop.
Your point person
One empowered owner on your side who can make scope decisions within a day, joins the Monday kickoff, and is in the room for the Friday demo. That single clear line of decision-making is what keeps a seven-day loop from stalling.
Five rituals, nothing spare.
We run these five and no more. No daily live standups, no status meetings, no ceremony that doesn't move the build forward — the leanness is what buys the speed.
-
Kickoff
Lock the scope and sign off acceptance criteria. The week's work is defined before a line of code is written.
-
Async daily updates
Written, not stood-up. Everyone stays current without a meeting that interrupts the build.
-
Mid-sprint check-in
One checkpoint to catch drift early, surface blockers, and confirm we're still tracking to Friday.
-
Demo
A live walkthrough of working software on staging. Feedback is captured against something real.
-
Retro
What shipped, what changed, what's next — feeding straight into the following week's plan.
Where the cadence holds or breaks.
Nothing is built without acceptance criteria
If a piece of work isn't defined, it isn't started. Written criteria are the contract for the week.
Minor course corrections are welcome
As the work reveals itself, small adjustments within the agreed scope are normal — we plan for them, not against them.
Substantial new requests go to next sprint
Bigger asks are scoped into the next week's plan, which is never more than a few days away. The current sprint still ships.
"Done" means deployed to staging
Not "code complete." Done is reviewed, tested, and running on a staging environment you can click through.
Tools at every stage, judgment in control.
AI compresses the busywork at each stage of the week. It raises the quality floor and the pace — it never replaces the senior judgment steering the work.
- Claude
- CursorGitHub CopilotCodex
- Claude
- Google Cloud PlatformAWS
No change ships on one person's say-so.
Senior or not, every change is reviewed before it merges. It's how quality holds at speed — the discipline behind shipping a full feature in seven days without cutting corners.
- Retry backoff reads right. Can we cap max attempts?
- Capped at 6 with jitter, plus a regression test.
- 2 commits · 4 files · +118 −12
- Approved — ship it.
The lines we hold.
-
No solo heroics
Every change is reviewed. Nothing ships on one person's say-so, however senior — review is how quality holds at speed.
-
No work without acceptance criteria
Undefined work is how sprints quietly slip. If it isn't written down, it doesn't enter the week.
-
No scope creep dressed as "small asks"
Minor tweaks fit the week; new scope waits for the next one. We protect the cadence that makes us predictable.
-
No ceremony for its own sake
Meetings that don't move the build forward get cut. Lean is the point, not an accident.
-
No "we'll demo next week"
Every sprint produces something to click on Friday. A week without working software is a broken sprint.
The playbook, answered.
How is the playbook different from your process page?
The process page is the day-by-day calendar of a sprint. The playbook is the reasoning behind it — the principles, the team, and the discipline that make a seven-day loop actually deliver working software.
Why is there no dedicated designer on the pod?
Our product managers carry design through to production-ready specs using AI tools, which keeps the pod lean and the loop fast. For design-heavy work we bring a designer in, but most sprints ship without needing a separate hire to slow the cycle.
Can scope really not change mid-sprint?
Minor course corrections within the agreed scope are normal and welcome — that's how real work goes. Substantial new requests go into next week's plan so the current sprint still ships, rather than stalling on a moving target.
Isn't seven days too short for real engineering?
It's short because the pod is lean, the scope is locked, and AI compresses the busywork — not because we cut corners. Everything is still reviewed, tested, and deployed to staging before the week closes.
Want to run your first sprint with us?
Get a structured estimate in two business days.