Launch Countdown Planner

A launch date is a promise made early and defended late. The plan behind it is usually a checklist with no dates on it, which means nobody knows whether it fits until the fortnight when it obviously does not. This puts a start date on every item by working backwards from the launch, in working days, and tells you immediately if the plan was never deliverable.

The date itself

Everything is measured backwards from this day.

What has to happen

One per line, as: name, days before the date it must be done, how long it takes. The third number is optional and defaults to a day.

Skip weekends

Your plan will appear here, working backwards from the date.

What this generator does

Computes a start and finish date for every task by working backwards from the launch date, counting working days by default. Each task's finish is the launch minus its lead time and its start is that finish minus its duration; the earliest start is when the work has to begin. Tasks whose start date has already passed are flagged as overdue, with the shortfall in days — which is the number the conversation about moving the date should be about.

How to use this tool

Set the launch date.
List each task: what it is, how many days before launch it must be done, and how long it takes.
Leave weekends skipped unless your team genuinely works them.
Press Work backwards, and check whether anything is already overdue.

Understanding the controls

The date itself: The launch date. Everything else is derived from it, so changing it and replanning is the fastest way to find a date that works.
What has to happen: One task per line: name, days before launch it must be complete, and how long it takes. Lead time is a deadline, not a start — 'agree the scope, 60' means signed off 60 days out. Duration is in working days when weekends are skipped.
Skip weekends: On by default here, because launch work happens on weekdays. It changes the answer substantially: twenty working days is four weeks of calendar, not three.

Worked examples

Build it, 30, 20: Twenty working days, finishing 30 days before launch.
Internal review, 10, 2: Two working days, done ten days out.
Brief support, 5: A single day, five days before launch.
The useful failure: 'This plan does not fit. 3 tasks would have had to start already.'

Common use cases

Putting real dates on a launch checklist before committing to the date
Finding out whether a launch date is deliverable while it is still moveable
Working out the last responsible day to freeze scope
Giving a team a timeline where each person can see when their part starts
Sanity-checking a date somebody else has already promised

How this generator works

A backward pass over the task list. Each task's finish date is the launch minus its lead time; its start is the finish minus its duration, counting the finish day itself. With weekends skipped both steps count working days and results are nudged off Saturdays and Sundays, which is where hand-built timelines usually go wrong: five working days back from a Monday is the previous Monday, and across a dozen tasks that gap compounds into a week. Tasks are sorted by start date so the plan reads as a sequence, and any start before today is marked overdue. The shortfall reported is the largest overshoot — the amount of time the plan is actually missing.

Randomness and fairness

Nothing here is random. The same launch date and the same tasks always give the same plan, which is what makes it usable as a shared reference.

For how randomness is produced across the whole site, see how Generate Random works.

Assumptions this tool makes

A lead time is a deadline measured back from launch, not a start date.
Durations are working days when weekends are skipped, and calendar days otherwise.

Limitations and good to know

Tasks are scheduled independently. Nothing here knows that the announcement cannot be written before the scope is agreed, so a set of lead times that implies the wrong order will be scheduled in the wrong order.
There is no resource model. Four tasks in the same week may be fine for a team of six and impossible for one person, and the plan looks identical either way.
Only weekends are skipped, not public holidays. A plan spanning a bank holiday or a shutdown period needs padding by hand.
Lead times and durations are estimates you supply. The arithmetic cannot improve on them, and a confident-looking timeline built from optimistic inputs is still an optimistic timeline.
It produces a plan, not a tracker. Nothing is saved, and it does not know what has already been done.

Common mistakes

Treating the lead time as a start date: It is the deadline. 'Build it, 30, 20' means finished 30 working days before launch, having started 20 working days before that.
Planning to the launch date rather than to the freeze: Give the last genuinely flexible task a lead time of a week or more. A plan where the final task finishes on launch day has no room for the thing that always goes wrong.
Arguing about the date instead of the shortfall: The shortfall is a number of days. It converts an argument about whether the date is realistic into a question about which specific week to find, which is a much easier conversation.

Practical tips

Plan it before the date is announced. The whole value is in finding out that a date does not fit while it can still change.
Add the tasks people forget: security review, legal sign-off, support briefing. They have long lead times and no visible progress, which is why they get left out.
Rerun with the date a week later to see what that buys. It is usually more than people expect, because it moves every dependent start date too.

Troubleshooting

The plan fits but feels wrong: Check how many tasks start in the same week. The tool schedules each independently, so a plan that fits on paper can still be four people's work landing on one person's desk at once.
Turning weekends off made everything fit: It would. That is only a real answer if the team actually works weekends — otherwise it has moved the problem rather than solved it.

Privacy and your data

Task names and dates stay in the browser. Nothing is uploaded, stored, or written into the page address — which matters for an unannounced launch, where the task list alone can give away the plan. Analytics records only that the tool ran and how many tasks were in the list.

Frequently asked questions

Why work backwards from launch instead of forwards from now?: Because the launch date is the fixed constraint and the work is what has to bend. Planning forwards produces a schedule that overruns at the far end, which you discover last. Planning backwards places every task against the constraint, so an undeliverable plan is obvious on the first day rather than the final fortnight.
How should I decide the lead times?: Ask when each task must be finished for the next one to be possible, not how long it takes — the duration covers that. Anything depending on someone outside the team needs a lead time well beyond its duration, because most of that time is waiting rather than working.
Can it tell me if the date is realistic?: It can tell you whether the plan you entered fits in the time available, which is a narrower and more useful question. If nothing is overdue, the plan fits given your estimates. Whether those estimates are realistic is a judgement no calculator can make for you.
Why is 'skip weekends' on by default here?: Because launch work is weekday work, and counting weekends silently shortens every duration by two days a week. The event planner defaults the other way for the opposite reason: parties and weddings genuinely get organised at weekends.