Shipping every week as a team of one

A weekly release gives a solo builder what a team gets from a sprint review and a release manager: a date that does not move, and a pressure to keep work small enough to finish. It works only if three habits exist behind it. Work is cut into slices, the main branch can be deployed at any time, and the week has a stop rule that says what flexes when time runs short.

Most published guidance on delivery is written for teams. This page uses the parts that apply to one person and says where a team's practices need a substitute.

Why a week

The Scrum Guide defines Sprints as fixed-length events of one month or less, and says a long horizon can invalidate the goal, raise complexity and raise risk, while shorter Sprints produce more learning cycles and limit the cost of being wrong. Nothing in the guide singles out a week. It is a practical choice for one person because it is long enough to finish a real change and short enough that you can remember how the last one went.

DORA's research on small batches gives the underlying reason. Working in small batches shortens the time it takes to get feedback on a change, which makes problems easier to triage and fix. Its guide also notes that it prevents falling into the sunk-cost fallacy, meaning continuing with a design because of what has already been spent on it.

What a team provided that you now have to replace

A team has reviewers, a second person who notices a missed step, and someone to cover for sickness. A team of one has none of them, so each function needs a substitute.

The last row is the one solo plans usually omit. The remedy is to measure how much of your recent weeks went on unplanned work and plan the rest. That fraction is yours; this page does not offer a number, because none from a published source describes your situation.

The week

One layout that works for a Monday to Friday week follows. The days are an example, so shift them to suit your own.

A one-page spec for the outcome makes Monday faster. A one-page spec for a first release describes a format that suits a week's goal as well as a first launch.

Slice small enough to finish

DORA recommends the INVEST principle for splitting work: Independent, Negotiable, Valuable, Estimable, Small and Testable. For Small it says batches should be completable in hours to a couple of days. For a solo builder, a good slice is one that you can describe in a sentence, finish in a day or two, and demonstrate to yourself.

When a feature is larger, DORA describes dark launching. Start at the service or API layer, not the interface, so additions can go to production without being visible to users, and check in the finished parts while the whole feature is incomplete. For a site this can be as simple as a flag in a configuration file that keeps a section out of the rendered page until it is ready. Anything merged and hidden is still tested by the automated checks, which is the point.

Slice by outcome. A slice of "database tables" teaches you nothing until the screens exist. A slice of "a visitor can save one item" crosses the layers and can be checked by a person.

A fictional example: the week's goal is "visitors can keep a short list of saved items". Four slices fit it. First, one hidden page that stores and shows a single item. Second, add and remove. Third, the list survives a reload. Fourth, the layout works at a phone width and with the keyboard. Each can be used by hand when it lands, each is deployed behind the flag, and the flag is switched on only when the fourth passes. If Wednesday goes badly, cut the decorative polish in the fourth slice. Keep the reload behaviour, because a list that forgets is broken, and keep the keyboard and phone-width checks, because they belong to the quality line that does not move.

Keep main deployable

DORA's trunk-based development page contrasts long-lived feature branches, which need bigger merges and often a code freeze, with trunk-based work, where branches last no more than a few hours and developers merge at least once a day. A team of one has no merge conflicts between people, but the same logic applies across time: the longer a branch lives, the more the code underneath it drifts and the less you remember about why it exists.

The continuous delivery page supplies five questions to ask of yourself. Is the software deployable throughout its lifecycle? Do you prioritise keeping it deployable over new features? Is fast feedback on deployability available? When it breaks, is fixing it your top priority? Can you deploy on demand? If the answer to the first or fourth is no on a Wednesday, the Friday release is already in doubt. Fix the red build before starting the next slice.

The stop rule: flex scope, not the date or the quality

The Scrum Guide's rules for a Sprint give the template. During it, nothing endangers the Sprint Goal, quality does not decrease, and scope may be clarified and renegotiated as more is learned. For a team of one the renegotiation is a decision you make alone, so make it in writing on Wednesday, not at 6 pm on Friday. A simple form is this: name the item you will cut, the reason, and whether it goes to next week or the refusal list.

The opposite choices are the ones to refuse: moving the date every time the work runs over, and passing the checklist by skipping its slowest item. Either teaches you that the cadence is optional, and after that it is not a cadence.

The checks that stand in for a reviewer

With no second person, the checklist has to be written down before the pressure arrives, and as much of it as possible should run by itself. A workable minimum for a website or small product:

1. The build passes from a clean checkout, not only on your machine.
2. Automated checks cover the things you have broken before: links, required metadata, the layout at a phone width.
3. The new slice has been used by hand once, from the entry point a visitor would use.
4. The release notes describe what changed in words a user would recognise.
5. The way back is known: the previous version can be restored in one step, and you have confirmed where that step is (see preview deployments and rollbacks).

