What an 18-hour event build actually teaches you about deadlines

In August 2023 we were handed a brief with one immovable fact in it: doors open at 8:00 AM. Everything else — crowd size, final stage design, sponsor requirements — was still moving. We started building at 8:00 PM the night before.

The event went ahead. Over three lakh people turned up. What follows is what that night taught us, most of which we now apply to software projects that have nothing to do with staging.

Plan backwards from the immovable thing

Every project has exactly one date that cannot move. On an event it is obvious — the doors. In software it is usually hidden behind a wall of “ASAP”, and finding it is the first real piece of work.

Once you have it, you schedule in reverse. Not “what do we start on Monday” but “what has to be finished by Thursday for Friday to be possible”. Forward planning hides slack in the middle of a project where you cannot see it. Backward planning puts the pressure exactly where it belongs.

Give every workstream its own hard cutoff

Our failure mode that night would have been cascade: lighting waits on stage, audio waits on lighting, signage waits on everything, and one ninety-minute delay at the start eats the entire morning.

So each trade got its own deadline with its own buffer, and a rule that a late workstream does not get to push into the next one’s window — it gets more people instead. It is the same discipline as keeping software teams decoupled behind a stable interface. The point is not that nothing runs late. The point is that when something does, it runs late alone.

Own the handoffs or they will own you

The single biggest saving that night was not working faster. It was that stage, lighting, AV, signage and branding were all run by our own team rather than coordinated across five vendors.

Handoffs are where hours disappear — in the gap between one company finishing and another starting, in the phone call that goes unanswered at 2 AM, in the spec that meant two different things to the two people reading it. Removing a handoff is almost always worth more than optimising the work on either side of it.

This is why we run development, marketing and production under one roof. Not because a single company is inherently better at all three, but because the seams between three companies are where projects actually fail.

Decide the safety floor before you optimise anything

Crowd estimates ranged so widely that planning for the low end was a safety risk and planning for the high end was a budget risk. So we set the floor first — what has to be true for this to be safe at the high end — and treated it as non-negotiable. Everything else got optimised around it.

Software has the same shape. Decide your non-negotiables — data integrity, auth, the thing that must never go down — and then let everything else flex. Teams that try to optimise everything equally end up compromising the one thing they could not afford to.

What it is actually worth

None of this makes the work take less time. What it does is make the remaining time predictable, which is the thing clients are really buying when they ask for a deadline.

We finished at 8:00 AM. Not because the night went smoothly — it did not — but because the plan assumed it would not.