Fixed Price vs Hourly vs Retainer: Pay for Software

Fixed price suits a clear scope, hourly suits unclear work, and a monthly retainer suits maintenance. The real difference is who carries the risk.

I price most of my own work as fixed quotes with milestones, and I run monthly maintenance plans for clients whose servers and apps I look after. I have also taken over projects that went wrong under each model. The model on the contract rarely caused the trouble. The trouble came from picking the wrong model for the kind of work. This guide explains how each one works in practice, what to put in writing, and how to choose.

Key takeaways

• Fixed price moves the estimate risk to the developer. It only works when the scope is written down before work starts.
• Hourly (time and materials) moves the risk to you. It fits research, rescue work and fast-changing products, ideally with a weekly cap.
• A retainer buys availability and a set amount of work each month. It fits maintenance, not building a product from zero.
• Change requests decide whether a fixed-price project stays friendly. Agree how they are priced before you start.
• Pay against working demos, not against dates or percentages of "progress".

How does a fixed-price software project work?

You and the developer agree on a written scope, a total price and a set of milestones. Each milestone ends with something you can click through, and payment for it follows the demo. If the work takes longer than estimated, the developer absorbs the cost. If it takes less, the developer keeps the margin.

The way I run it: a free scope call, then a written feature list with milestones, then a fixed quote. Nothing starts until both of us agree on that list. It is a short document, but every later conversation points back to it.

Good for: MVPs with a clear core flow, websites, migrations, integrations, server setups, anything you can describe as "done when X works".

Watch out for:

• A vague scope with a fixed number on it. "An app like Uber" at a fixed price means someone will be unhappy later. Usually both sides.
• A price far below the others. A low fixed quote often means the developer read the scope differently from you, or plans to make it up with change requests.
• No acceptance criteria. "Done" has to be something you can test, like "a patient can book, pay and get a confirmation SMS".

How does hourly (time and materials) work?

You pay for the hours worked at an agreed rate, usually invoiced weekly or monthly with a log of what was done. There is no total price, only an estimate.

Good for: work you can't scope in advance. Debugging a production problem, taking over unknown code, research spikes, or a product that changes direction every week after user feedback.

Watch out for:

• No cap. Ask for a weekly or monthly maximum. When the cap is close, the developer stops and asks before going on.
• Hours without output. Ask for a short weekly note: what shipped, what is next, what is blocked. Hours with nothing to show for them are an early warning.
• Paying for learning. Some ramp-up on your code is fair. Weeks of learning a framework the developer said they knew is not.

How does a monthly retainer work?

You pay a fixed amount each month for a defined service: a number of hours, a response time, or a list of recurring tasks. On my server maintenance plan the monthly work is a checklist: updates, backup checks, disk, SSL, security patches and a short report. My monthly VPS maintenance checklist shows what that looks like.

Good for: keeping a live product healthy: updates, small fixes, monitoring, a few small features a month, and someone who answers when it breaks.

Watch out for:

• Unused hours. Agree whether they roll over. Usually they don't, and that is fair because the developer kept the time free for you.
• "Unlimited" anything. Unlimited requests for a fixed fee means slow answers or a quiet drop in quality. A clear list is better.
• Big projects inside a retainer. A rewrite squeezed into maintenance hours takes forever. Quote it separately.

Change requests: where fixed-price projects go wrong

Every project gets new ideas halfway through. That is healthy. Friction comes when nobody agreed on what happens next. Put this in the agreement:

1. Anything not on the feature list is a change request, however small it sounds.
2. The developer answers each request in writing (I reply on an issue in the project's GitHub repository): what it changes, the price and the effect on the timeline.
3. Work on it starts only after you approve.
4. Small changes can be swapped for something of similar size you no longer need, at no cost.

The swap rule keeps both sides relaxed. You stay in control of the budget, and the developer isn't pushed into free work.

Which model should you choose?

• You know what "done" looks like: fixed price with milestones.
• You can't describe "done" yet: a short paid discovery or hourly phase first, then fixed price for the build.
• Something is broken and you don't know why: hourly with a cap, or a fixed-price diagnosis. On my emergency fixes, if I can't fix it, you don't pay.
• The product is live and needs care: a monthly retainer with a written task list.
• A big product over many months: mix them. Fixed price per milestone for features, retainer for upkeep.

Payment terms that protect both sides

• Pay per milestone, on a working demo. Not on "50% done", which nobody can measure. Small fixed-scope packages on my site are paid by card through Stripe at checkout; larger projects are paid per milestone.
• You own the code and accounts from day one. Repositories, hosting, domains and app store accounts in your name. My freelancer hiring checklist covers this in detail.
• A warranty period. Bugs in agreed features found soon after delivery are fixed at no cost. Agree on the length.
• Running costs listed separately. Servers, SMS, email, payment fees and store accounts are yours and are not part of the build price. My MVP cost guide lists the usual ones.

Frequently asked questions

Is fixed price or hourly cheaper?

Neither is cheaper by default. A fixed price includes the developer's buffer for the unknown, and hourly passes the unknown to you. For a clear scope, fixed price usually ends up cheaper and always ends up more predictable.

Why do developers add a buffer to fixed-price quotes?

Because they carry the risk if the estimate is wrong. A clear, detailed scope lowers that risk, so the buffer gets smaller. Vague scope is expensive under every model.

What should a software development retainer include?

A list of recurring tasks, a monthly amount of work, a response time for urgent problems, and a short monthly report. It should also say what is not included, such as new features above a certain size.

Should I pay a large deposit up front?

Prefer milestone payments tied to demos. A modest first payment to start the first milestone is normal; paying most of the price before seeing any working software puts all the risk on you.

Can a fixed-price project change scope?

Yes, through change requests. Each one gets a written price and timeline before work starts, or is swapped for a feature of similar size that you no longer need.

Want a fixed quote?

Send me what you want to build or fix. After a free scope call you get a written feature list, milestones and one fixed price, so you know the cost before any work starts. See my web development services or contact me.