{"id":4352,"date":"2026-10-08T10:36:43","date_gmt":"2026-10-08T10:36:43","guid":{"rendered":"https:\/\/www.liquidwebdevelopers.com\/blog\/?p=4352"},"modified":"2026-10-19T11:39:50","modified_gmt":"2026-10-19T11:39:50","slug":"fixed-price-vs-hourly-vs-retainer-which-to-choose","status":"publish","type":"post","link":"https:\/\/www.liquidwebdevelopers.com\/blog\/fixed-price-vs-hourly-vs-retainer-which-to-choose\/","title":{"rendered":"Fixed Price vs Hourly vs Retainer: Which to Choose"},"content":{"rendered":"

Pricing models are usually discussed as though one is inherently fairer. They are not. Each one moves risk to a different place, and the right choice depends on how well the work can be specified before it starts.<\/p>\n

Fixed price moves risk to the developer,<\/strong>\u00a0who prices that risk into the number.<\/p>\n

Hourly moves risk to you,<\/strong>\u00a0which is why it looks cheaper per unit.<\/p>\n

A retainer moves risk to nobody in particular,<\/strong>\u00a0and instead buys availability.<\/p>\n

Once you see it that way, the decision becomes about how much certainty the work permits rather than about which model feels safer.<\/p>\n

<\/span>Fixed price<\/span><\/h3>\n

How it works.<\/strong>\u00a0An agreed scope for an agreed price, regardless of how long it takes.<\/p>\n

Where it is strong.<\/strong>\u00a0Budget certainty, which for many businesses is the deciding factor. The developer absorbs estimation risk, so an overrun is their problem. It forces specification, because nobody can fix a price without defining the work, and that discipline often improves the project. And it aligns the developer with efficiency.<\/p>\n

Where it fails.<\/strong>\u00a0It requires a well-defined scope, and if your requirements are uncertain, you are fixing a price against something nobody understands yet. The buffer is invisible \u2014 you are paying for risk that may not materialise, and you cannot see how much. Change requests become a negotiation, because every deviation affects the developer’s margin. It can incentivise doing the minimum that satisfies the letter of the specification. And it discourages the conversation where a developer suggests a better approach mid-project, because better usually means different.<\/p>\n

When to choose it.<\/strong>\u00a0Well-defined projects with stable requirements: a theme build<\/a> to an agreed design, a specified integration<\/a>, a migration where discovery has already happened. Also when your organisation requires budget certainty for approval reasons, which is a legitimate constraint even when it costs a little more.<\/p>\n

How to make it work.<\/strong>\u00a0Do discovery first, as a separate paid phase, then fix the price against the resulting specification. This is the single best use of fixed pricing and it removes most of its weaknesses. Also agree the change process before you start, and accept that you will use it.<\/p>\n

<\/span>Hourly<\/span><\/h3>\n

How it works.<\/strong>\u00a0You pay for time spent, usually against an estimate that is not a commitment.<\/p>\n

Where it is strong.<\/strong>\u00a0Flexibility, since you can change direction without renegotiating. No hidden risk premium, so on a project that goes smoothly you pay less than a fixed price would have cost. It suits uncertain work, particularly exploratory or diagnostic tasks where nobody can say in advance what will be needed. And it keeps the developer’s advice honest, because suggesting a different approach costs them nothing.<\/p>\n

Where it fails.<\/strong>\u00a0No budget certainty, which makes approval difficult and can be stressful. You carry all the estimation risk. It requires trust, since you cannot easily verify hours. It can reward inefficiency, though in practice reputation constrains this more than people fear. And it creates friction on small requests, because every small change has a visible cost, which leads to improvements being deferred rather than made.<\/p>\n

When to choose it.<\/strong>\u00a0Diagnostic work where the scope is unknowable in advance \u2014 “our conversion dropped and we do not know why”. Ongoing small changes. Exploratory or experimental work. Situations where you want the flexibility to change direction. And when you have an established relationship with someone you trust.<\/p>\n

How to make it work.<\/strong>\u00a0Agree an estimate with a notification threshold: the developer tells you when they reach a stated percentage of it. Set a cap you must approve exceeding. Ask for itemised time reports rather than a total. And review weekly rather than monthly, so surprises are small.<\/p>\n

<\/span>Retainer<\/span><\/h3>\n

How it works.<\/strong>\u00a0A recurring monthly fee for an agreed allocation of time or scope of service.<\/p>\n

Where it is strong.<\/strong>\u00a0Availability, which is the real product. A retainer means someone knows your store and can act quickly, rather than you joining a queue. Predictable cost, which suits planning. No friction on small work, so improvements actually happen instead of being deferred because they are not worth raising a quote for. Accumulated knowledge of your store, which makes every task faster. And usually a better rate than ad hoc hourly.<\/p>\n

Most importantly, it changes what gets done. Stores on a retainer make dozens of small improvements a year that stores paying per task simply do not, and over time that compounds into a meaningfully better store.<\/p>\n

Where it fails.<\/strong>\u00a0You pay whether or not you use it, and unused hours are often lost. It can drift into a subscription nobody examines. Without a defined scope it becomes ambiguous, and both parties end up dissatisfied. And it is poor value if your needs are only occasional.<\/p>\n

When to choose it.<\/strong>\u00a0Ongoing maintenance and improvement<\/a>, which is what most stores under-buy. Situations where responsiveness matters. Stores with continuous small changes. And as the standing arrangement after a project ends, which is the transition most stores handle badly by either continuing to pay project rates or stopping entirely.<\/p>\n

How to make it work.<\/strong>\u00a0Define what is included and what falls outside. Agree whether hours roll over. Set a notice period that is fair both ways. Review quarterly against what you actually used. And keep a prioritised backlog, because a retainer with no queue of work gets wasted.<\/p>\n

<\/span>The fourth option: hybrid<\/span><\/h3>\n

The arrangement that suits most real projects, and the one least often proposed.<\/p>\n

Paid discovery, then fixed price.<\/strong>\u00a0Discovery is charged hourly or as a small fixed fee, produces a specification, and the build is then fixed-priced against it. This gets you budget certainty where it matters without fixing a price against unknowns. For any substantial project this is usually the right structure.<\/p>\n

Fixed price for the defined core, hourly for the uncertain parts.<\/strong>\u00a0A migration might be fixed for the data, theme, and redirect work, with an hourly allowance for the plugin functionality nobody has fully assessed yet. Honest, and it stops the whole project being priced at the uncertainty of its worst-understood component.<\/p>\n

Fixed price project, then retainer.<\/strong>\u00a0The standard and sensible progression. Build under a fixed price, maintain under a retainer.<\/p>\n

Retainer plus project pricing for larger pieces.<\/strong>\u00a0An ongoing retainer for routine work, with substantial pieces quoted separately so they do not consume the whole allocation.<\/p>\n

<\/span>Side by side<\/span><\/h3>\n
\n\n\n\n\n\n\n\n\n\n\n\n\n
<\/th>\nFixed price<\/th>\nHourly<\/th>\nRetainer<\/th>\n<\/tr>\n<\/thead>\n
Who carries estimation risk<\/td>\nDeveloper<\/td>\nYou<\/td>\nShared<\/td>\n<\/tr>\n
Budget certainty<\/td>\nHigh<\/td>\nLow<\/td>\nHigh<\/td>\n<\/tr>\n
Flexibility to change<\/td>\nLow<\/td>\nHigh<\/td>\nModerate<\/td>\n<\/tr>\n
Requires defined scope<\/td>\nYes<\/td>\nNo<\/td>\nPartly<\/td>\n<\/tr>\n
Hidden risk premium<\/td>\nYes<\/td>\nNo<\/td>\nSometimes<\/td>\n<\/tr>\n
Friction on small tasks<\/td>\nHigh<\/td>\nModerate<\/td>\nVery low<\/td>\n<\/tr>\n
Suits diagnostic work<\/td>\nPoorly<\/td>\nWell<\/td>\nWell<\/td>\n<\/tr>\n
Best for<\/td>\nSpecified projects<\/td>\nUncertain work<\/td>\nOngoing improvement<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

<\/span>A worked example: the fixed price that should not have been<\/span><\/h3>\n

An electronics retailer put a migration out to fixed-price tender. Their brief described the project in general terms and asked for a fixed price, because their finance process required an approved number before work could begin.<\/p>\n

Three developers quoted. Two padded heavily, because the brief did not let them assess the custom pricing logic or the ERP integration. The third quoted low, having assumed both were simpler than they were.<\/p>\n

The client took the low quote. Month two established that the ERP integration used a bespoke middleware layer nobody had documented, and that reproducing their customer-group pricing needed Shopify Plus<\/a> rather than the plan in the quote.<\/p>\n

The developer was now facing significant unpriced work under a fixed price. What followed was four months of change-request disputes, a deteriorating relationship, and a project that finished late and over budget anyway \u2014 because a fixed price only fixes the price if the scope holds.<\/p>\n

The restructure they eventually agreed was what should have happened at the start: a paid discovery phase of three weeks, producing a written specification and a technical approach, followed by a fixed price against that specification. The second fixed price was higher than the original quote and lower than the two padded ones, and the project finished close to it.<\/p>\n

Their finance process had required a number before anyone understood the work. The available options were a padded number, a wrong number, or spending a small amount to produce an accurate one. Discovery was always the cheapest of the three.<\/p>\n

<\/span>How to choose<\/span><\/h3>\n

How well can you specify the work?<\/strong>\u00a0Precisely: fixed price. Vaguely: discovery first, then fixed price. Not at all: hourly.<\/p>\n

How much does budget certainty matter?<\/strong>\u00a0If your approval process requires a number, fixed price after discovery is your structure.<\/p>\n

Is the work ongoing or a project?<\/strong>\u00a0Ongoing points to a retainer, almost always.<\/p>\n

Do you expect to change direction?<\/strong>\u00a0Frequent change and fixed pricing are a bad combination, and it will cost you more in change requests than hourly would have cost in hours.<\/p>\n

Do you trust the supplier yet?<\/strong>\u00a0Hourly requires trust you may not have. A first engagement is often better fixed, or small.<\/p>\n

Is the task diagnostic?<\/strong>\u00a0Never fixed-price a diagnosis. Nobody can quote for finding out what is wrong.<\/p>\n

How much small work do you have?<\/strong>\u00a0If the answer is a steady trickle, a retainer will get more done for less than paying per task, and the difference over a year is larger than people expect.<\/p>\n

<\/span>Getting a retainer right<\/span><\/h3>\n

Retainers are the model most often entered casually and most often wasted, so a few specifics on structuring one well.<\/p>\n

Define what is in and what is out.<\/strong>\u00a0A retainer described as “ongoing support” satisfies nobody. Better: routine changes, app updates and monitoring, small theme adjustments, bug fixes, performance checks, and a stated allocation of improvement work \u2014 with substantial new features quoted separately. Both sides then know when something is a retainer task and when it is a project.<\/p>\n

Decide what happens to unused time.<\/strong>\u00a0Options are that it expires monthly, rolls over for a limited period, or banks indefinitely. Expiry is simplest and encourages use; rollover with a cap is the fairest compromise. Indefinite banking sounds generous and tends to create a large unused liability that eventually causes an awkward conversation.<\/p>\n

Keep a prioritised backlog.<\/strong>\u00a0The single biggest cause of wasted retainers is having no queue of work. When the month starts and nobody has thought about what to do, the allocation goes on whatever happens to break. A standing list of improvements, ranked, means the time goes somewhere useful.<\/p>\n

Agree response expectations, separately from the allocation.<\/strong>\u00a0How quickly does someone acknowledge a problem, and how quickly do they act on something urgent? This is often what you are really buying, and it is distinct from hours.<\/p>\n

Set a fair notice period both ways.<\/strong>\u00a0Thirty days is common and reasonable. Long lock-ins on a maintenance arrangement are a warning sign.<\/p>\n

Review quarterly against actual usage.<\/strong>\u00a0If you consistently use half, reduce it. If you consistently overrun, increase it. A retainer that has not been reviewed in two years is usually wrong in one direction or the other.<\/p>\n

Ask for a monthly summary.<\/strong>\u00a0What was done, what time it took, and what is next on the backlog. This keeps the arrangement visible and prevents it becoming an unexamined subscription.<\/p>\n

Distinguish monitoring from work.<\/strong>\u00a0Some of the value is someone watching \u2014 checking speed, watching for errors, noticing when an app breaks something. That is worth paying for even in a month when little changes, and it should be stated so it does not look like you paid for nothing.<\/p>\n

<\/span>The real cost comparison<\/span><\/h3>\n

A note on how to compare these models honestly, because per-hour rates make it look simpler than it is.<\/p>\n

Fixed price includes work you cannot see.<\/strong>\u00a0Scoping, project management, risk buffer, and the hours the developer absorbed when something took longer than expected. Comparing a fixed price to an hourly rate multiplied by your own guess at the hours is not a comparison.<\/p>\n

Hourly excludes your time.<\/strong>\u00a0Specifying tasks, reviewing work, managing the relationship, and making decisions all cost you hours that do not appear on the invoice. On a poorly specified hourly engagement this can be substantial.<\/p>\n

A retainer’s value is partly in work that would not otherwise happen.<\/strong>\u00a0The genuine comparison is not retainer cost against the same tasks billed hourly. It is the store you have after a year on a retainer against the store you have after a year of deferring small improvements because each one needed a quote. Those are different stores, and the difference does not appear in any pricing comparison.<\/p>\n

All three exclude the cost of doing nothing.<\/strong>\u00a0The most expensive option is usually the one where problems accumulate unaddressed \u2014 apps<\/a> piling up, speed degrading, small bugs becoming normal \u2014 because nobody had an arrangement that made maintenance frictionless.<\/p>\n

\"Four
Pay for discovery, then fix the price against what it produces.<\/figcaption><\/figure>\n

<\/span>The bottom line<\/span><\/h3>\n

No model is fairer; each moves risk somewhere. Fixed price buys certainty and includes a buffer you cannot see. Hourly removes the buffer and gives you the risk. A retainer buys availability and the absence of friction, which is what actually makes stores improve.<\/p>\n

For most substantial projects the right structure is a hybrid: pay for discovery, then fix the price against the specification it produces. That single arrangement resolves the central tension, and its absence is behind most of the fixed-price disputes we see.<\/p>\n

Then move to a retainer once the\u00a0project<\/a>\u00a0is done. The stores that keep getting better are not the ones with the best developers. They are the ones where making a small improvement \u2014 a\u00a0theme adjustment<\/a>, a page fix, a speed tweak \u2014 does not require a quote, an approval, and an invoice.<\/p>\n

<\/span>Frequently asked questions<\/span><\/h3>\n

Is fixed price or hourly better for Shopify development?<\/strong>\u00a0Neither is better in general; they move risk to different parties. Fixed price puts estimation risk on the developer, who prices it into the number as a buffer you cannot see, and it requires a well-defined scope to work. Hourly puts the risk on you, which is why it costs less per unit when things go smoothly. The practical rule: if you can specify the work precisely, fixed price is fine and gives you budget certainty. If you cannot, fixing a price against unknowns produces either a padded quote or a change-request dispute.<\/p>\n

What is the problem with fixed-price development quotes?<\/strong>\u00a0They only fix the price if the scope holds, and on poorly specified projects it does not. The buffer is invisible, so you cannot tell how much you are paying for risk that may never materialise. Change requests become adversarial because every deviation affects the developer’s margin. And it discourages the mid-project conversation where a developer suggests a better approach, since better usually means different. The fix is not avoiding fixed pricing but sequencing it correctly: pay for a discovery phase first, then fix the price against the specification it produces.<\/p>\n

Is a Shopify maintenance retainer worth it?<\/strong>\u00a0For most stores with any ongoing activity, yes, and the reason is not the rate. A retainer removes the friction on small work \u2014 no quote, no approval, no invoice for every minor change \u2014 which means small improvements actually happen instead of being deferred indefinitely. Over a year, stores on a retainer accumulate dozens of fixes and refinements that stores paying per task never make, and that compounds. You also get someone who knows your store, which makes every task faster, and responsiveness when something breaks. Define the scope and keep a prioritised backlog so the allocation gets used.<\/p>\n

Should I ever pay hourly for a whole Shopify project?<\/strong>\u00a0For exploratory or diagnostic work, yes \u2014 nobody can fix a price on finding out why your conversion dropped. For a defined build, hourly leaves you carrying all the estimation risk with no ceiling, which is uncomfortable and hard to get approved. If you do work hourly, agree an estimate with a notification threshold so the developer tells you when they reach a stated percentage of it, set a cap that requires your approval to exceed, ask for itemised time reporting, and review weekly rather than monthly so any surprise is small.<\/p>\n

What is the best pricing structure for a Shopify migration?<\/strong>\u00a0A hybrid, in two stages. Pay for a discovery phase \u2014 typically two to four weeks depending on complexity \u2014 that inventories your apps, integrations, custom business rules, and URL structure, and produces a written specification. Then fix the price for the build against that specification. Where something remains unassessed, such as plugin functionality nobody has fully examined, carve it out as an hourly allowance rather than letting its uncertainty inflate the price of the whole project. Then move to a retainer after launch, which also covers the ninety-day monitoring period.<\/p>\n

How do I stop a fixed-price project turning into a change-request argument?<\/strong>\u00a0Sequence it properly and agree the process before you need it. Run discovery as a separate paid phase so the price is fixed against a written specification rather than against a brief, since most change-request disputes are really disagreements about what the original scope covered. Then agree in advance how changes are raised, how their cost and time impact are assessed, who approves them, and at what rate \u2014 and accept that you will use the process, because you will. Holding a contingency of ten to twenty percent makes the conversation practical rather than confrontational when it arrives.<\/p>\n

Can I switch pricing models partway through a relationship?<\/strong>\u00a0Yes, and most good relationships do. The common progression is a fixed-price project, then a retainer for ongoing work, with larger pieces quoted separately as they arise. Switching is usually easiest at a natural boundary \u2014 after launch, or at the end of a phase \u2014 and it helps to be explicit about why rather than leaving the old arrangement to drift. The transition most stores handle badly is the one straight after a project: they either keep paying project-style rates for small changes that do not warrant them, or stop entirely and let the store slowly degrade.<\/p>\n","protected":false},"excerpt":{"rendered":"

Pricing models are usually discussed as though one is inherently fairer. They are not. Each one moves risk to a different place, and the right choice depends on…<\/p>\n","protected":false},"author":7,"featured_media":4367,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[376],"tags":[],"class_list":["post-4352","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-hiring-working-with-an-agency"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t