Design subscription or fixed-price project?

In short

All four models sell the same thing: a designer's time. The difference is how that time is measured, and who pays the bill when the work takes longer.

• If your requests are constant and small, a subscription or a series of sprints makes sense.
• If you can write down screen by screen what you want, take a fixed-price project.
• If the work fits into one or two weeks, a single sprint is enough.
• If you don't know yet what you want, find the problem first and choose the model afterwards.

The picker below matches the kind and length of your work to a model. It doesn't estimate a price.

How the four models work

Design subscription

You pay a fixed monthly fee, and a request queue opens. The designer takes the next task, finishes it and moves on to the next. At the end of the month you continue or stop.

Its strength is predictability. You don't get a quote for every small task, and you know at the start of the month what you'll pay.

Its weakness is empty weeks. If you wrote no request in a month, the fee is still due. A subscription also usually designs what you ask for and doesn't question what you should ask for.

Fixed-price project

You write down the scope, and the other side gives a price and a delivery date. If the work takes longer than estimated, whoever wrote the quote pays for that time.

Anyone who knows this risk adds a buffer to the price. The vaguer the scope, the bigger the buffer. So writing the scope down clearly also lowers the price.

Its weakness is change. Every flow added along the way means a new negotiation. If the quote doesn't say how changes are priced, ask before you sign.

Hourly freelancer

The designer logs their hours, and you pay per hour. While it's unclear what to do, this is the most flexible model.

This time the risk is yours. The longer the work takes, the bigger the bill, and you learn the total only at the end. If you work by the hour, set a cap on the total hours.

Sprint

A sprint is a working period of fixed length agreed up front. The length doesn't change; what fits into that time is discussed.

The price per period is fixed; the scope within the period is flexible. The model sits between fixed price and subscription: you can take a single period and stop, or open several in a row when needed.

Who carries the risk?

When choosing a model, the real question is: who pays if the work takes longer or changes? I built the table around that question.

Model	When the price is fixed	Who pays if it takes longer
Subscription	At the start of every month.	You, with the next month's fee.
Fixed-price project	Before the work.	Whoever wrote the quote. If the scope changes, you.
Hourly freelancer	At the end of the work.	You, with every hour.
Sprint	At the start of the period.	You, with the next period.

Each model puts the risk on one side. With a subscription, the risk of the empty month is yours. With a fixed price, the risk of a wrong estimate is on the other side and shows up in the price.

In software development this tension is an old topic. One of the values in the 2001 Manifesto for Agile Software Development is responding to change over following a plan. A fixed-price project, by definition, is tied to a plan.

My view: if the scope really is clear, the plan helps. If it isn't, the plan becomes a contract in which every change gets expensive.

Why “sprint” means three different things

When reading quotes you'll meet the word “sprint” in at least three meanings. Ask which one is meant, so nothing gets mixed up.

• Scrum sprint. The 2020 Scrum Guide defines the sprint as a fixed-length event of one month or less. According to the guide, the scope within a sprint can be clarified and renegotiated with the Product Owner.
• Design Sprint. The Design Sprint as GV describes it is a five-day process. On Monday the goal is set; on Friday a prototype is tested with customers. At the end you have a realistic prototype and know what comes next. You don't have a product that goes live.
• Sprint as a service. A fixed-length, fixed-price period of design or development sold by a studio. The sprint I sell is of this kind.

What all three share is the fixed length. The difference is what you have in hand at the end of the period. Get that in writing in the quote.

Which model fits you?

Pick the kind and length of your work. The picker shows you a model, the reasoning behind it and the matching ux.center offer.

Pick a model

The picker needs JavaScript. The same matching rules are also in the table below.

This picker doesn't estimate a price. It matches the kind and length of your work to a working model; the rules are my own. With every choice the recommended model, the reasoning and the matching ux.center offer change.

I also wrote the same rules as a plain table:

Kind of work	Length	Matching model
A steady stream of small requests	1 to 2 weeks	Sprint.
A steady stream of small requests	1 to 3 months	Subscription or back-to-back sprints.
A steady stream of small requests	more than 3 months	Subscription or a designer on the team.
A project with a clear scope	1 to 2 weeks	Sprint.
A project with a clear scope	1 to 3 months	Fixed-price project.
A project with a clear scope	more than 3 months	Fixed-price project in phases.
Not clear yet	1 to 2 weeks	Hourly consulting or a short diagnosis.
Not clear yet	1 to 3 months	Diagnosis first, then a sprint or project.
Not clear yet	more than 3 months	Diagnosis first, then choose again.

