You're about to buy custom software. Somewhere on the agency's website is a pricing model. There are two main flavors:
Fixed-price project. "We'll build X for $Y by date Z." One contract. One number. One end date.
Monthly retainer. "We're your software team for $X/month, with a 60-day initial commit, then cancel any time." Ongoing relationship. Predictable monthly spend. Indefinite end date.
Both are valid. Both are sold confidently. They are not interchangeable, and choosing the wrong one for your situation is one of the most expensive mistakes you can make in custom software.
This post is the decision tree. Read all the way through; the right answer for your project depends on five questions, not one.
The short answer
Before the long one, here's the short version:
- Fixed-price wins when: scope is small, well-defined, one-time, and the software won't change much after launch. Example: a one-page marketing site, a one-time data migration, a fixed-scope landing page A/B test framework.
- Retainer wins when: the software is going to keep evolving. Which, honestly, is most cases — because most custom software exists to run a business, and businesses change.
If you read no further, default to retainer. Fixed-price is the exception, not the rule, for any software that's actually load-bearing for an operating business.
Now the long version, because the choice deserves more than a default.
The five questions
These are the five questions you can answer about your project today that determine which model fits.
Question 1: Is the scope genuinely fixed?
A genuinely fixed scope is a scope where the answer to "what should we build?" is the same on day 1, day 30, and day 90.
For most custom software, that scope does not exist. The day you start clicking around a real prototype, you'll change three opinions about the data model. The day your customers see it, you'll change three more. The day you start using it in production, ops will surface five edge cases you didn't know about.
A fixed-price contract treats scope change as an exception to be negotiated separately. A retainer treats scope change as the work itself.
If you can write down everything the software needs to do today and you're confident that list won't change — fixed-price is honest. If you suspect (or know) the list will change — fixed-price is dishonest, no matter how confidently anyone signs the contract.
The most common failure mode of fixed-price projects is the change order. The contract is for $40K. The first scope clarification adds $5K. The second adds $8K. By month three, the "$40K project" is at $62K and growing, the relationship is adversarial because every conversation feels like a renegotiation, and you've spent more than the retainer would have cost and gotten less.
Question 2: Will the software still need work after launch?
Most software is not done at launch. It is launched, then iterated on, in many cases for years. Bugs surface in production that didn't show up in QA. Users ask for the feature they didn't realize they wanted until they tried v1. Integrations need updating when partners change their APIs.
If your software is going to keep evolving — which most operating-business software is — then a fixed-price project just defers the question. You'll ship v1, then need v1.5, and v1.5 either becomes a second fixed-price contract (which has its own scope-creep dynamics), or you bring on a retainer team to maintain and extend.
The retainer model treats the entire arc — v1, v1.5, v2, maintenance, the surprise integration request — as one continuous thing. The total cost over 18 months is often lower than a series of fixed-price contracts adding up to the same outcome.
Question 3: How much will the cost of delay hurt you?
Fixed-price contracts have a date. If the date is missed, the contract has provisions: maybe a discount, maybe an extension, maybe a refund. None of those provisions actually give you working software on the date you needed it.
If your software needs to be live by a specific date because of an external dependency — a regulation, a tradeshow, a contract — fixed-price gives you a number to point at, but doesn't actually deliver the date. Retainer doesn't promise a date either, but it gives you weekly visibility into what's actually shipping, so you find out about slip in week three instead of week eleven.
The relevant question is: when something slips, how do you want to find out? Fixed-price gives you a status email at milestone delivery. Retainer gives you a Friday demo where you can see for yourself.
Question 4: How much do you trust the vendor?
Fixed-price contracts are a form of risk transfer. You're saying: "We agree on the scope, you take on the risk of delivering it for the price quoted." This works only if the vendor (a) actually has the capacity to deliver, (b) doesn't get squeezed into a worse-than-expected outcome that destroys their incentive halfway through, and (c) is around to honor the warranty if something breaks.
When trust is low — first engagement, unknown vendor, large stakes — fixed-price feels safer because the dollar amount is bounded. In practice, the bounded number creates the squeeze that makes the relationship adversarial. Trust gets harder still when the vendor is in another country and another legal system — offshore vs. onshore walks through where that trade-off actually breaks.
Retainer requires more upfront trust. The trust is built by the structure: a 60-day commit (long enough to see real work, short enough to bail), weekly demos (you see progress before you pay the next invoice), source-code ownership from day one (you can take everything with you if you cancel), no-questions cancellation after the commit. The structure substitutes for blind trust.
Question 5: Will you have an in-house team eventually?
If your endgame is an in-house engineering team — you're a venture-funded startup, you're planning a specific exit, you want to own the team — then a fixed-price project to get to v1 and then hand off to internal hires can make sense. Before you commit to that path, it's worth knowing what a real in-house software team actually costs in 2026. You're explicitly not buying an ongoing relationship; you're buying a starting line.
If your endgame is "we will always need a software team but never want to hire one in-house" — and that's most operator-owners — retainer is what you want. You're buying continuity. You're not buying a project.
The decision in one table
| If… | Use fixed-price | Use retainer |
|---|---|---|
| Scope is genuinely fixed | Yes | Overkill |
| Software will keep evolving | No | Yes |
| You need a specific live date with consequences | It promises one (doesn't deliver one) | It gives you weekly visibility |
| You don't trust the vendor yet | Bounded $ feels safer but creates squeeze | 60-day commit + weekly demos build trust |
| You plan to hire in-house eventually | Good for v1 + handoff | Wrong shape for the goal |
| You want predictable monthly opex | No | Yes |
| The work is one-time and commodity | Yes | No |
The middle case: phased fixed-price
A few vendors sell what looks like a hybrid: "fixed-price per phase," where you sign a contract for v1, then a separate one for v1.5, then a separate one for v2.
This is a fixed-price contract with extra steps. Each phase has its own scope creep. The seams between phases generate handoff inefficiency. By the time you've done four phases, you've signed four contracts, paid four legal-review fees, and re-negotiated four price points.
The math is usually worse than retainer over the same period. If you find yourself drafting phase 4, switch to retainer — you're already in a retainer relationship, you're just paying more for it through the contract overhead.
What a real retainer looks like
A good monthly retainer has these properties:
- A monthly fee, not an hourly rate. Hourly rates create the same adversarial dynamic as fixed-price ("did this conversation count as billable?"). Monthly fees make capacity predictable.
- A defined initial commitment, then month-to-month. 60 days is the right initial window: long enough to actually ship something, short enough that you can bail without taking a bath. After that, month-to-month cancellation is the only retainer structure I'd accept.
- Source-code ownership from day one. Your code lives in your GitHub, on day one of the engagement. If the relationship ends, you walk away with everything. Anything else is vendor lock.
- Hard concurrency caps on what's in flight. A retainer without concurrency limits degrades into infinite customer support. Look for a tier structure where each tier names the maximum number of concurrent initiatives.
- Weekly shipping, not monthly check-ins. A retainer should produce visible weekly output — code merged, features shipped, deploys made. If the monthly invoice arrives and you can't point to specific things that happened that month, that's a problem.
What a real fixed-price looks like
When fixed-price is the right choice, look for these properties:
- Scope written down in detail, signed by both sides. Not "we'll build a CRM." Specific user stories, specific screens, specific accepted edge cases.
- A change-order process you both agree on before signing. Hourly rate for additions, written estimate for each change, your approval before work starts on the change.
- A defined acceptance test. What does "done" mean, in terms a non-engineer can verify? Don't sign without this.
- A maintenance plan for after launch. Even fixed-price work needs someone to fix bugs after launch. Write that into the contract, or know exactly who's going to do it.
- Source-code ownership on completion. Same as the retainer rule. Anything else is lock-in.
The honest summary
Fixed-price feels safer to buyers because the number is bounded. In practice, for any software that's load-bearing on an operating business, fixed-price contracts get more expensive and more adversarial as scope inevitably shifts, while delivering less than a retainer would have. The "bounded number" comes with hidden change-order growth that often exceeds the original price.
Retainer feels riskier upfront because the meter is running every month. In practice, for software that's going to keep evolving, the retainer relationship produces more value per dollar, more predictably, with a healthier client-vendor dynamic. The 60-day initial commit and the month-to-month cancellation cap your downside; the weekly demos give you the visibility a fixed-price contract pretends to.
Most operator-owners belong on retainer. If you don't think you do, walk through the five questions again and be honest about your answers — particularly the one about whether the software will keep evolving. It almost always will.
If you want to walk through which model fits your specific project, book a 30-minute call. Or, if you want to see how our retainer is structured before that conversation, the pricing page and the process page lay out the mechanics in detail.