Ongoing support
An application runs a real part of your business and no longer has anyone assigned to it. A monthly retainer puts a named engineer on it, one who already knows the system, so that a change request or an outage does not start with a stranger reading code.
Hire or retain
When the person who maintained a .NET application leaves, the default reaction is to backfill the role. Sometimes that is right. It is worth costing out honestly before committing, because the comparison is rarely as close as it looks.
| Mid-level .NET hire | 20-hour retainer | |
|---|---|---|
| Monthly cost | ~$14,600 fully loaded ~$135k salary plus tax, benefits, equipment |
$3,600 |
| Up-front cost | Recruiting fee, typically 20 to 25% of salary | Fixed-fee assessment |
| Time to productive | 6 to 9 months on an undocumented system | Immediately after the assessment |
| Availability | Every day | Business hours, within the hour block |
| If they leave | You are back where you started | Documentation stays with you |
| Knowledge risk | One person holds the context again | Written record built as work is done |
The honest counter-argument is the availability row. An employee is there every day and a retainer is not. If the application changes constantly, needs someone embedded with the business, or generates more than about forty hours of work a month on an ongoing basis, hire. A retainer is the better answer when the system is stable, changes arrive in bursts, and what you need is for someone competent to already understand it when something happens.
What it costs
Retainers are a block of hours per month at a rate below standard hourly. Month to month, thirty days notice, no term commitment.
| Hours / month | Monthly | Fits |
|---|---|---|
| 10 | $1,900 | Security patches, dependency updates, small changes and a known point of contact when something breaks. A stable application that needs to stay healthy rather than move. |
| 20 | $3,600 | The above plus a steady flow of small feature work and integration changes. The most common tier for a system still actively used and occasionally adjusted. |
| 40 | $7,000 | Roughly a day a week. A modernization track running alongside maintenance, or several connected systems under one arrangement. |
Unused hours expire at the end of the month. That is deliberate on both sides: it keeps the monthly figure honest rather than turning it into a savings account, and it means capacity is genuinely reserved for you rather than notionally owed. Work beyond the retainer is billed at the standard hourly rate, and you are told before that happens, not after.
Tiers can be changed or cancelled with thirty days notice. There is no term contract, because a retainer that has to be enforced by a contract is not one worth having.
What the hours cover
Keeping it running
Security patching, framework and dependency updates, certificate and credential renewals before they lapse, monitoring that reports a failed job or a broken sync before a user does, and investigation when something behaves unexpectedly.
Changing it safely
Small features, report changes, integration adjustments when a system on the other end changes its API, and the schema and data work those require. The value of a retainer over ad hoc work is that none of this starts with rediscovering how the system fits together.
Knowing what you have
Documentation accumulates as work is done rather than as a separate project: deployment steps, integration behavior, business logic sitting in stored procedures, scheduled task ordering. If the arrangement ends, that record stays with you. The point of the engagement is not to make you dependent on it.
What it does not cover
A full migration, a rewrite, or a large new build is a project with its own scope and price, not something to absorb into a retainer. Where one is warranted, it gets quoted separately and the retainer continues alongside it. Twenty-four seven paging is also outside this arrangement; response is during business hours unless something different is agreed in writing.
How it starts
A retainer on an unfamiliar system begins with an assessment, because paying for support from someone who does not yet understand what they are supporting is paying for reading time. The assessment establishes what is running in production, what the database contains, what the external dependencies are and how deployment actually works. It is fixed fee, it is a standalone document, and plenty of clients take it and stop there.
Where a rescue or migration engagement has already happened, the retainer follows on from it directly and no separate assessment is needed.
Tell me what needs covering
What the application does, roughly how old it is, and who supports it now. That is usually enough to say which tier fits and whether an assessment is needed first.
Get in touch