How to Decide Between a Retainer and Project Engagement

Who This Guide Is For

Business owners and operations managers who are working with (or considering) a development partner and need to decide whether a fixed-scope project engagement or an ongoing retainer is the better model for their needs.

Before You Start

• Neither model is inherently better. The right choice depends on the nature of the work, the predictability of your needs, and your budget structure.
• You can switch between models. Many businesses start with a project engagement and transition to a retainer once the core system is built. Others do the reverse.
• The best engagement model is the one that aligns incentives. Both you and your partner should benefit from the arrangement.

Step 1: Understand Both Models

Project engagement. A defined scope of work with a fixed price and timeline. You pay for a specific deliverable. The engagement ends when the deliverable is complete.

• Best for: well-defined builds, one-off projects, systems with a clear endpoint
• Payment: milestone-based or fixed price
• Scope: defined upfront, changes managed through formal change requests

Retainer. An ongoing allocation of development time. You pay a monthly fee for a guaranteed number of hours or a commitment to response time and availability.

• Best for: ongoing development, maintenance, continuous improvement, unpredictable needs
• Payment: monthly recurring fee
• Scope: flexible, prioritised month-to-month based on current needs

Step 2: Evaluate Your Work Pattern

Look at what you need over the next twelve months:

Project engagement is better if:

• You have a specific system to build with a defined scope
• The work has a clear start and end point
• Your needs are predictable and can be specified upfront
• You do not anticipate needing development work after the project is complete

A retainer is better if:

• You need ongoing development, bug fixes, and improvements
• Your needs change month to month and cannot be fully predicted
• You want priority access to a development team without delay
• You have a live system that requires regular maintenance and updates
• You value a long-term relationship with a team that knows your systems

Step 3: Compare the Economics

Project engagement economics:

• You pay for what you get — a specific deliverable at a specific price
• No ongoing commitment once the project is complete
• Change requests during the project incur additional cost
• Starting new projects requires new scoping, proposals, and ramp-up time

Retainer economics:

• You pay a predictable monthly amount regardless of how much work is needed that month
• Priority access and faster response times (no queuing behind other clients)
• No proposal or scoping overhead for individual tasks
• Unused hours may roll over or may be lost depending on the agreement
• Retainer rates are typically 10-20% lower per hour than project rates because the partner has guaranteed income

Step 4: Consider the Relationship

The engagement model affects the working relationship:

Project engagements are transactional by nature. The partner learns your business for the project, delivers, and moves on. Each new project requires re-learning context. The relationship is episodic.

Retainers build cumulative knowledge. The partner becomes increasingly familiar with your systems, your business, and your preferences. Less time is spent explaining context. The relationship is continuous.

If your software needs are ongoing, the relationship value of a retainer often outweighs the flexibility of project engagements.

Step 5: Decide (or Combine)

Many businesses benefit from a hybrid approach:

1. Start with a project. Build the core system with a defined scope and budget.
2. Transition to a retainer. Once the system is live, move to a retainer for ongoing maintenance, improvements, and new feature development.

This gives you the cost certainty of a project engagement for the initial build and the flexibility of a retainer for ongoing evolution.

Common Mistakes

• Choosing a project when the work is inherently ongoing. If you will need regular development work, a series of small projects is less efficient than a retainer — each one requires scoping, proposals, and context-switching.
• Choosing a retainer when you have a single defined need. If you need one system built and nothing after, a retainer wastes money during months when there is no work.
• Not defining retainer scope clearly. A retainer should specify: hours included, response time commitment, what counts as retainer work vs. out-of-scope work, and how unused hours are handled.
• Staying on a project model out of inertia. If you have been doing project after project with the same partner for two years, a retainer would likely be more efficient for both sides.
• Ignoring the priority benefit. Retainer clients typically get faster response times and priority scheduling. If response time matters, factor this into your decision.

What Good Looks Like

The right engagement model results in predictable costs, appropriate access to development resources, minimal overhead for both sides, and a working relationship that improves over time. Neither party feels trapped, and the model evolves as needs change.

Next Steps

For retainer details, see Support Retainers. For project-based work, Custom Software Development covers how we structure engagements. If you are unsure which model fits, get in touch — we are happy to discuss both options.