What a delivery date should actually mean

There are two things a date can mean, and they get used interchangeably in a way that costs people money.

An estimate is a prediction.

It says: based on what we know now, this is roughly how long we think it will take.

Estimates are useful. They're also, by definition, wrong some of the time—that's what makes them estimates rather than commitments.

A commitment is a promise.

It says: we have organised our work so that this date happens, and if it doesn't, that's on us.

The trouble starts when an estimate is presented as a commitment.

You plan around it—a product launch, a lease, a marketing spend, a seasonal campaign—and then it moves. The reasons sound reasonable, but there's nothing you can do because the date was never load-bearing. It just looked like it was.

What has to be true before a date is worth committing to

A date is only as solid as the four things underneath it.

The scope is written down and agreed

Not "a website with a few pages"—an actual list of what's being built.

You cannot commit to a date for work nobody has defined, because every undefined piece is a place the timeline can quietly expand.

Someone is accountable for the date specifically

Not for the project generally.

There's a difference between a team that wants to finish on time and a team where missing the date has a consequence.

Both sides know what they owe

Almost every genuinely late project has a stretch in the middle where the work was waiting on a decision, a logo file, or a piece of copy.

If the agreement only describes what the builder owes, half the timeline is undefended.

There's a mechanism for change

Scope changes are normal and often good.

What's not normal is scope changing while the date stays the same on paper and everyone privately knows it won't hold.

A change should produce a new, agreed date, in writing, before the work starts.

Take any one of those away and the date reverts to an estimate, whatever it's called in the proposal.

Why we quote a date after discovery, not before

We don't give a launch date in a first conversation, and we'd be suspicious of anyone who does.

At that point, nobody knows what's being built—not because the client hasn't explained it, but because the questions that determine the timeline haven't been asked yet.

For example:

• How many pages actually need bespoke design?
• Where is the content coming from?
• What has to integrate with what?

So the date comes at the end of a paid discovery week, alongside a written scope and a fixed price.

By then, it's a commitment rather than a guess, because all four conditions above are in place.

What we can and can't promise

We can't promise the world never intervenes.

People get sick. Suppliers go down. Life happens to small teams, and any firm claiming perfect immunity to that is telling you something untrue on the first page.

What we can promise is narrower—and more useful.

• We don't commit to a date we don't believe we can meet.
• We tell you the same day if anything threatens that date, rather than waiting until the deadline.
• The consequence for missing it is written into the contract before you sign—not offered as an apology afterwards.

That's the whole distinction.

A date you can plan around isn't a more optimistic estimate.

It's a different kind of thing entirely.