TL;DR: Fixed price, hourly and retainer are not three ways to pay for the same thing. They are three ways to split risk. Fixed price works when the scope can be written down and tested against, so the builder carries the risk of being wrong about effort. Hourly works when nobody can honestly write the scope yet, so the client carries that risk in exchange for flexibility. A retainer works when the job is ongoing judgement rather than a deliverable, like a fractional CTO role or keeping live AI agents healthy. Most good projects use more than one: a small paid discovery, a fixed-price build, then a retainer for what comes after launch. I have worked under all three, from fixed-scope Unity jobs on Upwork while I was still at university to ongoing CTO roles at RAQTS, Nystag and Bettershop, so this is the honest version of how I choose.
Founders usually ask "what is your rate?" first, and it is the wrong first question. The rate only means something once you know what shape of engagement it sits inside. A cheap hourly rate on a project with no clear scope can cost more than a generous fixed price on one with a clear scope. The contract model decides who absorbs the surprises, and every software project has surprises.
The real question: who carries the risk?
Every software estimate is a guess with error bars. The contract model decides which side of the table those error bars land on.
- Fixed price: the builder carries the risk on effort. If it takes longer than estimated, that is their problem. The client carries the risk that the scope written down was not what they actually needed.
- Hourly (or daily): the client carries the risk on effort. They pay for the time it takes. In exchange they can change direction any day without renegotiating.
- Retainer: neither side is buying a deliverable. The client is buying availability and judgement over a period, and the builder is committing a slice of their attention.
Once you see it that way, the choice mostly makes itself. The question is not "which is cheapest" but "which risk can each side actually see and price?"
When fixed price works
Fixed price is the right model when you can write the scope as something a stranger could test. Not "an AI receptionist for our clinic" but "an inbound voice agent that answers on this number, books into this calendar, captures these five fields into the CRM, transfers to this extension on these triggers, and sends this summary after every call."
That level of detail is exactly what I try to get to in a discovery call for an AI voice agent. When it exists, fixed price is good for both sides. The client knows the number and can plan around it. The builder is rewarded for being efficient, and these days that matters a lot, because tools like Claude Code on client projects make some kinds of work dramatically faster. On an hourly contract, that speed-up mostly shows up as a smaller invoice. On a fixed price, it pays for the extra care that makes the result solid.
Fixed price goes wrong in three predictable ways:
- The scope is vague and both sides pretend it is not. The builder pads the estimate to cover the unknowns, or does not pad it and then quietly cuts corners when the unknowns arrive.
- "Done" is not defined. Without acceptance criteria, the last ten percent of the project turns into an argument about whether something is a bug or a new feature.
- The change process is missing. Requirements always move. A fixed-price contract needs a sentence that says how changes get priced, or every change becomes a negotiation.
My early freelancing was mostly fixed-scope Unity work: small projects first, then real ones for clients in Australia and the US. The lesson I took from that period, which I wrote about in freelancing from Pakistan for US clients, was that the projects that went well were not the ones with the best price. They were the ones where we had both written down what finished looked like before anyone started.
When hourly works
Hourly is the honest model when the scope genuinely cannot be written yet. That is more common than people admit:
- Inheriting someone else's codebase. Until somebody has read it, nobody knows if the feature you want is a day or a rewrite. My first-week audit of an inherited codebase exists precisely because that week has to happen before any fixed quote means anything.
- Research-shaped work. AR tracking in a new environment, headset performance on a device you have not profiled, a hardware integration with sparse documentation. At ARCortex and Nystag a lot of the hard problems were of this kind: you find out what the work is by doing the first part of it.
- Fast-moving early products. If the founder is still discovering what the product is, a fixed scope locks in a guess. Paying for time keeps the ability to change your mind cheap.
Hourly goes wrong when nobody is watching the burn. The fix is simple and boring: a weekly summary of hours against what was delivered, a cap that requires a conversation before it is crossed, and short milestones so the client can stop at any point and still own something useful. If a builder resists all three, that tells you something.
The other failure is quieter. Hourly contracts can reward slowness, or at least fail to reward speed. A good hourly relationship depends on trust in a way a fixed price does not, which is why I think hourly fits best once a working relationship already exists.
When a retainer works
A retainer is for work that is not a project. The output is decisions, availability and steady care, not a deliverable with a finish line.
The clearest example in my own work is the fractional CTO role. At RAQTS, Nystag and Bettershop the job was never "build feature X." It was owning the technical direction, reviewing what the team shipped, making the architecture calls, managing releases, and being reachable when something important broke. I wrote about how that works in practice in being a fractional CTO for three startups. You cannot write a fixed scope for "make the right call when it comes up," and billing that hourly makes founders hesitate to ask the very questions they hired you to answer.
The second example is live AI systems. A voice agent is not finished when it goes live. The first two weeks after launch surface caller behaviour nobody predicted, models and platforms change underneath you, and the client's business changes too: new services, new hours, new staff to transfer to. That ongoing care fits a retainer far better than a stream of tiny change requests.
Retainers go wrong when they turn into a fixed fee for unlimited work, or a fee for nothing. Both are fixed by naming what the retainer covers (response time, number of review sessions, the systems in scope) and what sits outside it and gets scoped separately.
The hybrid I recommend most often
For a typical new build, the structure I suggest to clients looks like this:
1. A small paid discovery
A short, fixed-price phase to turn an idea into a written scope: requirements, integrations, edge cases, acceptance criteria, and an estimate for the build. For an inherited codebase, this is the audit. The client walks away with a document they own, whether or not they continue with me.
2. A fixed-price build against that scope
Now the scope is real, so a fixed price is honest. It comes with a change clause: anything new gets a short written estimate before work starts, and the client decides whether it goes into this phase or the next. If you want a feel for typical durations, how long it takes to build an AI voice agent gives realistic ranges, and what an AI receptionist actually costs breaks down the ongoing platform costs that sit on top of the build.
3. A retainer, or a clean handover
After launch the client chooses. Either a retainer covering monitoring, updates and a set amount of improvement work, or a proper handover of the system to their own team, with documentation, credentials and ownership of every account. Both are legitimate. What is not legitimate is a project that ends with the client unable to change anything without the original builder.
Questions to ask before you sign anything
Whatever model you choose, these questions protect you:
- What exactly is in scope, and how will we test it? If the answer is a paragraph rather than a list, the project is not ready for a fixed price.
- How are changes priced? There should be a clear, written process, not goodwill.
- Who owns the code, the accounts and the credentials? The answer should be "you, from day one": repository, cloud, app stores, voice platform, CRM. I gave the same advice in how to hire a Unity developer, and it applies to every kind of software.
- What happens after launch? Bug fixes for a period, a retainer option, or a handover. Decide before the build, not after.
- How will I see progress? Working builds or call recordings on a regular rhythm beat status reports.
The short version
Pick the model that matches what can honestly be known. Fixed price when the scope is testable. Hourly when it is not yet, with caps and weekly visibility. A retainer when the job is judgement and ongoing care. For most new products, combine them: pay for discovery, fix the price of the build, then decide between a retainer and a handover. The rate matters far less than getting the shape right.
I build AI voice agents, software and products for founders, and I take on fractional CTO roles for teams that need technical direction without a full-time hire. If you are trying to work out how to structure a project, more about my background here, or book a call and we can figure out which shape fits.