A custom software build does not end on launch day. It ends — if it ever ends — somewhere in year three, when the product has either become load-bearing infrastructure or has been quietly replaced by something else. Almost everything that decides which of those two endings you get happens in the twenty-four months after the build phase, and most of it runs on a retainer.
Software retainer agreements are also where the trust between buyer and studio gets cashed in. The build phase is largely a planning exercise — discovery, design, scope, milestones, sign-off. The retainer phase is open-ended. The work is harder to spec in advance, the buyer's leverage is lower because the system is already live and rewriting partner is expensive, and the contract is the only thing that protects either side from a slow drift into resentment.
This post is the version of a retainer we work to ourselves, and the version we wish more first-time buyers were offered when they finish a build. It is biased toward Indian SMB and startup contexts — companies in the INR 5 crore to INR 200 crore range buying their first or second piece of custom software — but the structural points hold elsewhere.
What most retainers actually deliver — and don't
Three shapes dominate the market, and each has a specific failure mode.
The first is the hour block. The studio sells you forty hours a month, you submit tickets, the meter runs. This sounds fair and it is the model most often pitched to buyers who want to feel in control of cost. In practice, hour-block retainers spend the first half of every month arguing about which work was a bug (free under the existing scope) and which was a change request (consumes hours), and the buyer ends up too cautious to use the retainer for anything except outages.
The second is the all-inclusive SLA, lifted from the SaaS-vendor playbook. The studio promises uptime, security patching, "minor enhancements", and a support inbox. The number is round and the contract is short. What goes wrong is that "minor" is undefined, so almost every real change becomes "out of scope", and the retainer quietly drains to one engineer occasionally checking that the system is still up.
The third is the handshake. There is no retainer at all — the studio agrees to "support" the product, with the implicit assumption that the buyer will pay hourly when work comes up. This works exactly long enough for the studio to take on its next build, after which the handshake stops returning calls.
None of these is dishonest in isolation. They each fail because they avoid the harder questions: what counts as included work, who responds in what time frame, how a small change moves through the system, and what the buyer can show their partners at the end of the month.
The six jobs of an honest post-launch retainer
A retainer that earns its monthly fee does six distinct things. A retainer that is doing fewer than four of them is underpriced trouble.
One — keep the lights on. Security patches, dependency upgrades, certificate renewals, backup verification, the boring infrastructure work that nobody notices when it is done and everybody notices when it is missed. Under the DPDP Act 2023, reasonable security safeguards for any system handling personal data are now statutory, not optional. The retainer should commit to a patching cadence and a written log.
Two — fix bugs the build phase could not have caught. Real users do things real test plans never imagined, and real data has shapes no fixture file replicates. The first sixty days post-launch are when the long tail of these surfaces. The retainer is what stands between that tail and the user experience.
Three — answer the small-change inbox without billing per email. Tweak the invoice template. Add a new dropdown option. Move a column on a report. These are change requests in the strict sense, but billing each one as a discrete project creates so much friction that buyers stop asking. The honest version of a retainer absorbs a steady flow of small changes inside the monthly fee, and pulls bigger ones into a written change-request flow.
Four — run the next round of improvements without a new SOW. Most products grow incrementally for the first year — a feature here, an integration there. The retainer should be able to absorb a phase of two-to-four-week enhancements without the buyer having to renegotiate a contract every time.
Five — be reachable, with named humans. A Slack or WhatsApp channel with the engineer who actually worked on the code, not a generic support inbox staffed by people reading from a runbook. Two named people on the studio side, an SLA on response time, and an escalation path when the named people are unavailable.
Six — be auditable. A written monthly readout the buyer can hand to a partner, a board, or a finance team — what was done, what is queued, what is open, hours used vs hours allocated. The readout is the artifact that makes the retainer a real piece of infrastructure instead of a recurring invoice nobody wants to defend.
The studios that build retainer practices that last across multiple clients do all six. The ones that don't, lose retainers within twelve months — sometimes because the client churns, sometimes because the studio quietly defaults on half the list.
Bug vs change request: the line that decides the contract
This is the single most consequential clause in a retainer, and most retainers fudge it.
The clean definition is: a bug is a divergence between the system's behaviour and the agreed scope. A change request is a request for behaviour the scope does not cover. Both definitions reference the same document — usually the build-phase scope, plus any subsequent CRs that have been signed off — and both sides agree, in writing, that this is the document of record.
Without this anchor, "bug" becomes whatever the buyer thinks is broken and "change request" becomes whatever the studio thinks is new work, and you end up litigating on email. The honest version names the document, names the person on each side who approves CRs, and includes a simple matrix: under four hours of work, classified as a small change and absorbed; four to twenty hours, written CR, scheduled inside the retainer if capacity allows; more than twenty hours, separate fixed-price proposal.
The same logic applies to integrations breaking because a third party changed their API, data migrations needed for new business processes, and performance issues that emerge as data volume grows. None of these are clean bugs in the strict sense, but all of them are work the system needs. Where they sit in the retainer should be written, not negotiated case by case.
Three retainer shapes — light, standard, embedded
Most retainers we have run, including the ones our clients now operate on, fall into one of three shapes.
Light retainer — keep-the-lights-on plus a small monthly hour bank. Suitable for stable systems with low rate of change, typically INR 20,000 to 35,000 per month for a build in the 10-25 lakh range. Buyer expectation should be calibrated: this retainer is not building new features, it is keeping the system safe and responsive when small things go wrong.
Standard retainer — six jobs, all six, with a monthly hour guideline in the 20 to 40 range. Suitable for live products in their first or second year, where the rate of change is still meaningful. Pricing usually 12 to 20 percent of build cost annualised, which for a 15-25 lakh build means INR 35,000 to 75,000 per month. This is the shape most growing companies should start with at launch and downshift to a light retainer once the product stabilises.
Embedded retainer — dedicated capacity. The studio assigns one or two engineers part-time or full-time to the product, plus a project lead managing scope and cadence. Priced on capacity, not on output, usually INR 1.5 to 4 lakh per month depending on seniority and split. Suitable when the next phase of work is large enough that a fixed-price phase-two contract would be the alternative, and the buyer prefers continuous capacity over discrete project blocks. We move clients into this shape only when their roadmap genuinely justifies it; an embedded retainer with insufficient roadmap becomes a body shop.
Picking the wrong shape is the most common retainer mistake. Buyers default to standard because it sounds responsible, then either bleed cost on a stable system that needed a light retainer, or strangle a product that needed embedded capacity to actually grow.
Pricing, and when not to start a retainer
The pricing rule of thumb is straightforward: take the build cost, divide by twelve, multiply by 0.6 to 1.0 for the first year depending on system complexity. For a 20 lakh build, that lands around INR 1 to 2 lakh per month of plausible retainer spend if the system needed continuous work — but the same build might only need INR 40,000 per month if it is stable and the roadmap is light. The honest conversation is which of those two ends your product sits closer to, and the answer is rarely "we don't know" if both sides have been paying attention during the build.
There are two cases where you should not start a retainer at all. The first is when the product has clearly not reached usable v1 — a retainer is not a way to finish a build, and treating it as one corrupts both contracts. Finish the build under the fixed-price contract, then start the retainer. The second is when the buyer has internal engineering capacity that the studio's retainer would duplicate. In that case the relationship should shift to a clean handover, with the studio available for paid advisory but not for monthly billing.
A retainer is post-launch infrastructure. It is the cheapest and most boring part of the relationship when it works, and the most expensive failure mode in custom software when it does not. The contract is the thing that decides which one you get.
If you are coming out of a build and trying to figure out what the right post-launch shape looks like, our retainer service is built around the six jobs above — fixed monthly fee, written scope, named humans, monthly readout, month-to-month. The Iyer & Joshi cockpit case study and Halverson Chambers matter management rebuild both moved onto standard retainers at handover; the shape and price tracked the rule of thumb above. For the build-phase commercial model that this retainer sits on top of, see our note on fixed-scope, fixed-price engagements. When you are ready to talk about your specific setup, start here.