Free playbooks in your inbox

How to Sell Unlimited Claude Design Without Working Weekends

Put the word unlimited on your own Claude Design offer page and mean it, because a queue does the enforcement instead of you. Here is the intake-to-delivery shape and the one sentence that goes on the card next to the price.

From the youcanbuildthings catalog ▸ Build-tested

Hello builders,

You can put the word unlimited on your own offer page this week and mean every letter of it. The unlimited design subscription model does not fail because clients ask for too much, and today we build the one thing that makes it safe: a queue that does the enforcement so you never have to.

We start with the fear, because yours is aimed at the wrong word. One greedy client, a flat monthly fee, and you are working every weekend until you die. An operator watching agencies try to run manual retainers at scale gave that failure the best name I’ve read: administrative suicide.

Your instinct is right and your target is wrong. What you are actually afraid of is not volume, it is simultaneity: being pulled in four directions on a Tuesday by one client who paid once. Those are different fears with completely different fixes, and only one of them has a mechanism.

What unlimited actually promises

So let us go read the one that has been running for years. Here is the Designjoy FAQ, word for word:

Is there a limit to how many requests I can make? “Once subscribed, you’re able to add as many design requests to your queue as you’d like, and they will be delivered one by one.”

Source: designjoy.co. Read that twice, because there are two separate promises in it and everybody only sees the first.

Unlimited requests. Serialized delivery.

The client can ask for anything they want, whenever they want, and they’ll never hear no, which is exactly why the word unlimited can sit on the sales page and do its job. What the client cannot do is make two things happen at once. There’s a queue, and the queue moves at your speed rather than theirs. The pricing card says it in five words: one request at a time.

So you don’t cap the work. You cap the concurrency.

A queue diagram from the book, headed "Productize or Die" with the subtitle "The Queue Is Your Promise." Three columns run left to right. UNLIMITED INTAKE holds a stack of request cards including "Website hero update," "New pricing page," "Social post template," "Case study layout" and "Product one-pager" tagged "it's next," under the note "Add as many requests to your queue as you'd like." ONE ACTIVE LANE narrows to a single card marked IN PROGRESS, under the note "All requests wait their turn. Only one is in progress." SERIALIZED DELIVERY shows three delivered items marked Day 1, Day 2 and Day 3, under the note "Delivered one by one, on a steady rhythm." A callout reads "The queue is wide. The throat is narrow. The rhythm is steady," and the footer reads "Unlimited is about intake. One at a time is about delivery. Different axes. Same system."

Sit with how good that is. Every fear you have about unlimited scope is a fear about simultaneity, and the queue kills it without ever telling a client no. The word no never appears in the transaction. It is just “that’s next”, which is a thing a happy customer hears rather than an argument.

Write the concurrency line

Now the part that decides whether anything we wrote survives contact with a real client. The line goes on the card, next to the price, in the same font as the benefits, and you write it before you have a client who tests it:

  • entry tier, the one at $5,500: one active request, and revisions go in the queue
  • project tier, the one at $14,000: one active request, staged, so they see work every 24 to 48 hours until the whole thing is done
  • retainer tier, the one at $6,500 a month: one active request at a time, plus a standing slot each week

Look at what we just did there. You made a promise about speed and sequence, and you made no promise whatsoever about simultaneity.

The queue itself is your own plumbing, and it always will be. Claude Design designs, and it ships no ticket system and no CRM, so pick a boring tool for the board and spend zero creative energy on it.

The reason it belongs on the sheet instead of in your head is that an unwritten policy is a negotiation, and the negotiation happens on the worst possible day: the one where a client is already frustrated and you are already tired. Written down in advance, inside the thing they bought, it is not a boundary you are defending. It is just how the product works, and nobody argues with a vending machine.

Your instinct will also be to bury this line below the fold, because it is the least appealing thing you have to say. Do not. It is the only line on the page that proves the rest is real. Anybody promising unlimited concurrent design from one person is lying, and your buyer has been lied to before by somebody who was that eager.

Then the big request lands

Here is the scariest ticket you will ever receive, and it is from your best client: can you redesign the whole app?

That request is worth more than your entire tier and it’s plainly outside your fixed scope, so the promise you made has two obvious ways to die. Say yes and eat it, or say no and watch them leave. There’s a third door, and it’s on the same FAQ:

How do you handle larger requests? “Larger requests are broken down on Designjoy’s end. This applies to full-scale website or mobile app designs, UI/UX work, etc. You should expect to receive a reasonable amount of work every 24-48 hours until the entire request is done.”

He never refuses the giant request and never argues about whether it is in scope. He decomposes it and feeds it through the same queue at the same rate, and the client sees real work every 24 to 48 hours until it is done. The big one stops being a threat the moment we stop treating it as one object, because it is just cards, and cards go in a queue.

So the conversation you were dreading turns into one sentence: that is a big one, so I will break it into pieces, you will see the first inside 48 hours, and we keep going until it is finished. Nobody is angry and nobody is negotiating.

One last thing, for the month when delivery starts slipping and you are sure a client is taking advantage. Before we have the boundary conversation, go and count that client’s active cards. You will find two. You did not lose the boundary, you lost the queue, and two active requests means each one moves at half speed so both are late. Go back to one.

Now go build something this weekend!

John Cook

Why trust this? Every youcanbuildthings guide is pulled from a build-tested book: code that ran in production before it was written down.