Day of Design
All insights
Founder's Log5 min2026-04-14

Why We Don't Do Rush Jobs

A subscription model only works if the queue is bounded. Saying no to rush work isn't a service limit — it's the service.

We get about two "emergency" requests a week.

"Launching Monday, can you turn this deck around by end of day?" "The board meeting moved up, we need the homepage live tomorrow." "Our competitor just dropped a thing, can you match it by Friday?"

We say no to most of them. Not because we can't technically do it — we've done fast work under fire for nine years. We say no because saying yes would break the system we're charging clients for.

The subscription promise

A subscription works like this: the client pays a flat monthly fee and gets a queue of design + AI tasks, delivered in typically 24-48 hours per task, in the order they asked for them. They can pause. They can cancel. They don't negotiate per-job.

The whole reason this works — for us and for the client — is that the throughput is predictable. We can staff against it, cost it, and guarantee quality because we know the queue depth and the expected turn time.

A rush job doesn't just add one more item to the queue. It jumps the queue. That means the five tasks behind it get slower. If I say yes to one rush job, I've degraded the service for five other people who are paying the same flat fee.

What happens when studios break this

I've watched agencies agree to every rush request because saying no felt like weakness. Within six months:

  • The good people leave because they can't plan their week.
  • The bad work ships because there's no time for craft.
  • The subscription collapses into retainer — same price, worse service, and the client starts comparing you to project-based shops who quote per-job at 1/3 the cost.

Saying yes to every rush feels like customer service. It's actually the fastest way to lose the customers who valued the subscription discipline in the first place.

When we do accept rush work

There's a version that works. We call it priority insertion, and it has three rules:

  1. The client names it as priority themselves. They bump it over their other queued items — total queue depth doesn't increase.
  2. Turnaround is the fastest tier's SLA, not faster. (24h on Professional, 48h on Starter.) The number doesn't shrink.
  3. If neither of the above works, we quote a one-off project fee outside the subscription. The fee reflects the true cost of breaking the queue for everyone else.

About 70% of "emergencies" resolve under rule 1 — the client just needed to re-rank what was already queued. Another 20% accept rule 2. The remaining 10% go with rule 3, and they're the ones where the fee is actually appropriate.

The hidden message in saying no

When you hold the line on the queue, something interesting happens: clients start treating their own work more seriously. They stop firing off half-formed requests because they know each one costs them a slot in the queue. They write better briefs. They consolidate three small asks into one sharp one.

It's the same dynamic as good error messages in software: being precise about what you won't do teaches the user to be precise about what they want.

We lose a few potential clients in the sales conversation when this comes up. Almost always the ones who were shopping for on-demand freelance labour at a subscription price. That's fine. The system we built wasn't for them.

Book a strategy call

Thirty minutes to see if we should work together.

Tell us where the work is stuck. We'll assess fit and give you one or two next steps you can act on immediately.

Book a Call