Unlimited development subscription: what it means, and what it does not
Unlimited does not promise a quantity of work. It promises you will stop asking permission before asking for something. What the model really covers, what it never covers, and how to tell a healthy offer from one heading for trouble.
"Unlimited" does not describe the volume delivered
An unlimited development subscription does not promise a quantity of work. It promises that you will no longer have to ask permission before asking for something.
The distinction sounds thin. It decides everything that follows, and it is where half of all disappointments are manufactured. What is unlimited is the request queue: you add as many as you want, whenever you want, with no amendment and no fresh estimate. What is not unlimited is the production capacity facing it.
A provider who says "unlimited" without ever saying what is not sells an ambiguity. It holds for three months, long enough for the client to realise that a full rebuild and a button fix do not cost the same to produce.
An honest offer therefore states its limit on the pricing page itself. Ours is written out in our FAQ: the volume delivered depends on the complexity of what is asked. That is not fine print, it is the heart of the model.
02
The three limits no subscription removes
Whatever the provider, three constraints stay in place. No offer erases them, and every serious offer names them.
The first is production time. A mobile app does not get built in a week because the subscription is monthly. The second is framing effort: a vague request costs more to understand than to build, and that time comes out of your queue. The third is human availability, which does not stretch because a payment recurs.
These three limits are not flaws in the model. They are the reasons a fixed price can exist without anyone losing money, and therefore the reasons the offer will still stand in twelve months.
It is the same logic as senior technical reinforcement: what you buy is available capacity, not a stock of hours to burn through.
03
One request at a time, and why that is the right constraint
The core mechanism of a development subscription fits in one sentence: you fill a queue, the provider works the first item, you approve, they move to the next.
This constraint is the part people understand least, and it is the part that protects the client. Here is what it produces in practice.
01
You keep control of the order
Your priority shifts on a Tuesday morning? You reorder the queue. There is nothing to renegotiate, because nothing was contracted at the request level. The contract covers capacity, not the list.
02
Nothing is lost to parallelism
Four projects open at once means four half-finished projects and four contexts to reload. One request at a time produces fewer open subjects and more finished ones. The difference shows within two months.
03
The price stays predictable for both sides
A slot is a unit of production. It can be counted, so it can be sold at a fixed price. If you genuinely need two fronts moving, you add a slot rather than dilute the first.
This is the opposite of a time-and-materials arrangement, where you buy days and carry the risk that those days produce nothing. Here you buy a flow of deliveries, approved one by one.
“Opening three projects in parallel for one client means producing three half-finished projects. The single-flow constraint delivers more, not less.”
04
Six questions to ask before signing
Subscription offers all look alike on their home page. They differ on these six answers, and a serious provider gives them in thirty seconds.
The fourth question is the most revealing. A provider whose model rests on retention through dependency will hesitate. A provider whose model rests on delivered value answers immediately, because the answer costs them nothing.
05
Telling a healthy offer from one heading for trouble
The table below does not pit providers against each other, it pits two ways of phrasing the same offer. The right-hand column is the one that survives a second year.
Two ways of selling a development subscription
On
Fragile phrasing
Phrasing that holds
The word unlimited
Used alone, with no object
Explicitly tied to the request queue
Parallelism
Never quantified
A stated number of flows, and it is priced
Exclusions
Found in the terms and conditions
Listed on the pricing page
Leaving
Notice period, fees, code to negotiate
No notice, code and access handed over
Price
On request, after qualification
Published openly
A public price is more than a sales argument. It is a commitment not to charge two clients differently for the same thing, and anyone can verify it.
06
Who this model works for, and who it does not
A development subscription suits one precise situation: a living product, a roadmap that moves, and nobody in house to carry it technically. That is the SaaS founder with no technical director, the SME leader with an internal tool to evolve, or the team juggling several freelancers.
It does not suit two situations, and that should be said before selling. A genuinely fixed scope, known in advance and dated, is better handled as a project package: the provider then carries the overrun risk, which a subscription does not. And a one-off need of a few days does not justify a monthly commitment.
This is not a salesperson's nuance. A client who subscribes for a closed need will feel trapped within six weeks, and they will be right.
Choosing the model comes before choosing the provider, and it deserves the same care as choosing a technical partner.
Frequently asked
What we get asked most often
The three questions that come up on every first call.
How much does an unlimited development subscription cost?
Public prices in the French market run from a few hundred euros to several thousand per month, and that spread means nothing until you relate it to parallelism. A low rate can mean a single very slow flow, production subcontracted far away, or a scope that excludes shipping to production. So always compare a price per production flow, never a bare price. At Figue, the subscription starts at 1,490 euros excluding VAT per month per slot, published openly.
How many requests can I expect per month?
No honest provider will give you a number, and you should be wary of one who does. What can be measured is the flow: one active request at a time per slot, delivered then approved before the next. Over a month that means many small requests or one large one, and you are the one who decides by ordering your queue.
What happens if I stop after two months?
With a decent provider, nothing special: you cancel with no notice, the month in progress remains due, and you leave with the code, the designs and the access. If the answer to that question involves conditions, a minimum term or exit fees, it is not a subscription, it is a commitment in disguise.
07
What to check, in short
An unlimited development subscription is a good model when it is phrased honestly, and a bad one when it rests on an ambiguity. The difference is not in the price, it is in what the provider agrees to put in writing.
Look for three sentences on the page in front of you: what "unlimited" refers to, how many projects move in parallel, and what happens the day you leave. If all three are there, you can discuss the rest. If one is missing, ask before talking money.
“The best test of an unlimited offer is how precisely it describes what it does not do.”
