Most software retainers are structured to benefit the agency. A fixed monthly fee, a loose description of “ongoing development and support,” and a relationship that gradually shifts from shipping features to answering questions and attending status calls. If you’ve been on the receiving end of that, you already know how it feels: the invoices keep coming, the roadmap keeps moving, and somewhere around month four you start wondering what you’re actually paying for.
We run retainers differently at Amora, and after doing this long enough, I’m convinced the structure of the agreement matters more than anything else – more than the hourly rate, more than the seniority of the people assigned. Get the structure wrong and you’re paying for availability, not outcomes. Get it right and a retainer becomes one of the most efficient ways a growing product can buy engineering capacity.
This is what we’ve learned from building and maintaining SaaS products on retainer for Australian founders and operators, and what you should demand before you sign.
The Fundamental Problem: Retainers Reward Hours, Not Delivery
Here’s the conflict of interest no one talks about in the sales call. An agency on a time-and-materials retainer profits most when problems take longer to solve. That’s not a moral failing – it’s just the incentive structure. A good engineer can fix a performance bottleneck in two hours; a billing model that charges by the hour creates subtle pressure to document that work as a day’s effort.
The solution isn’t to find an agency with better ethics (although that helps). The solution is to build a retainer structure that aligns the agency’s financial interest with yours. That means output-based accountability baked into the contract itself.
When we scope retainers, the first question we ask a client is: what does “good” look like at the end of each month? If neither party can answer that concretely, the retainer will drift. Guaranteed.
The Three Retainer Models – and Which One Actually Works
There are roughly three models you’ll encounter in the Australian market:
- Pure hours bank. You buy a block of hours each month (say, 40 or 80) and the agency draws against them. Simple to understand, simple to abuse. You have no way of knowing whether a task genuinely took six hours or whether it was logged at six hours because that’s what was left in the bank.
- Scope-based monthly sprint. You agree on a set of deliverables each month – features, bug fixes, infrastructure work – and the fee covers delivery of those items, not hours. Unused capacity rolls over or is forfeited depending on the agreement. This is structurally healthier, but it requires both sides to plan properly, which many clients aren’t set up to do.
- Hybrid: reserved capacity with a delivery cadence. The agency commits a specific number of sprint days per month (not hours – days, because hours are too granular to audit), and each sprint cycle closes with a demo and a written delivery summary. The fee is fixed, but accountability is output-driven. This is the model we prefer and the one I’d recommend any founder push for.
The hybrid model works because it preserves flexibility (you can shift priorities week to week) while still demanding that something ships. A demo at the end of a sprint is a forcing function. It’s very hard to sit in a demo and explain why nothing moved.
What the Contract Needs to Say – Specifically
A software retainer agreement that protects you as a buyer should address five things that most standard agency agreements quietly avoid:
- Deliverable definition per cycle. Not “development work” but a specific list agreed at the start of each sprint – features, integrations, technical debt items, whatever you’ve prioritised. If it’s not written, it didn’t happen.
- Rollover and carry-forward policy. If the agency doesn’t deliver the sprint scope, what happens? A good agreement gives you credit. A bad one doesn’t acknowledge the possibility of underdelivery.
- IP assignment timing. In a retainer, IP should transfer on delivery of each sprint, not at contract end. We’ve seen disputes where a client tried to exit a retainer and the agency claimed ownership of six months of work because the contract was ambiguous. Get this in writing, sprint by sprint.
- Escalation and exit terms. How much notice do you need to give? What happens to in-progress work? What’s the handover obligation? A 30-day exit clause with a mandatory code handover checklist is reasonable. Anything longer than 60 days benefits only the agency.
- Access and observability. You should have read access to the repository, the CI/CD pipeline, and the production monitoring dashboards at all times. Not “we’ll send you a report” – direct access. If an agency resists this, treat it as a red flag.
Pricing: What to Expect in the Australian Market
Retainer pricing in Australia varies significantly depending on the seniority of the team and whether the agency is genuinely onshore. As a rough guide from what we see:
A bare-minimum retainer – one engineer, a few days a month, maintenance and minor features only – will run somewhere between $4,000 and $8,000 per month for legitimate onshore Australian work. A mid-weight retainer covering a part-time product pod (a senior engineer and some design or QA capacity) is typically in the $12,000 to $22,000 per month range. A full product team on retainer – the kind that’s actually building at pace – sits above $25,000 per month.
If you’re being quoted $3,000 a month for “a senior full-stack engineer,” someone offshore is doing that work, regardless of what the contract says. That’s not necessarily fatal – but you deserve to know what you’re buying.
The mistake we see most often is founders buying a cheap retainer when what they actually need is a one-time scoped build. If you have a defined feature set to ship, a fixed-scope project will almost always be cheaper and faster than drip-feeding it through a monthly retainer. Retainers make sense when you genuinely need ongoing iteration – when the product is live, users are giving feedback, and priorities shift month to month. They’re not a good mechanism for building the first version of something.
How to Run the Retainer Once You’re In It
The agency is only half of this equation. We’ve worked on retainers that ran beautifully and ones that turned into messes, and the client’s operating rhythm is the variable that makes the difference more often than the agency’s capability.
What works:
- A single decision-maker on the client side who can approve sprint scope within 24 hours. Not a committee. One person.
- A prioritised backlog that’s maintained by the client, not delegated to the agency. The agency should build what’s on the list, not decide what the list contains.
- A written sprint kickoff – even just a short Slack message or a Notion doc – confirming what’s in scope for the coming weeks. This creates a paper trail and forces both sides to be explicit.
- Monthly retrospectives that are honest. If a sprint underdelivered, say so and agree why. If priorities shifted mid-sprint and that caused the underdelivery, that’s useful information too.
What kills retainers: ad hoc requests that bypass the backlog, unclear ownership of the product roadmap, and the slow creep of “can you just…” conversations that eat sprint capacity without ever appearing on any scope document.
When to Exit a Retainer
Know your exit signal before you start. The retainer has done its job when your product has stabilised to the point where a junior internal hire can handle day-to-day maintenance, or when the volume of work drops below the minimum viable engagement for an agency to staff sensibly. Running a $4,000/month retainer for one or two small tasks a month is expensive compared to hiring a junior dev on contract for those specific tasks.
The other exit trigger is stagnation. If you’ve been on a retainer for six months and you couldn’t clearly describe three meaningful things the product can do now that it couldn’t do then – end it. Retainers can drift into a kind of expensive comfort where both sides are technically honouring the agreement but nothing is really moving. That’s the worst version of this arrangement.
If you’re trying to figure out whether a retainer is the right structure for your next phase – or whether you’d be better off with a scoped build first – talk to Amora about your build and we’ll give you a straight answer, even if that answer is “not yet.”
The best retainers we run feel like having a product team inside the business. The worst ones we’ve heard about from founders who came to us afterwards were just slow-motion budget burns with good-looking invoices. The difference is almost always in how the agreement was structured before anyone wrote a line of code.
Got something you want built?
Amora Digital is an Australian software and AI agency. We scope it, build it, and ship it – live in 28 days. No offshore teams. No surprises.