The rules are a starting point. For work on the edge, the decision usually becomes clear in a 15-minute call.

When a subscription is the wrong choice

A subscription is a good model, but it doesn't suit every kind of work. In these cases I recommend a different model.

• When it's a one-off piece of work. The first version of a new app is a project. Put it into a monthly queue and it becomes unclear when it's finished.
• When you don't know what the problem is. The queue is only as good as the requests in it. Producing the wrong request quickly every month is a loss too.
• When the stream of requests is irregular. With two full months and one empty one, you pay for the empty month too.
• When code has to be written too. With a design-only subscription, the cost of the team that turns the design into code comes on top.

It's also clear when a subscription is the right choice. The product is live, the design system is in place, and the team knows every week what it wants. The requests are small and similar, and nobody wants to wait for a quote for each.

In a team like that, a subscription is a way to get regular design capacity without hiring a designer. On one condition: whoever writes the requests has to really know the product's problems.

Before a subscription, look at the last three months. How many design requests were there, and which weeks were empty? Those two numbers usually tell you whether a subscription fits.

When a fixed price works

A fixed price is for work whose scope can be written down. If you can make the list of screens and also list the empty, loading and error states, a fixed price gives you the clearest number.

When comparing quotes, look at the items: how many screens, which platform, is there research, is code included? Line those items up before you compare prices.

For long work, ask for a quote in phases instead of one fixed price. When the first phase is over, talk about the next one based on what you learned. I collected the questions to ask before working with a team in the guide to choosing a UX agency.

Example: the same team, four models

Imagine an ecommerce team. Checkout is often abandoned on mobile. On top of that, every week brings promotional banners and small fixes to screens.

This team really has two different kinds of work: a project whose scope can be written down, and an open-ended stream of requests.

• If it puts everything into a subscription: checkout goes into the queue too. The more banner requests come in between, the further the checkout end date slips.
• If it does everything as a fixed-price project: every small weekly task needs a quote. Writing the quote takes longer than the work.
• If it does everything with an hourly freelancer: both kinds of work move, but it only learns the total cost of checkout at the end.
• If it splits the work: a sprint or fixed-price project for checkout, a subscription or a designer on the team for the weekly requests.

I recommend the fourth. Instead of forcing one model on all the work, it's cheaper to give each piece of work the model that fits its kind. What's broken in checkout I find first with a review against the checkout pattern.

What to ask in the quote for each model

Whatever the model, get these questions answered in writing before you sign.

• With a subscription: how many requests run at once? What happens if I stop mid-month?
• With a fixed price: which screens are included? How many revision rounds are there? How is the new price worked out if the scope changes?
• By the hour: is there a weekly hours report? Is there a cap on the total?
• With a sprint: how many days is the period? At the end, do I have a design file, a prototype or code? What happens to work that doesn't fit?

For all of them two shared questions come on top. Do the files and code pass to you on payment? Who does the work, and have you talked to that person?

Every question whose answer stays unclear can turn into a dispute later. Ask these questions in the first conversation, and the quotes are easier to compare too.

Which model is there at ux.center?

I don't sell a subscription. Instead, I give the flexibility people look for in a subscription through the sprint.

• Design & Ship Sprint: $999 for 1 week or $1,949 for 2 weeks. Design and code together, straight into your repo. Starts the next business day.
• In the sprint I work on one request at a time. I aim to deliver each request within 24 hours.
• No monthly commitment. After the sprint you can stop or open the next one.
• Fixed-price project: you describe the scope, and within 24 hours I send one price and a delivery date.

Payment is up front by card. Prices are in USD and exclude VAT. The duration and payment method of every offer are on the pricing page.

The limit of this model is clear too. If you need several requests running at once, the sprint doesn't fit, because requests are handled one after another.

My note

To me, the question of the model is often a wish to postpone an uncertainty. A subscription is a comfortable way of saying “We'll think about what to do later”.

I'd rather shrink that uncertainty first. If the product is live, a UX audit shows what's broken. With the list in hand, the work becomes a sprint or a project.

The biggest risk of a subscription, to me, is that the person writing the request isn't a designer. “Redo this screen” goes into the queue, and nobody asks why the screen works badly. That's why I start the sprint by choosing the scope together.