Handbook
/
Product & Engineering
Shipping Weekly: The Cadence That Wins
The best startups ship constantly. Here's how to establish a weekly shipping cadence that accelerates learning and builds momentum.
Speed is the ultimate startup advantage. You don’t have more money, more people, or more brand recognition than incumbents. But you can move faster. And the teams that ship weekly consistently outperform those that ship monthly or quarterly.
Why Weekly
Faster Learning
Every release is an experiment. You ship something, observe user behavior, and learn. The more often you ship, the more often you learn. Weekly shipping gives you 52 learning cycles per year. Monthly shipping gives you 12. Over three years, that’s 156 vs 36 cycles of learning. The compound effect is enormous.
Momentum
Shipping creates energy. The team feels productive. Users see progress. Investors see execution. Nothing kills morale like long projects that never finish. Weekly shipping ensures that every week ends with an accomplishment.
Smaller Batches, Lower Risk
Large releases are risky. More changes means more potential bugs, more things that could go wrong, more surface area for problems. Weekly shipping forces small batches. Each release changes less, so each release risks less.
User Feedback
Users give better feedback on real changes than on hypothetical ones. Weekly shipping means users constantly experience new things, and you constantly get signal on what’s working.
Competitive Advantage
While your competitor is planning their quarterly release, you’ve shipped 12 times. You’ve tested 12 hypotheses. You’ve incorporated 12 rounds of user feedback. Speed wins.
What “Shipping” Means
Shipping means getting changes in front of real users. Not merging to main. Not deploying to staging. Actually reaching users.
This counts as shipping:
•
A new feature visible to all users
•
An improvement to an existing feature
•
A bug fix for something users hit
•
A UX change users will notice
•
A new piece of content users will see
This doesn’t count:
•
Refactoring that doesn’t change user experience
•
Internal tooling (unless you’re the user)
•
Partial features behind feature flags nobody can access
•
“Shipping” to staging
The discipline of weekly shipping requires that something changes for users every week.
How to Ship Weekly
Monday: Plan the Week
Start each week by deciding what will ship by Friday. Not what you’ll work on—what will ship.
The question isn’t “what should we do?” but “what’s the smallest valuable thing we can finish?”
Rules for planning:
•
If it can’t ship this week, break it down further
•
If it can be shipped without polish, ship it without polish
•
If it blocks on external dependencies, work on something else
Daily: Standup Check
Each standup, ask: “Are we still on track to ship by Friday?” If not, reduce scope immediately. Don’t push the date; shrink the work.
Thursday: Feature Freeze
By Thursday, stop adding to the week’s scope. Focus on finishing, not starting. Thursday is for polishing, testing, and preparing to ship.
Friday: Ship
Ship early Friday. This gives you time to catch issues before the weekend. If something breaks, you can fix it. Never ship late Friday.
After shipping:
•
Announce to the team (small celebration)
•
Communicate to users if relevant
•
Note what was learned
•
Prepare for next week’s planning
What If We Can’t Finish?
If Thursday arrives and the feature isn’t done, you have options:
1.
Ship what’s ready. Often you can ship a partial version that still delivers value.
2.
Skip the week. Ship nothing, learn the lesson, plan better next week.
3.
Work the weekend. Occasionally acceptable, never sustainable.
Never push Friday shipping to Monday. It creates a slippery slope. Friday is the deadline.
Scope Management
Weekly shipping requires aggressive scope management:
The Two-Day Rule
If something takes longer than two days, it’s too big. Break it into pieces. Each piece should be independently shippable.
Exception: Infrastructure work sometimes takes longer. Timebox it and pair it with smaller user-facing work.
Vertical Slices
Build vertically, not horizontally. Instead of building all of the backend, then all of the frontend, then shipping: build a thin slice through the entire stack that delivers one piece of value.
Bad: “Week 1: Database schema. Week 2: API. Week 3: Frontend. Week 4: Ship.”
Good: “Week 1: Ship basic version with one endpoint and simple UI.”
Feature Flags
Feature flags let you ship code without exposing it to users. This enables:
•
Shipping partial features that aren’t ready for everyone
•
Testing with a subset of users
•
Separating deploy from release
But don’t abuse feature flags to avoid shipping. The goal is to ship to users, not to hide behind flags forever.
Cutting Scope
When you won’t hit the deadline, cut scope. Always. The questions:
•
What’s the simplest version that delivers value?
•
What can we do without?
•
What can ship next week instead?
Cutting scope isn’t failure. It’s discipline.
Building the Culture
Weekly shipping requires team buy-in:
Celebrate Shipping
Make Friday shipping a ritual. Announce what shipped. Recognize who contributed. Make it feel good to ship.
Don’t Punish Bugs
Shipping fast means sometimes shipping bugs. If you punish people for bugs, they’ll slow down. Instead, build systems for fast detection and rollback.
Metrics Over Opinions
When shipping creates debates (“Is this ready? Should we include X?”), default to shipping and measuring. Let user data resolve arguments.
Protect Friday
Don’t schedule meetings on Friday afternoons. Protect the shipping window. It’s sacred time.
Lead by Example
If founders and leaders demand weekly shipping but don’t participate, it won’t stick. Leaders should be in the code, in the standups, shipping alongside the team.
When Weekly Doesn’t Work
Some situations challenge weekly shipping:
Enterprise customers with change management requirements. Solution: Ship to cloud/hosted version weekly, batch releases for on-premise.
Regulated industries with compliance requirements. Solution: Ship internally weekly, release externally on a compliant schedule.
Hardware dependencies. If you ship software that requires hardware, you’re constrained by hardware timelines.
Major platform shifts. Sometimes you need to rebuild foundations. Timebox this work and return to weekly shipping after.
Even in these cases, the principle applies: ship as frequently as your constraints allow. If you can’t ship weekly, ship biweekly. If not biweekly, monthly. Never quarterly.
Measuring Shipping Velocity
Track your shipping:
•
Number of releases per month
•
Average size of releases
•
Time from code complete to production
•
Percentage of weeks with a user-facing ship
If velocity is decreasing, investigate. Usually it’s scope creep, unclear priorities, or growing complexity.
Key Takeaways
•
Weekly shipping compounds learning—52 cycles per year beats 12
•
Shipping means changes reaching users, not code reaching staging
•
Plan Monday, freeze Thursday, ship Friday
•
If you can’t finish, cut scope—never push the date
•
Build vertically (thin slices) not horizontally (layers)
•
Celebrate shipping, don’t punish bugs, lead by example
AIMake has access to all of this
Our AI has access to the entire Startup Handbook. Ask it anything about building your startup.
Get started →
← Previous
Security Basics Every Founder Should Know
Next →
Technical Debt: When to Take It, When to Pay It