Gabriel Espinheira
The last agency kept ten things "in progress." Six months later, none of them had shipped. The dashboard stayed busy — green arrows, a burndown chart, a status column three cards deep — and the business hadn't moved a millimetre. If you've run an owner-operated company for a while, you've lived some version of this: plenty of motion, nothing you can point to. So when a subscription says it works one request at a time, it sounds like a downgrade. It isn't. That single-active-request limit is the reason work ships at all, and there's ordinary maths behind why.
TL;DR: "Unlimited requests, one at a time" isn't rationing your capacity. Working a single active request is the only way a subscription can promise a real weekly cadence, because queueing maths (Little's Law) says the way to ship faster is to hold less in progress, not more. The limit is the product.
What "unlimited requests" actually promises
Read the small print on any "unlimited" plan and the word is doing a lot of quiet work. Unlimited describes how many requests you can stack in the queue and how many revisions each one gets. It says nothing about how many run at once. One task is active; everything else waits its turn.
The design and creative subscriptions that popularised this model sell it exactly that way — unlimited requests, worked one at a time, with a rough turnaround on each. The queue is the mechanism that lets one senior operator serve several clients without lying about capacity. Most write-ups explain that from the provider's side: the queue protects the agency's margin. True enough. What almost nobody tells the buyer is that the same constraint is protecting them.
The maths says more in progress ships slower
In 1961, an MIT professor named John Little published the proof for a formula that now governs serious production queues everywhere: average cycle time equals work in progress divided by throughput. Rearrange it and the awkward part surfaces. With throughput fixed, the more you hold in progress, the longer each item takes to finish.
Throughput is how much a team can actually complete in a week. A senior-led subscription has one senior partner and a tight contractor stack, so throughput is real but bounded. "Unlimited requests" can't raise it. All the phrase can raise is work-in-progress — and by Little's Law, that lengthens the time every request spends in the system. You feel productive because ten cards are inching forward. Each one lands later than it would have if you'd run them in sequence. A queue capped at one active request is the shortest honest path from "asked for" to "shipped."
Ten open tasks cost more than they look
Splitting attention isn't free, and the bill is larger than most founders budget for. David Meyer, whose team ran the landmark task-switching experiments published in 2001, has put the cost of flipping between jobs at up to 40% of productive time. That figure is his own extrapolation rather than a line in the paper, and it's worth saying so plainly — but the direction isn't in dispute. Every switch reloads the problem, and complex creative and engineering work reloads slowly.
So ten live requests don't hand the operator 10% each. They get less than that, because the switching between them burns hours that never touch the actual work. One active request removes the switch. The person building it holds the whole problem in their head until it's done, then picks up the next one clean.
A queue you can watch is the honest version
Most agency relationships feel like a black box because the work in progress lives somewhere you can't see. You get a monthly report instead — "reports full of jargon, green arrows, and charts that don't really mean anything," as one owner described it. A green arrow is not shipped work.
SharpHaw runs the queue in the open, inside SharpOS. Every request moves through four columns you can watch: Backlog, In Progress, Review, Published. One card sits in In Progress at a time. You can see what's active, what's next, and what landed this week without booking a status call. That visibility only works because the limit exists. A board with forty things "in progress" is a to-do list pretending to be a plan. "I want results, not reports" is the whole design brief.
What one at a time forces you to decide
The real work the limit does happens upstream of the shipping: it makes you rank. When only one request can be active, "do everything" stops being an option and "what matters most this week" becomes a question you have to answer out loud.
That's the trade. You give up the comfortable sense of everything moving at once. In return you get a weekly conversation about priority — the one a fat retainer lets an agency avoid, because looking busy on ten fronts is easier than choosing. A good queue is ruthless about sequence: the landing page leaking enquiries goes before the blog refresh that can wait a fortnight. If your gut says all ten are urgent, that gut is exactly what stalled the last engagement.
When one at a time is the wrong fit
This model has a real edge, and naming it is only fair. If you genuinely need five separate workstreams running in parallel, each with its own owner and deadline, a single senior queue is not your tool. You want a team sold by the hour or a set of in-house hires, and you should buy that structure with your eyes open.
The one-at-a-time queue fits the owner-operator who has more marketing ideas than time, no internal marketer to run them, and wants one senior partner accountable for both sequence and outcome. For that owner, the limit is the difference between a two-year backlog and a weekly habit.
Frequently asked questions
Does "one request at a time" mean the work is slow?
Usually the opposite. Because only one request is active, it moves start to finish without queueing behind nine others. Total output is set by the team's weekly throughput, not by how many tickets sit open, so a single active request is the fastest route from asked to shipped.
Is an unlimited-requests subscription worth it?
It's worth it when you have a steady backlog of marketing work, no one internal to run it, and a provider who's honest that "unlimited" means queue depth rather than simultaneous output. It's poor value if you expected ten things built at once — no subscription gives you that from one senior operator.
How many requests actually get done in a month?
As many as the team's weekly throughput allows, shipped in priority order. The useful question isn't "how many can I submit" but "what's the weekly shipping rate, and can I see it?" A visible queue answers both; a monthly report answers neither.
What counts as one request?
One shippable change with a clear finish line: a new landing page, an ad set rebuild, a month of content, an automation. Vague, open-ended asks get split into sequenced requests so each has a real "done" — which is what keeps the queue moving instead of clogging it.
What to do next
A subscription that runs one request at a time is making a promise it can keep: the next thing on your list ships this week, and you can watch it happen. "Unlimited" makes a promise about the queue. One-at-a-time makes a promise about output. Pick the one you can see.
Want to test it? Book a 30-min call, bring the three changes you'd want shipped first, and we'll rank them into a queue you can watch — the terms, and the exit, are already on the Plans page.
