In this guide 6 sections
A retainer suits software the business cannot stop using, because response time and cover are agreed in writing, while pay per fix suits stable software that rarely breaks. A salaried developer suits weekly change. Many owners combine a retainer and projects.
What you are really buying with each model
Availability is what a retainer buys: a fixed monthly fee, a named response time, a list of covered tasks and a person who has already read your code. Idle months cost the same. That is the trade.
Pay per fix buys a single outcome: something breaks, you raise a request, and the vendor bills by the hour until the fault is closed and tested. Quiet months cost nothing. A bad month hurts.
A salaried developer buys attention, because one person sits inside your business, hears about problems in the corridor and can change a label on the dispatch screen before lunch.
Predictability and response time
Budget shows the gap first. Under a retainer, maintenance becomes a line in the monthly accounts, while hourly work lands as a surprise invoice after a failed payment gateway or an expired SSL certificate.
Response time is the second difference: a written service level might promise a reply within an hour for a stopped system and within a day for a cosmetic fault. Hourly vendors answer when a gap opens.
An employee answers instantly, but only in office hours, and your warehouse may start scanning at six in the morning, long before a nine to five developer arrives. That window is uncovered.
- Retainer: fixed monthly fee, agreed reply times, covered task list
- Pay per fix: variable invoices, best effort reply, quote before work
- Own developer: salary plus tools, instant reply in office hours only
- Check who answers a failed overnight batch job in each case
Who holds the knowledge, and what happens on leave
Knowledge is the hidden cost. An hourly vendor may meet your code only when it fails, so every fix begins with an hour of reading before anyone touches the fault.
A retainer vendor keeps a running picture of your database tables, cron jobs, third party keys and the quirks of last year’s upgrade, so diagnosis starts at once.
A single in house developer holds everything in one head, so a fortnight of leave or a resignation leaves the system with no owner at all. Ask where the deployment steps, environment variables and hosting logins are written down, since anything held only in one head cannot be handed to a stranger on short notice. Vendors cover leave by swapping people. A good one still needs notes, so insist on a handover file, a repository you control and admin rights in your own name.
Who builds the small improvements
Every working system collects a wish list: a new column on the invoice export, a filter on the stock report, a second approver on purchase orders. None is urgent. Together they weigh heavily.
Most retainers include a few hours of small changes each month, which clears the list steadily without a new quote every time. Pay per fix handles the list only if you remember to ask and accept a fresh quote each time, so wishes tend to sit for months.
An in house developer handles it best because a request costs them nothing to raise, and the person who asks can walk over and watch the change. Large builds are different. A new module or a mobile app needs its own scoped project with wireframes, milestones and a price, whichever maintenance model you chose.
- Write the wish list down in one shared sheet
- Agree whether small changes count inside the retainer
- Set a size above which work becomes a separate quote
- Review the list every quarter and drop what nobody misses
Which model fits which situation
Choose a retainer when a stopped system halts billing, dispatch or production and nobody inside can read the code, because every hour of delay costs orders. Choose pay per fix when the software is small, stable and used by few people, so a failure costs a day of annoyance and nothing more. Choose a salaried developer when you ship changes every week and already have a technical lead who can set priorities and review the work.
The mixed model is common. A small retainer covers monitoring, backups, security patching and urgent faults, while projects such as a new report or a courier integration are priced separately.
This week, list your last twelve months of faults and changes, mark which stopped work, and bring that sheet to every vendor conversation.
Maintenance model comparison sheet
This comparison sheet gives a column each to a retainer, pay per fix and an in house developer, with a final row for your score from one to five. The other rows cover monthly cost range, reply time for a stopped system, who holds the repository and logins, leave cover, small change allowance and exit terms.
Open a blank worksheet to printQuestions owners ask
Is a retainer wasted money in a quiet month?
Not entirely. The fee pays for monitoring, patching, backup checks and a person who knows your system, and it earns its keep on the day something stops.
Can I switch from pay per fix to a retainer later?
Yes, and many owners switch after an outage, usually starting with a short trial term so both sides can test the reply times. Before signing, ask for a written list of what the retainer covers, what is quoted separately and how unused hours are treated at month end.
What should a retainer contract spell out?
Reply and fix times by severity, covered systems, hours for small changes, reporting, handover duties and notice period belong in writing with the escalation contact. Say who owns the code, the hosting account and the domain, because that decides whether you can leave cleanly when the relationship ends.
When does hiring a developer make more sense than a vendor?
When changes arrive every week, the product is central to your business and someone technical can set priorities and review the work. Without that lead, a lone hire drifts.