The decision between a project engagement and a monthly retainer isn't about which is better - it's about which fits what you're trying to accomplish. Getting this wrong is expensive: an unnecessary retainer costs you money for work you don't need; a project model for ongoing needs creates constant quoting friction and gaps in support.
What a project engagement looks like
A project engagement has a defined scope, a fixed price, a timeline, and a clear deliverable. You're hiring a developer to build something specific: a new Shopify theme, a migration, a product page redesign, a custom integration. When it's delivered, the engagement ends.
Right for:
- One-time builds - new store, theme rebuild, migration from another platform
- Defined features - a specific integration, a custom section, a checkout upsell
- Fixed-price audits - CRO, speed, SEO, UX - where the deliverable is a report and action plan
- Situations where you don't know whether you'll need ongoing development after the project
Advantages: predictable budget, clear scope, no ongoing commitment. You pay for what you need and stop when it's done.
Limitations: if you have ongoing needs after delivery, you're back to scoping and quoting for each new piece of work. Small requests - a quick fix, a section tweak, a new product template - become their own mini-projects. This is fine if your needs are infrequent; it's friction if you need changes weekly.
What a monthly retainer looks like
A retainer is an ongoing monthly engagement where you pay a fixed fee for a defined amount of developer time or a defined set of services each month. The developer is essentially on-call for your store within the agreed scope.
Retainers vary significantly in structure:
Hours-based retainers give you a set number of developer hours per month (e.g., 10 hours) that you can use for any work - fixes, new features, improvements. Unused hours typically don't roll over.
Service-based retainers define what's included rather than how many hours: "monthly theme maintenance, bug fixes, and one new section per month". This is cleaner if your needs are predictable.
A/B testing retainers are a specific type: ongoing experimental development where the developer designs and builds tests, analyses results, and ships winners. This is what the A/B Testing Programme covers.
Right for:
- Stores that regularly need development work - new features, seasonal updates, ongoing optimisation
- Businesses running continuous A/B testing or CRO programmes
- Stores where site maintenance (app updates, theme fixes, content changes) requires developer involvement
- Teams that want a developer available without the overhead of scoping every individual request
Advantages: faster response times, relationship continuity (the developer knows your store deeply), predictable monthly cost, no quoting friction for small requests.
Limitations: ongoing monthly cost regardless of how much work is actually needed in a given month. If your development needs are lumpy - heavy for three months, then nothing for six - a retainer is inefficient.
The questions that determine which fits
How often do you need development work? Weekly or more often: retainer. Monthly: retainer or project depending on complexity. Quarterly or less: project.
Are your needs predictable or variable? If you know you'll need a new landing page every month and ongoing speed optimisation, a retainer scoped to those needs is more efficient than monthly project engagements. If your needs are hard to predict, projects keep you from paying for capacity you're not using.
Do you have a specific project first? Most retainer relationships start with a project. A developer builds your new theme, gets to know your store deeply, and then transitions into a retainer for ongoing work. This is the natural progression - don't start with a retainer before you have an established relationship and a known store to maintain.
What's your budget certainty? Projects give you exact budget certainty per engagement. Retainers give you monthly cost certainty but variable output - some months deliver more value than others.
What to avoid
Retainers without clear scope. A retainer that says "up to 20 hours per month of development" without defining what work is in scope creates ambiguity. Both sides end up frustrated - the client thinks their requests aren't being prioritised, the developer thinks the client's requests are outside scope. Define upfront what types of work the retainer covers.
Projects for genuinely ongoing needs. If your business model requires consistent development - new A/B test variants every two weeks, seasonal collection landing pages monthly, regular product feature additions - treating each one as a separate project creates constant administrative overhead. A retainer is more efficient for both sides.
Retainers with agencies that don't allocate a dedicated developer. With some agencies, a retainer means you go into a queue with other retainer clients and whoever is available picks up your work. The relationship value of a retainer disappears if there's no continuity of developer. When evaluating a retainer, confirm specifically who will be working on your store each month.
