The project shipped.
Now build the income that keeps arriving.

Purpose & audience

Most software people can build, and many can now sell and get paid. Far fewer ever plan the step that turns a run of projects into a business with a floor under it.

The companion guides in this library take a project from a vague idea, through a defensible estimate and a signed deal, to money safely in your account. This one picks up after delivery and answers the question that decides whether you are running a business or just running on a treadmill: once the work is delivered, what keeps the revenue coming? It covers the support relationship, the maintenance discipline, the retainer that smooths your cash flow, and the harder judgment of which custom work is general enough to become a product other people will pay for again and again.

It is written for independent developers, small software firms, and anyone who has delivered good work and then watched the income go quiet until the next project lands. Everything here is generic and reusable — no company or product specifics — and applies whether you build for Windows, the web, or mobile, and whether you are supporting a brand-new application or a system that has been in production for twenty years.

The core principle

The delivery guide argues you cannot price what you have not defined. The Getting Paid guide extends that to the contract and the payment schedule. This guide adds the next link in the chain: a delivered project is not the end of a relationship, it is the start of one — and the value of that relationship is decided by how deliberately you structure what comes after handover.

Two failure modes recur throughout. The first is giving away the ongoing work — treating support, fixes, and "small changes" as free goodwill until you are running an unpaid help desk on top of your paid projects. The second is productizing too early or too eagerly — turning one client's peculiar requirements into a "product" that fits no one else and drowns you in support. Almost every section below is an antidote to one of those two mistakes.

Where this sits in the library

This guide begins where the others end — at a delivered, accepted, paid-for project. It picks up threads deliberately left hanging elsewhere: the warranty-versus-support boundary first drawn in Getting Paid & Protecting Yourself, and the retainer introduced there as "the natural bridge into ongoing income." Read it alongside the Custom Software Delivery Guide (which defines the work you will now support) and Getting Paid (which sets the contractual terms this ongoing work sits on top of). Its own natural sequel is the exit — how a business built on recurring revenue is valued and sold — but that is a later guide.

There is a ladder that runs from the least predictable income a software business can have to the most. Knowing which rung you are on — and which one is next — is most of the strategy.

Why lumpy project income is a trap

Pure project work has a structural flaw that no amount of skill fixes: the revenue stops the moment the work stops. Every project is a standing start. You sell it, deliver it, get paid, and then face an empty pipeline and the full cost of winning the next one. Cash flow lurches between feast and famine. Worse, the busiest weeks — heads-down in delivery — are exactly when no selling happens, which guarantees the famine that follows the feast.

This is not an argument against project work; project work is often where the largest single checks and the deepest client relationships begin. It is an argument against only project work. The goal is not to abandon projects but to make each one deposit something durable: a support agreement, a retainer, a maintenance contract — a reason for money to keep arriving after the invoice is paid.

The four rungs

Most software income sits on one of four rungs, in rising order of predictability. A healthy business is usually climbing — deliberately moving weight from the lower rungs to the higher ones over time.

The rungs are cumulative, not exclusive. A mature small software firm typically earns on all four at once: it still takes projects, it warranties them, it converts a good share into support retainers, and a slice of what it has learned to build repeatedly has become a product. The lower rungs feed the higher ones — projects reveal what is worth supporting, and support reveals what is worth productizing.

MRR, ARR & how you're valued

The move up the ladder is not only about smoother cash flow; it changes the arithmetic of what your business is worth. Project revenue is valued cautiously because it must be re-won every year. Recurring revenue — income contracted to arrive month after month — is valued far more highly, because a buyer or a bank can count on it.

You do not need a finance function to use these. Even a spreadsheet that separates "arrives every month whether or not I sell anything" from "had to be won this month" will tell you, at a glance, how much floor you have built. The rest of this guide is about widening that first column.

The line between a free warranty and a paid support relationship is where the ladder's second rung meets its third. Draw it clearly and support becomes a business; leave it blurred and you run a help desk for free.

Drawing the line

A warranty is a bounded, free promise: for a defined period after acceptance, you will fix genuine defects — the software failing to do what the accepted specification said it would — at no charge. Support is a paid, ongoing service: help, changes, enhancements, environment updates, questions, and everything that is not a defect in the originally delivered scope. This is the same distinction the Getting Paid guide draws in its contract; here it becomes the hinge of your recurring revenue.

The confusion between the two is not accidental — clients have every incentive to route new requests through the warranty as "bugs" and expect them free. If you have not drawn the line explicitly, every enhancement, every "while you're in there," every new report becomes a warranty claim, and the warranty period never really ends. The fix is not to be stingy; it is to be clear, in writing, before the work is delivered.

Time-boxed, scope-boxed, condition-boxed

A defensible warranty is bounded on three axes at once. Miss any one of them and it quietly becomes unlimited free work.

• Time-boxed — it ends. A defined number of days or weeks after acceptance, not "until the client is happy."
• Scope-boxed — it covers defects against the accepted specification, not new wishes, new features, or changes to requirements that emerged after delivery.
• Condition-boxed — it does not cover problems the client caused: their own changes to the code, a new operating environment, altered data, or third-party components you did not supply.

