What a year of running a nightclub system taught us about building for deadlines

What the system is, briefly

Three connected levels on one loop. The first automates campaign work on Meta, which is where this audience discovers events. The second manages and optimises ticket inventory, giving continuous visibility into how an event is selling. The third treats ticket sales as a process to optimise, reading what marketing is doing against what inventory is showing.

The levels feed each other, which is the part that makes it a system rather than three tools that happen to be owned by the same business. The full write-up is in the case study.

What follows is not about those components. It is about what running them for a year taught us about the shape of the problem, which turns out to apply well beyond nightlife.

The week is the unit of time, and that changes what reliable means

Most business software is designed around a month or a quarter. Nightlife is not. Every event is conceived, promoted and finished inside days, and then it happens again.

When your cycle is that short, a failure that would be a minor annoyance elsewhere is structural. A system that is down for a day in a monthly cycle has lost a small fraction of that cycle. The same outage in a weekly cycle lands on one of the few days that determine whether a room fills, and there is no next month to recover in.

• Recovery time matters more than uptime. The useful question is not what proportion of the time it works. It is how quickly it is working again, measured against a deadline that does not move.
• Every job needs a defined behaviour when a dependency is unavailable. Not an error, a decision: hold, retry, skip, or escalate to a person. Deciding that up front is most of the reliability work.
• Changes ship between events, not in a vacuum. There is no quiet week. Anything that cannot be deployed safely against a live calendar is not deployable at all.
• Silence has to be trustworthy. On a weekly cycle nobody has time to check whether a system is fine. It has to be loud when something is wrong and quiet otherwise, and the quiet has to be reliable enough to believe.

Perishable inventory makes the deadline the design constraint

A ticket to Saturday's event is worth something up to the moment the doors open, and then it is worth nothing. There is no clearance, no next quarter and no carrying it over. That single property reorganises every decision in the system.

It means the value of information decays. Knowing on Wednesday that an event is selling slowly is actionable. Knowing on Friday is interesting. Knowing on Sunday is a report.

It also means the cost of a delay is not proportional to its length. A day of latency early in a cycle is absorbed. The same day late in the cycle removes the only window in which anybody could have done something.

• Freshness beats completeness. A partial picture now is worth more than a complete one later, which is the opposite of how most reporting is designed.
• Alerts have to be timed to the decision, not to the data. The useful moment to say an event is behind is the last moment somebody can still act, and that is earlier than it feels.
• The system has to know where it is in a cycle. Sell-through means nothing as an absolute number. It only means something relative to how far out you are, which means every comparison is against a curve rather than a threshold.
• Latency is a feature specification. For anything perishable, how fresh the data is belongs in the requirements alongside what it contains.

What we automated, and what we deliberately did not

The clearest line we drew, and the one we would draw again, is between labour and judgement.

The campaign work is labour. Building and managing campaigns per event, week after week, is a job that consumes a person's evenings and consists mostly of repeating a process. That is exactly what a system should be doing, and handing it over does not cost the operator anything they wanted to keep.

Programming, brand and pricing calls are judgement. They depend on knowing the room, the scene, the crowd and what the venue is trying to be, and none of that is legible to a system. Automating them would have been technically possible and strategically wrong.

1. Take the repetition, leave the decisions. The test we use is whether the same inputs should always produce the same output. If yes, it is a candidate. If a good operator would sometimes answer differently, it is judgement.
2. Surface what a decision needs. A large part of the value turned out to be not making decisions faster but making them visible: putting the state of an event in front of somebody while the decision was still open.
3. Do not hide the mechanism. An operator who cannot see why the system did something will stop trusting it, and a system that is not trusted gets overridden into uselessness.
4. Leave the manual override in place, permanently. Not as a transitional measure. There are nights when the person knows something the system cannot.

Three levels, one loop, and why separate tools would not have done it

The temptation with a problem like this is to solve it in pieces. A campaign tool, an inventory view, a sales report. Each is easier to build, and each is genuinely useful on its own.

The reason they were built as one loop is that the questions worth answering all cross the boundaries. Whether a campaign is working is not answerable from campaign data. It is answerable from what happened to sell-through. Whether an event is behind is not answerable from ticket counts alone, because behind depends on what was being spent and where attention was going.

Three tools give you three views and leave the joining to a human at the end of a long week. That join is precisely the work that does not get done, which is why it was the thing worth building.

What running something is like, as opposed to building it

This is the part we underrated before this engagement, and it is why the ongoing shape has turned out to matter more than the initial build.

A system that has been live for a year is not the system that was launched. Upstream platforms change. Event patterns shift with the season. Assumptions that were reasonable in month one are quietly wrong by month eight, and nothing announces it.

• Assumptions decay silently. The failures that matter are not crashes. They are rules that keep executing correctly against a world that has moved.
• Somebody has to look, on a schedule. Not at whether it is running, at whether it is still right. That is a standing commitment, not a support ticket.
• The operator's questions change as they get better. A year in, the things being asked of the system are not the things it was originally specified to answer, and that is a sign of success rather than a scope problem.
• Documentation is what makes a year possible. Anything undocumented in a live system becomes load-bearing folklore within months.

What we would tell another venue or promoter

The architecture transfers, because the underlying shape does: perishable inventory, a hard date, a discovery channel where the audience already is, and a weekly cadence that never pauses. What differs is the ticketing setup and the event rhythm, which is what a scoping conversation establishes rather than something to assume.

Start with visibility, not automation. Knowing continuously how events are selling is worth having on its own, and it is the thing that tells you which automation is worth building.

Be honest about your cycle. A venue running weekly and a promoter running four events a year need different systems, and the second one should probably not build most of this.

Decide what stays human before you start. It is a much easier conversation in week one than in month six.

Expect the ongoing part to be real. A live system against a live calendar is a commitment. Anyone who tells you it is a build and then it runs itself has not run one.

Why there are no numbers in this post

Everything above is about design decisions, because those are ours to publish. The results belong to the client.

We do not put client performance figures on this site. Not real ones, not rounded ones, not approximate ones with a hedge attached. Partly because a venue's sell-through is commercially theirs rather than ours to advertise, and partly because those numbers, stripped of context, are the least honest kind of evidence in this industry: they cannot be verified by a reader, they cannot be attributed to any one cause, and every agency publishes them.

What we will do instead is put you on a call with the operator. If you run a venue, a room or an event calendar and want to hear how this works from the person living with it rather than from the people who built it, ask on the discovery call and we will arrange it.