A shipping week is the founder's hardest unit of time. Three to five days of compressed delivery, half-debugged features, customer questions, and the quiet terror of public commitments coming due. The week itself is hard. What is harder is the two weeks after, which most founders pay for in lost recovery, dropped routines, and decisions that should not be made tired.

This page is what to do during the shipping week so that the cost is contained to the week itself.

What you might notice

The first thing you notice in a shipping week is that the brain runs the same loop over and over. The launch checklist. The unresolved bug. The thing you forgot to test. The customer who emailed yesterday. The loop is not productive. It is the noise of a system under load that is trying to monitor everything simultaneously.

The second thing you notice is that the body knows before the calendar does. Sleep gets thinner two days before the week officially starts. Appetite changes. The fuse is shorter with the people who live with you. None of this is dramatic. It is the predictable physiology of a system preparing for compression.

The third thing you notice, if you have done a shipping week before, is that the recovery afterward is non-trivial. The recovery is not "I am tired for a day". The recovery is "I cannot make a good decision for ten days". This is the actual cost, and it is the cost worth managing.

The first move: name the actual scope

Most founders enter a shipping week with an inflated scope and a deflated honest assessment. The two together produce a week that is too ambitious by 30 percent and a founder who is too tired by 50 percent.

Cognitive-behavioral technique applied to scoping starts with one question. What is the minimum version that is genuinely shippable?

Not the version you imagined three months ago. The version that, if it ships Friday, is genuinely good for customers and does not require a follow-up emergency release. Write that version down. Three sentences. The features that are in scope. The features that are out of scope. The conditions under which it is considered done.

This is harder than it sounds because the founder's brain resists scoping down. The resistance is identifiable. It says things like "but the customers will want X" or "but the competitors have Y". These are predictions, not data. The actual customer behavior post-launch is more forgiving than the prediction.

For more on the cognitive-distortion patterns this addresses see how to rebuild focus after a distracted month.

The second move: protect the morning

The shipping-week morning is more valuable than usual. The hour from 7 to 9 a.m. is the only hour that day with a high probability of clean deep work. The hour from 7 to 9 p.m. will be a different hour by Wednesday.

The protection move is simple. Email opens at 10 a.m., not 7. Slack opens at 10 a.m., not 7. The first three hours of the day are for the work that actually ships the product. Everything else fits into the back half.

This is harder during a shipping week because the inbox is louder. The customer who needs an answer. The investor who saw the tweet. The friend who is checking in. The temptation is to clear the inbox to be ready for deep work. The reality is that the inbox is never clear during a shipping week and the attempt to clear it costs the morning.

For the morning structure this depends on see stoic morning routine for solo founders.

The third move: predetermine the response to setbacks

During the shipping week, things will break. The deployment will fail at 11 p.m. A dependency will update unexpectedly. A test that passed yesterday will not pass today. The customer will report a critical bug at 4 p.m. on Thursday.

The predetermination is to decide on Monday what your response will be to each of these setbacks. Not whether they will happen. They will. The decision is what you do.

The deployment fails at 11 p.m.: you do not debug at 11 p.m. You write a one-line note, you go to bed, you debug at 7 a.m. Friday with a fresh brain.

The dependency updates: you pin the version, you do not chase the new behavior in a shipping week.

The test fails: you check whether it is a real regression or a flaky test. If flaky, you ignore it and ship. If real, you assess in five minutes whether it blocks shipping or can be hotfixed in week one.

The customer reports a bug at 4 p.m. Thursday: you acknowledge the report in twenty minutes, you triage it in an hour, you decide whether it blocks the Friday ship or moves to next Monday.

These are not theoretical decisions. They are decisions made in advance so that the in-the-moment decision is a recognition, not a deliberation. The founder who has predetermined the responses to the most likely setbacks operates from a position the founder who has not cannot reach.

For the broader weekly-planning frame this sits inside see how to make a week plan that survives contact with reality.

The fourth move: book the recovery before the week ends

The recovery week starts Friday afternoon, not the following Monday. The decision to book it is made on Monday morning of the shipping week, not Friday afternoon when the brain is too tired to plan.

The booking looks like this. Friday evening: no work. Saturday: low-stakes activity that is not on the laptop. Sunday: the normal Sunday planning ritual for the next week, but with an explicit recognition that the next week is lighter than usual.

The lighter week is the actual recovery. Not the weekend. The weekend is rest. The lighter week is repair. A founder who shipped on Friday and tries to do a full week the following Monday will burn out by Wednesday and lose week two as well.

The lighter week looks like this: no new feature work, only customer feedback and small fixes, two deep blocks instead of four, an early end Friday. This is not slacking. This is the recovery that protects the next shipping cycle.

For the founder version of recovery from burnout signals see what stoic philosophy says about burnout for builders.

What this is not

This is not a sprint methodology. There is no estimation game here, no story points, no retrospective format. The shipping week is a structural recognition that founders ship in waves, and that the waves have predictable costs.

This is also not a recommendation to do shipping weeks frequently. Once a quarter for a major release, once a month for a minor one. More frequent than that and the cumulative cost of the recovery weeks exceeds the value of the shipping cadence.

This is also not a guarantee that the shipping week will go well. Some of them do not. The point of the framework is that the bad shipping week is contained, recovered from, and learned from, rather than starting a downward spiral.

The Stoic register

The Stoics wrote about compressed periods of effort. Seneca described the difference between exertion and exhaustion as the willingness to acknowledge when the work was done. The shipping week is exertion. The acknowledgment that it is done on Friday at 5 p.m. is the difference between a week that ends and a week that bleeds into the next month.

The Stoic founder does not work harder during the shipping week than the non-Stoic founder. They contain the work. They define when it is over. They take the recovery as seriously as the shipping. The total output across a quarter is higher because the recovery weeks are real.

What changes

Two or three shipping weeks with this framework and the founder has data they did not have before. The framework is calibratable. The scoping move gets sharper. The setback responses get faster. The recovery week gets shorter without losing its function.

The founder who has run six shipping weeks with this structure has something the founder who has run six shipping weeks without it does not: a clear, low-drama record of what shipped, what broke, and what they would do differently. The pattern across quarters is what an operating layer surfaces. The shipping week is in the calendar. The pattern is in the record.

NothingGiven.

Frequently asked questions

How do I know if I am actually in a shipping week

A shipping week has three properties: a public commitment with a fixed date, scope that cannot be expanded mid-week, and a deliverable that will be visible to customers within seven days of the end. Without all three, it is just a busy week.

What if the week extends to ten days

Then it was a ten-day week, and the recovery extends proportionally. Lying to yourself about the length does not help. Naming the actual length lets you plan the actual recovery.

What about co-founders

The framework still works. The morning protection becomes shared. The setback responses become explicit agreements. The recovery week is taken together so that one founder is not back at full speed while the other is recovering.

What if I cannot afford to take a lighter week after

Then you cannot afford to do a shipping week. The lighter week is the cost of the shipping cycle. Skipping it does not save you the cost. It defers the cost into a more expensive form, usually a quiet month two quarters later.

How do I deal with the family during the week

You tell them in advance. The week is named, the duration is named, the post-week recovery is named. Most partners and family can absorb a hard week if they know it is bounded. Most cannot absorb the same hardness without warning, every month, forever.

What if I ship a major bug the day after

The recovery week absorbs it. The advantage of the lighter week is that there is bandwidth to handle the post-launch issue without re-triggering shipping-week intensity. This is one of the main reasons to have the lighter week.