The handoff to a support sale

The end of the warranty period is the single best moment to sell support, and most builders let it pass in silence. The client is live, dependent on the software, and about to lose their free safety net — which is precisely when an ongoing arrangement is easiest to justify. Plan the conversation before the warranty ends, not after something breaks.

Framed this way, support is not an upsell bolted onto a finished job; it is the natural continuation of a relationship the client already values. The warranty was the free trial. Support is the subscription — and Part 04 is about pricing it so both sides find it fair.

A support contract is a promise about the future made concrete: what you will respond to, how fast, through which door, and for how much. The clearer the promise, the more a client will pay for it — and the less it will cost you to keep.

What an SLA actually promises

A Service Level Agreement (SLA) is the part of a support contract that sets measurable expectations. Its job is to be specific where a handshake is vague. A good SLA names a few things precisely: the hours of cover (business hours in which time zone, or around the clock), the channels through which issues may be raised, the severity levels and what each one means, and — the number everyone fixates on — the response time for each severity.

Severity levels

Severity levels let one word do a lot of work: they tell both sides how serious an issue is and therefore how fast you will move. Define them in the contract so "urgent" means the same thing to you and the client. A simple, widely understood scheme:

Notice that P4 quietly absorbs a category that is not really support at all — enhancements and new requests. Keeping those visible as their own severity, scheduled rather than fixed, stops them from masquerading as urgent defects and reminds both sides they are billable work.

What to include vs. bill hourly

The most important design decision in a support contract is the boundary between what the fee covers and what is billed on top. Draw it too generously and the plan loses money on your busiest clients; draw it too meanly and clients feel nickel-and-dimed. A workable pattern is to include the predictable, low-variance work in the fee and to bill the open-ended work separately.

• Usually included: defect triage and fixes for issues in delivered scope, a defined block of support hours or tickets, minor advice and questions, keeping the system running.
• Usually billed on top (or drawn from a separate allowance): new features and enhancements, significant changes to requirements, work caused by the client's own changes, large data migrations, and anything that is really a small project wearing a support costume.

Whatever split you choose, write it down and apply it consistently. The support contract, like the delivery contract before it, works only if nothing about money is ever a surprise to either party.

Ticketing discipline

Support that arrives through five different channels — a text here, an email there, a phone call at the weekend — is impossible to price, prioritize, or defend. The single most valuable operational habit in a support business is one channel, everything logged. Every request enters through an agreed door (an email address, a form, a simple ticketing tool), gets recorded, and is assigned a severity.

A retainer is the instrument that turns support from a series of invoices into a monthly floor. It is the clearest single step most project shops can take toward recurring revenue — and the one most often left on the table.

Retainer mechanics

A retainer is a recurring fee — monthly is common — in exchange for an agreed block of availability, hours, or a defined scope of support. As the Getting Paid guide notes, it converts the feast-and-famine of one-off projects into something you can plan around. The mechanics are simple but must be explicit, because vague retainers become arguments and specific ones become dependable revenue.

• Billed in advance. You are paid at the start of the period for the availability you are reserving, not at the end for hours already spent. This is the whole point — it is what makes the income predictable.
• Rollover, stated plainly. Decide what happens to unused hours: do they roll into next month, and for how long, or expire? Silence here breeds resentment on both sides.
• Overage, agreed up front. When a month's work exceeds the retainer, the excess is billed at an agreed overage rate the client already knows about.

A retainer is not only selling hours — it is selling reserved availability. The client is paying for the certainty that when they need you, you are contracted to be there. Pricing that reflects the reservation, not just the hours consumed, is what makes retainers sustainable (see below).

Tiered support

Offering a single support plan forces every client into one shape and leaves money on both ends — the light user overpays and leaves, the heavy user underpays and drains you. A small number of tiers lets clients self-select and gives you a natural upgrade path. Three is usually enough.

Pricing a retainer

The instinct is to price a retainer as a bundle of hours at your hourly rate. That undersells it, because it ignores the thing the client is really buying: reserved capacity. You are holding availability open for them whether or not they use it, and forgoing the ability to fully commit that time elsewhere. A retainer priced purely on expected hours consumed loses money in the quiet months it was supposed to smooth.

None of this is a substitute for professional or legal advice on how you structure and tax recurring income in your jurisdiction — but the underlying principle travels everywhere: charge for the availability you reserve, not only for the work you happen to perform.

Support answers the phone when something breaks. Maintenance is the quieter work that stops so much from breaking in the first place — and it is a service you should sell, not a cost you should silently absorb.

Preventive vs. reactive

Reactive maintenance is what most people picture: something fails, a ticket is raised, you fix it. Preventive maintenance is the work that keeps failures from happening — applying security and dependency updates, renewing certificates, checking that backups actually restore, watching disk and performance headroom, and keeping the software current with the platforms it runs on. Reactive work is unavoidable; preventive work is what separates a system that ages gracefully from one that lurches from crisis to crisis.

