Why We Replaced Hourly Retainers with Four Clear Engineering Rules
This article explains why our engineering team moved away from hourly retainers and adopted four clear engineering rules instead. You’ll learn the background, how the rules work, what problems they solve, and how to decide if a similar approach fits your team. The change improved predictability, alignment, and trust with clients.
Background: The Problem with Hourly Retainers
Hourly retainers have been a standard in consulting and agency work for decades. A client pays a fixed amount per month, and the team tracks hours against that budget. The model sounds simple, but it creates several structural problems:
- Incentive misalignment: The provider earns more by working more, not by delivering value faster. This can lead to padded hours or slow progress.
- Client anxiety: Clients often wonder if they are getting their money’s worth. They may micromanage time or demand detailed timesheets.
- Scope ambiguity: Without clear boundaries, small requests expand into large projects, eating the retainer and causing friction.
- Unpredictable delivery: Hours spent do not equal output. A task that takes 10 hours for one engineer might take 3 for another, making timelines unreliable.
Many teams try to fix these issues with better tracking or more communication, but the root cause remains: the unit of value is time, not outcome. We wanted a model that focused on what actually matters to the client—getting working software—while still protecting the team from endless scope creep.
How the Four Rules Work
Instead of billing or budgeting by hours, we defined four engineering rules that govern every request. These rules are not about time; they are about boundaries, clarity, and quality. Here is each rule and why it exists:
- Rule 1: One request at a time. The client can submit one defined task. The team works on it until it is done or until a blocker arises. This prevents context switching and ensures focused effort.
- Rule 2: Tasks must be small and testable. A request must be broken into pieces that can be completed in a few days and verified. If a request is too large, the team helps split it into smaller deliverables.
- Rule 3: Definition of done is explicit. Before work starts, both sides agree on what “done� means—what code changes, what tests pass, what documentation exists, and how the client will verify it.
- Rule 4: Scope changes are renegotiated. If the client adds requirements mid-task, the team pauses and renegotiates the deliverable. The original task is not expanded silently.
These rules are simple, but they change the conversation. Instead of “How many hours did you spend?� the question becomes “Did you deliver the agreed outcome?� The team is accountable for output, and the client is accountable for clear, stable requirements.
Why These Rules Specifically?
We chose these four rules because they address the most common failure points we observed in hourly retainers:
- Rule 1 eliminates multitasking. Multitasking reduces quality and increases completion time. By limiting work in progress, the team finishes tasks faster and with fewer errors.
- Rule 2 forces decomposition. Large, vague requests are the main source of scope creep. Breaking them down makes estimation and verification possible.
- Rule 3 creates shared understanding. Many disputes arise because the client expects one thing and the team delivers another. An explicit definition of done prevents that.
- Rule 4 makes scope changes visible. Instead of silently absorbing extra work, the team surfaces it. The client then decides whether to pay extra or drop the addition.
These rules are not arbitrary; they are direct responses to the incentives that hourly billing creates. They shift the focus from effort to outcome, which is what both parties actually want.
What Changed in Practice
Adopting the rules required changes in both team behavior and client communication. Here is what we observed after implementation:
- Fewer status meetings. Because each task has a clear definition of done, the team does not need daily check-ins. Clients get updates when a task is complete or blocked.
- More upfront planning. Before starting any task, the team and client spend time breaking it down and agreeing on the definition. This upfront investment saves hours later.
- Clearer priorities. With one request at a time, the client must decide what matters most. This forces them to prioritize instead of expecting everything simultaneously.
- Better trust. Clients see tangible results regularly. They no longer wonder if the team is “working enough� because they see completed, testable deliverables.
One concrete example: a client previously used a 40-hour monthly retainer for ongoing website maintenance. They would send a list of small fixes, but the list grew during the month, and the team often ran out of hours before finishing. Under the new rules, the client submits one task at a time, each with a clear definition of done. The team finishes that task, then the client submits the next. The result is that every task is completed, and the client knows exactly what they paid for.
Common Problems and How to Avoid Them
No model is perfect, and the four rules come with their own challenges. Here are common issues and practical mitigations:
- Problem: The client submits a huge task. Mitigation: Rule 2 requires breaking it down. The team helps the client split it into smaller pieces, each with its own definition of done.
- Problem: The definition of done is ambiguous. Mitigation: The team writes it down in a shared document. If the client disagrees later, they can point to the written agreement.
- Problem: The client changes their mind mid-task. Mitigation: Rule 4 triggers a renegotiation. The team pauses, explains the impact, and lets the client decide whether to proceed with the original or the changed scope.
- Problem: The team finishes early and the client has no next task. Mitigation: This is a positive sign of efficiency. The client pays for the completed task, not for unused time. They can submit a new task or end the engagement.
The key is to enforce the rules consistently. If exceptions are made too often, the model reverts to hourly thinking.
How to Choose Between Hourly and Rule-Based
Not every project or client is a good fit for the four rules. Here is a practical guide:
- Choose hourly retainers when: The work is highly exploratory, requirements change daily, or the client values access to a team over specific deliverables. For example, a research project where the path is unknown.
- Choose rule-based retainers when: The work is well-defined, repeatable, or can be broken into discrete tasks. For example, ongoing bug fixes, feature development, or content updates.
- Consider a hybrid: Some teams use hourly for discovery and rule-based for execution. This allows flexibility during the learning phase and predictability during delivery.
Our team chose rule-based because most of our work is feature development and maintenance—tasks that can be clearly specified. For a different type of work, hourly might still be the better choice.
Costs and Value: What You Actually Pay For
Under the four rules, the client pays for a deliverable, not for time. The cost is agreed per task, based on the complexity and estimated effort. This has several financial implications:
- Predictable budgeting: The client knows the cost of each task before it starts. There are no surprises at the end of the month.
- Efficiency is rewarded: If the team completes a task faster than estimated, the client pays the agreed price, not less. This incentivizes the team to be efficient without worrying about losing income.
- No “use it or lose it� pressure: Under hourly retainers, clients sometimes feel they must use all their hours. Under rule-based, they only pay for what they need.
However, the client must be willing to invest time in defining tasks clearly. The upfront planning is a cost that is not directly billed but is essential for the model to work.
Frequently Asked Questions
What if a task takes longer than expected?
The agreed price stays the same. The team absorbs the extra time, which is a risk they take to win the work. If the task is genuinely larger than expected, the team can ask to renegotiate under Rule 4, but only if the scope changed, not if the estimate was wrong.
How do you estimate the cost of a task without hours?
We still estimate hours internally to set a price, but we do not bill by them. The price is a fixed fee based on the complexity and the team’s past experience. The client sees only the fixed price, not the internal estimate.
What happens if the client submits a task that is too vague?
We send it back and ask for more detail. We work with the client to break it down into testable pieces and define what “done� means. If we cannot define it, we do not start.
Can the client submit multiple tasks in parallel?
No, Rule 1 says one at a time. This is intentional to avoid context switching. If the client wants parallel work, they can purchase a second retainer or a dedicated team, but that is outside this model.
Is this model only for software engineering?
No, the principles apply to any knowledge work where tasks can be defined and verified. Marketing, design, writing, and consulting can all use similar rules. The key is that the work must be decomposable into discrete deliverables.
What if the client is not happy with the deliverable?
The definition of done is the contract. If the deliverable meets that definition, the task is complete. If the client wants changes, that is a new task under Rule 4. This protects both sides from endless revisions.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.