Add to the list each time something slips through; shorten it only by turning a manual item into an automatic one. A list that grows without ever being automated becomes the reason a release is dreaded.

The Friday review

Spend a short, fixed slot comparing the week with its Monday goal, and ask three things. What shipped, and what did not? Which slice ran over, and was it too big or poorly understood? What is the first thing to cut from next week? Write the answers in a line or two. The record matters more than the discussion, since there is no one else to remember it, and a month of these lines shows patterns that one week hides: a type of work that always overruns, or a day that is always lost.

Measuring without gaming it

DORA's guide lists five delivery metrics: change lead time (committed to deployed), deployment frequency, failed deployment recovery time, change fail rate and deployment rework rate. It cautions against setting the metrics as goals, because of Goodhart's law, and against treating one metric as the whole picture. Used as a gauge for a slow week, they are cheap to compute from a deploy log.

The script below groups a log into weeks and reports deployments, the median hours from commit to deploy, and how many deploys needed a fix afterwards. The data are fictional and the times are UTC; fixedAfter is a stand-in for a failed deployment that needed intervention.

// cadence.mjs: weekly delivery report from a deploy log (fictional data; times in UTC).
const log = [
  { at: '2026-09-22T15:00:00Z', commits: ['2026-09-21T14:10:00Z', '2026-09-21T19:40:00Z'], fixedAfter: false },
  { at: '2026-09-24T16:30:00Z', commits: ['2026-09-23T13:00:00Z', '2026-09-24T09:15:00Z', '2026-09-24T12:45:00Z'], fixedAfter: false },
  { at: '2026-09-25T20:00:00Z', commits: ['2026-09-25T17:30:00Z'], fixedAfter: true },
  { at: '2026-10-01T15:20:00Z', commits: ['2026-09-29T15:00:00Z', '2026-09-30T18:00:00Z'], fixedAfter: false },
  { at: '2026-10-02T14:00:00Z', commits: ['2026-10-02T10:30:00Z'], fixedAfter: false },
  { at: '2026-10-08T16:00:00Z', commits: ['2026-10-05T14:00:00Z', '2026-10-07T13:30:00Z'], fixedAfter: false },
];

// Monday of the week that holds a date (UTC), as YYYY-MM-DD.
function weekOf(iso) {
  const d = new Date(iso);
  const back = (d.getUTCDay() + 6) % 7; // Monday = 0
  d.setUTCDate(d.getUTCDate() - back);
  return d.toISOString().slice(0, 10);
}
const median = (xs) => {
  const s = [...xs].sort((a, b) => a - b);
  const m = s.length >> 1;
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
};

const weeks = new Map();
for (const dep of log) {
  const w = weekOf(dep.at);
  const row = weeks.get(w) || { deploys: 0, leads: [], failed: 0 };
  row.deploys += 1;
  if (dep.fixedAfter) row.failed += 1;
  for (const c of dep.commits) row.leads.push((Date.parse(dep.at) - Date.parse(c)) / 3600000);
  weeks.set(w, row);
}
for (const [w, r] of [...weeks].sort()) {
  console.log(w, 'deploys:', r.deploys, ' median commit-to-deploy (h):', median(r.leads).toFixed(1), ' needed a fix:', r.failed + '/' + r.deploys);
}

Run on the sample log, it printed:

2026-09-21 deploys: 3  median commit-to-deploy (h): 13.3  needed a fix: 1/3
2026-09-28 deploys: 2  median commit-to-deploy (h): 21.3  needed a fix: 0/2
2026-10-05 deploys: 1  median commit-to-deploy (h): 50.3  needed a fix: 0/1

Read the trend, not the figure. Fewer deploys per week with a lengthening commit-to-deploy time means slices are growing: the third week above has the longest wait because changes sat unreleased for days. Take that as a prompt to cut next week's slices smaller, and do not pursue a better number for its own sake.

When a week is the wrong length

Some work does not fit: a data migration, a redesign or anything that needs an external approval. Choose a longer cycle on purpose, up to the one-month ceiling in the Scrum Guide, and still ship slices inside it. Or keep the weekly release and let the big item advance as hidden slices week by week, which is how DORA's dark-launch approach is meant to be used. What fails is the unplanned overrun, where "this week" becomes three without anyone deciding it.

Checklist

• Choose one outcome per week and slice it into pieces that finish in about two days.
• Merge to main at least daily and keep main deployable; fix a red build before the next slice.
• Write the cut decision on Wednesday: the item, the reason and where it goes.
• Keep part of the week unplanned, sized from your own recent weeks.
• Log every deploy and read lead time and deploy count as a gauge, not a target.