Software is not a bridge that, once built, simply stands. It sits on a moving foundation — operating systems change, libraries are deprecated, security vulnerabilities are discovered, browsers and devices update. A system that receives no preventive maintenance is not stable; it is quietly accumulating risk that will surface all at once, usually at the worst possible time.

Technical debt & the maintenance budget

Technical debt is the accumulated cost of shortcuts, deferred upgrades, and "we'll clean that up later" — and like financial debt, it charges interest. Every deferred update makes the next one harder; every worked-around quirk makes the next change riskier. Maintenance is how you service that debt before it compounds into a rewrite.

The practical move is to make maintenance a planned line, not an emergency. Reserve a share of the ongoing budget — in the retainer, or as a defined maintenance contract — for keeping the system healthy: updates applied on a schedule, dependencies reviewed, a little debt paid down each cycle. A client who funds steady maintenance pays a predictable, modest amount forever. A client who defers it pays nothing for a while and then a large, alarming amount all at once. Your job is to make the first path the obvious one.

Sell it, don't absorb it

Sold well, maintenance is one of the easiest recurring-revenue lines to justify, because the alternative — a system left to rot until it fails — is one every client instinctively wants to avoid. Framed as insurance against the large, sudden bill, a modest recurring maintenance fee is an easy yes. Framed as a cost you quietly eat, it is money you will never see.

This is the top rung of the ladder and the hardest step: recognizing that something you keep building for individual clients could be built once and sold to many — and knowing which somethings actually qualify.

Recognizing the generalizable

Not all custom work can become a product, and trying to productize the wrong work is a fast way to waste a year. The signal to watch for is repetition across clients. When you find yourself building substantially the same thing for the third different client — the same kind of report, the same integration, the same workflow with the names changed — you are looking at a candidate. The value is not in any one build; it is in the fact that the underlying need is shared.

The productization spectrum

Productizing is not a single leap from "services" to "SaaS." It is a spectrum, and moving one step along it is often enough to change your economics without betting the business.

The steps rise in reward and in risk together. A template you reuse across projects improves your margins with almost no downside. A full subscription product is a different business, with its own demands on marketing, support, and cash. Move deliberately, and only as far as the evidence of repeated demand justifies.

Pricing recurring revenue

Once work becomes a product sold repeatedly, pricing shifts from "what did this cost me to build" to "what is it worth to each customer, month after month." The common recurring models each fit different products:

Whichever you choose, the recurring nature changes the psychology: customers are re-deciding to pay you every period, so the product must keep delivering visible value, not just have delivered it once at sign-up.

Churn: the metric that decides everything

Recurring revenue only compounds if customers stay. Churn — the rate at which customers cancel — is the leak in the bucket, and it decides whether pouring in new customers actually raises the water level. A product with high churn is not a recurring-revenue business; it is a project business with extra steps, endlessly re-selling to replace the customers walking out the back door.

This is also why the earlier rungs matter so much to the top one: strong support, honest maintenance, and a product built from genuinely repeated demand are exactly what keep churn low. The discipline that makes support profitable is the same discipline that makes a product durable.

Climbing the ladder is not free. The move from project income toward recurring revenue has three predictable hazards — and each one has sunk businesses that got the strategy right but the transition wrong.

Protecting cash flow during the shift

The awkward truth about recurring revenue is that it starts small. A project might bring a large check next month; the retainer or subscription that replaces it brings a fraction of that, spread across many months. The arithmetic is better in the long run and worse in the short run — and businesses die of short-run cash problems, not long-run ones.

The safe path is to build the recurring layer on top of a still-running project business, not instead of it. Keep taking projects while you convert delivered ones into support and maintenance, and let the recurring base grow under you until it is large enough to lean on. Treat the transition as a gradual shift of weight from one foot to the other, never a jump.

Not alienating your existing base

If you already sell software on a one-time basis — a perpetual license, a bought-and-owned build — moving to a subscription model is not just a pricing change; it can feel to loyal customers like being asked to pay again for something they already own. Handled clumsily, it turns your best advocates into your loudest critics.

The support-load trap

Recurring revenue has a hidden cost that project revenue does not: every new recurring customer is a permanent support obligation. Ten one-off projects, once delivered and warrantied out, eventually go quiet. Ten support or subscription customers never go quiet — they accumulate. Grow the recurring base faster than you grow the capacity to support it, and you reach a point where every hour is spent keeping existing customers alive and none is left to build or sell.

Everything above, compressed into things you can run: a tier sheet you can put in front of a client, a test for whether an idea is ready to productize, and the vocabulary to talk about recurring revenue with confidence.

A support tier sheet you can adapt

A simple, honest tier sheet does most of the selling for you — it lets the client choose their own level of cover and makes the upgrade path obvious. Fill in the specifics you can genuinely honour; an SLA you cannot meet is worse than none.

The “is it ready to productize?” checklist

Run a candidate through this before you commit real time to turning custom work into a product. A "no" is not necessarily fatal, but it is a prompt to slow down — never a thing to sail past on enthusiasm alone.

Glossary