One Product at a Time, and Why the App Enforces It
The workflow in SendShelf has nine stages: idea, ordered, received, script, recording, editing, ready to upload, in review, live. Four of those — script, recording, editing, ready to upload — are collectively one card wide. One product can be in production at a time, across all four, and moving a second one in is refused.
People push back on this before they use it and stop mentioning it afterwards. It is worth explaining why it is there, because it is the one thing about the tool that looks like an arbitrary restriction and is not.
What five in flight actually costs
Starting a product is cheap and finishing one is not. So without a limit, the natural drift is to start things: you unbox one, write half a script, hit something awkward, and start the next one instead. Nobody decides to do this. It happens one reasonable-seeming step at a time.
The state you end up in is five products in various stages of half-done. That would be merely untidy if the only cost were attention. It is not, because each of those five has a return window running, and those windows do not pause while you think.
This is the part that makes a work-in-progress limit different for this job than for most. In ordinary knowledge work, too much in flight costs you throughput and some context-switching — real, but recoverable. Here every extra started product is a countdown you have committed to and are not watching. Five started products is five deadlines. Finishing one of them and letting the other four expire is not four delayed videos, it is four purchases you did not mean to make.
The limit is not about focus, in other words. It is about not taking on more financial exposure than you can film through.
The queue, and why you cannot reorder it
Behind the production lane sits the queue: everything received and not yet started. It sorts itself — soonest return date first, then by cost descending, then by how long it has been sitting.
There is no drag handle in that column. You cannot reorder it, and this is the second thing people push back on.
The reason is that a sortable queue gets sorted by mood. Not deliberately: you open the app, glance down the list, and pick the one you feel able to do today. That is almost always the cheap easy one, because the expensive one needs better lighting and a script you want to get right. So the expensive item — the one with the most money on the clock, the one that most needs doing — drifts downward every time you look at it. The mechanism that produces the loss is exactly the mechanism that feels like sensible prioritising in the moment.
Sorting by “money at risk soonest” removes the choice, and removing the choice is the point. The top card is the next card. On a morning when you do not want to decide anything, that is worth more than any feature we could have built instead.
Park and swap: a choice, not a wall
Here is where the limit stops being a restriction, and it is the part that does not come across until you have used it.
When you try to move a second product into production, SendShelf does not just say no. It names the card that is blocking you and offers to park that card back in the queue, so you can swap in one click. The work you had already done is not thrown away — the script stays, the notes stay, the history stays — and the parked product returns to the queue in its rightful place, sorted by its own deadline like everything else.
So the limit is not “you may not switch”. It is “switching is a thing you do on purpose, once, and see happen”. You are allowed to decide the product in front of you is the wrong one. What you are not allowed to do is have five, which is what happens when switching costs nothing and leaves no trace.
That distinction is the whole design. A hard wall would be wrong, because the real reason to switch — this product needs a prop I do not have until Thursday — is legitimate and common. An unlimited lane is also wrong, for the reasons above. The middle is a limit that yields to a deliberate act and refuses an accidental one.
What is deliberately not limited
Two stages sit outside the lane and are unlimited: in review and live.
Once a video is submitted, how long moderation takes is not yours to control. Blocking the next product behind a queue you cannot influence would be a limit that punishes you for someone else’s latency, which is the failure mode that makes people abandon work-in-progress limits everywhere they are tried. So a submitted video leaves the lane, and you start the next one immediately.
The same is true of published videos. They stay on the board because the record is useful, not because they occupy a slot.
There is also a rework path, and it matters here. A rejected video goes back to recording or editing with the reason attached, and the rejection count travels with the product — so rework re-enters the lane properly rather than becoming a fifth thing you have quietly started. You can also withdraw something you have already submitted, if you watched it back and spotted the problem before the moderator did, without losing the work.
The number is a setting, and the default is one
The limit is a real setting with a real value, and the default is one.
We think one is right for a solo creator filming onsite reviews, for the reason this whole post has been making: the cost of an extra started product is not diluted attention, it is an extra live deadline. But it is a number, not a law, and if your setup genuinely supports two lanes then two is what it should be.
What we would ask is that you change it deliberately rather than because a particular week was awkward. The awkward week is exactly when the limit is doing its job.
If you want to see what this looks like in practice, the features page walks through the whole workflow — and if you are still deciding whether any of this applies to you, we wrote down exactly who it is and is not for. Otherwise, create an account; SendShelf is invite-only for now and every account is reviewed by hand.