Fixed Price vs Time & Materials vs Retainer: Choosing the Right Pricing Model for Your Dev Shop

Fixed Price: Best for Well-Defined Projects

Fixed-price engagements give clients budget certainty and give your dev shop scope discipline. You quote a specific dollar amount for a specific set of deliverables defined in the SOW. If you finish efficiently, your margin improves. If you underestimate, your margin shrinks.

Fixed price works best when: requirements are clearly defined before work starts (detailed user stories, wireframes, or existing system documentation); the technology stack is known and your team has delivered similar systems before; the timeline is short enough (under 20 weeks) that requirement drift is manageable; and the client is organized and decision-making is fast.

Fixed price works poorly when: requirements are exploratory or will evolve significantly during development; the client organization is slow to make decisions or approve deliverables (delays push your hours cost up while revenue stays fixed); or significant third-party integrations exist that you can't fully scope without API documentation you don't have yet.

Fixed price margin protection strategy: include a 15–20% scope contingency buffer in your fixed price. If you estimate 400 hours, quote for 480 hours of internal planning. If the project runs to 480 hours, you're at break-even on contingency. If it runs to 400 hours, you've delivered a 20% gross margin uplift. Explicitly define a change order process in your MSA — any scope addition to the agreed SOW requires a written change order with additional pricing. Enforce this from day one.

Time & Materials: Flexible But Requires Discipline

Time and materials (T&M) pricing bills clients for actual hours worked at agreed hourly rates, plus any direct material costs (hosting, third-party APIs, licenses). There's no fixed end price — the client pays for what gets built.

T&M is appropriate when: requirements genuinely can't be scoped in advance (legacy system modernization where you don't know what you'll find inside the existing codebase); the client wants maximum flexibility to reprioritize features mid-sprint; or the engagement is long-term ongoing development with no clear end point.

T&M risks for dev shops: scope creep is often implicit rather than explicit — clients add features in daily standups without realizing they're expanding the project. Without weekly tracking and client communication about hours burned vs. budget, invoices arrive as surprises and create disputes. Also, T&M exposes your internal efficiency — a senior developer who builds a feature in 4 hours that you estimated for 8 hours gets the client a discount rather than your shop a margin improvement.

T&M best practice: set a monthly budget cap (also called Not-to-Exceed or NTE) and require client approval before exceeding it. Track hours in Harvest daily and send weekly budget burn reports to the client — a simple email or Notion update showing 'Week 3 of 12: 95 of 400 budgeted hours used, on pace.' This eliminates invoice shock and keeps clients informed.

Retainer: The Revenue Stability Model

A monthly retainer is a fixed monthly fee for a defined allocation of development capacity and/or services. The client pays the same amount each month regardless of exact hours delivered; your team provides a consistent level of output within that budget.

Retainers work best for: ongoing product development where the client has a continuous feature backlog; post-launch support and maintenance that requires consistent availability; and fractional CTO or technical advisory services bundled with development hours.

Retainer rate structures: (1) Hours-based retainer: $X/month for Y hours of development, with unused hours expiring (not rolling over). Clear and simple. (2) Capacity-based retainer: $X/month for one dedicated senior developer (Monday–Friday, 8am–4pm your time zone). The client gets a dedicated resource; you provide consistent output without tracking hours. This is the highest-margin retainer model — you bill for dedicated capacity, not tracked hours. (3) Outcome-based retainer: $X/month for delivery of agreed sprint goals (e.g., 2 features per month, defined at sprint planning). The client pays for outcomes, not hours — your incentive is efficiency.

Retainer contract essentials: 30-day notice to terminate (not month-to-month with immediate cancellation), scope definition for what's included (development hours, but not infrastructure costs, security audits, or design work), and a clear change order process for scope additions.

Hybrid Models: Mixing and Matching

The best dev shops don't use a single pricing model — they match the model to the engagement type:

Discovery phase: fixed price ($5,000–$15,000) — always. Discovery has a defined deliverable (the SOW/specification document) and defined timeline.

MVP build: fixed price — for well-specified MVPs where requirements are clear after discovery. T&M with NTE cap — for exploratory builds where discovery uncovered significant ambiguity.

Post-MVP ongoing development: retainer — convert project clients to monthly retainers for continuous product development. This is where the recurring revenue magic happens.

Emergency bug fix / critical support: T&M — fast response situations where scope is by definition unknown ('our checkout is broken, fix it'). Bill a premium hourly rate ($200–$300/hour for emergency response) and document every hour.

Long-term staff augmentation: T&M or capacity-based retainer. If a client wants 'one senior React developer embedded in our team,' a monthly capacity retainer is cleaner than hourly T&M billing.

Transitioning Between Models Within a Client Relationship

The ideal lifecycle of a dev shop client relationship: Discovery (fixed price, $5K–$15K) → MVP Build (fixed price, $25K–$100K) → Post-Launch Retainer ($5K–$10K/month) → Expanded Retainer as product grows ($10K–$20K/month).

This path takes a client from a one-time $50,000 project to $120,000+/year in recurring retainer revenue. The key transition is from the MVP build to the retainer — this must be proposed 4–6 weeks before the MVP launch, not after. Frame it as: 'As you launch to users, you'll need ongoing development for feature improvements based on user feedback, bug fixes, and performance optimization. We can continue as your technical team on a monthly retainer that provides [X] hours of dedicated development. Given what we've built together, this is the most efficient way to accelerate your roadmap.'

Retention rate at 12 months for well-managed retainer clients: typically 70–80% if you're consistently delivering value. At 80% retention with 8 retainer clients at $7,000/month average, you have $672,000/year in baseline recurring revenue before any new project acquisition.

Presenting Pricing Models to Clients

When a client asks 'how do you charge?', resist naming a pricing model first. Instead, say: 'It depends on how well-defined your requirements are and the level of flexibility you want. Let me explain three approaches and we can figure out what fits your situation best.' Then walk through fixed price (budget certainty, defined scope), T&M with NTE cap (maximum flexibility, shared risk), and retainer (ongoing development, monthly cadence). Ask which resonates with how they like to work.

This conversation positions you as consultative rather than transactional. It also gives you intelligence about the client's risk tolerance and budget approach — a client who immediately prefers T&M likely has evolving requirements and an organizational culture comfortable with ambiguity. A client who wants fixed price at all costs values budget predictability and probably has internal financial reporting that requires fixed commitments.

Use Proposify to send the final proposal with whichever model you've agreed on — their proposal templates include payment schedule sections that make milestone billing and retainer structures visually clear.

RECOMMENDED TOOLS

Some links above are affiliate links. We may earn a commission if you sign up — at no extra cost to you.

FREQUENTLY ASKED QUESTIONS