After delivery: support, recurring revenue, and the second project

The final milestone is invoiced, the system is live, the client's team sends a warm message, and then the account goes quiet. Twelve weeks later a message arrives at nine in the evening: something is broken, and it has apparently been broken for several days. Nobody was watching, because nobody had been made responsible for watching. The silence and the late-night message are the same failure, and it began on the day the project was declared finished.

The cheapest client a software company will ever acquire is the one it already has. The sentence is repeated often enough to have lost its edge, so restate it as arithmetic. Winning a new client of similar size costs months of outbound, several proposals, a procurement cycle and usually a discount at the end of it. Winning the second project inside an existing account costs one well-prepared conversation. Most companies still spend their effort on the first and leave the second to chance.

The handover is an acquisition moment

At handover you hold three things you will never hold with a stranger: live access to the client's systems, the trust that comes from having delivered, and a detailed picture of how the business actually runs. You know which department was left out of scope. You know that the finance team still assembles one report by hand every month. You know that two branches send their stock counts by phone. None of this is available in a first meeting with a new prospect, and most of it evaporates within a year if it is not written down.

So write it down before you leave. A short internal note listing what you saw and did not build — three to six items, each with the department it belongs to and a rough sense of the work involved — is the most commercially useful document a project produces. It is the agenda for the next two years of that account.

Support belongs in a contract, not in favours

Support given as a favour is worse for both sides than support priced honestly. The client feels awkward asking, then asks anyway at nine in the evening, because the alternative is a stopped operation. Your team fixes it between other commitments, unbilled, and quietly resents it. Within a year one side stops answering, and the relationship ends without either party deciding to end it.

A support agreement replaces goodwill with terms. At minimum it names the systems and environments covered, who on the client side may open a ticket, the hours of coverage, response commitments by severity, what happens to hosting, backups, certificates and monitoring, and how a change request is separated from a fault.

Exclusions matter as much as inclusions. State plainly that the agreement does not cover new modules or redesigns, systems you did not build, data entry and cleanup, training beyond an agreed number of sessions, or outages inside a third party — a payment gateway, a courier API, the tax authority's e-invoicing service — where your obligation is to diagnose, notify and work around rather than to repair someone else's platform.

Two pricing shapes work in practice. The first is a percentage of build value, commonly between fifteen and twenty-five per cent a year depending on coverage hours, billed monthly. For a build of 600,000 EGP that is roughly 7,500 EGP to 12,500 EGP a month. The second is a flat monthly figure derived from expected load, which is easier for a client to defend in a budget. Either shape can include a small pool of hours for minor changes, eight or sixteen a month, with anything larger estimated separately; the pool also creates a monthly reason to talk.

Whichever shape you choose, the figure has to be defensible in a month where nothing breaks. You are paid for readiness, monitoring and continuity, not per incident. If that cannot be said plainly in a proposal, the number is wrong — the same discipline that governs pricing, estimates and the proposal that gets signed governs support. At Softwiro the support terms are written before the build starts, because a system delivered onto infrastructure nobody administers is not finished.

What recurring revenue buys inside the company

Recurring revenue is usually described as smoothing cash flow. That understates what it does. A base of support agreements covers a predictable share of payroll before a single new contract is signed, and what that buys is not comfort.

Recurring revenue is mainly the ability to decline a project you already know will go badly.

Every software company recognises the shape of the project it should refuse: undefined scope at a fixed price, a buyer who negotiated discovery away, a prototype budget attached to production expectations. Companies take those projects anyway, in the month when payroll is close and the pipeline is thin. Each one costs more than it pays and consumes the senior people who would otherwise be delivering well. A support base makes a "no" affordable in a bad month, which is the only time the answer matters.

It also changes staffing. Engineers who know a system well are worth keeping between projects, and retainers justify keeping them rather than rebuilding the knowledge from scratch on the next engagement. Over a few years that is the difference between a company with institutional memory and one that starts every project from zero.

Growing inside the account

Growth inside an account moves in three directions, and they are not equally easy. Deeper means the same system gains what was deliberately left out of the first scope: a second warehouse, a returns flow, approvals by role. Sideways means another department — the commerce platform was built for sales, while finance still reconciles by hand. Outward means integrations: accounting packages, payment gateways, courier APIs, and in Egypt the e-invoicing and e-receipt obligations that arrive with deadlines the client did not set.

Sequencing matters more than enthusiasm. Do not propose the second system while the first is still unstable; give it sixty to ninety quiet days, where quiet means measured rather than assumed. Once the first system has stopped generating incidents, the list you wrote at handover becomes the agenda, and you are proposing from a position no competitor has.

Second projects inside a known account estimate far more accurately than first projects, because the data model, the deployment path and the people are already understood. That accuracy is not a reason to discount; price the second system on what it does for the client, not on how familiar it feels to you.

Presence without pestering, and the referral you ask for

Pestering is a monthly message asking whether anything new has come up. Presence is arriving with something the client did not have. A scheduled review of the system's own numbers is a legitimate reason to be in the room — quarterly for most accounts, monthly for large operations. Bring uptime and incidents since the last review, transaction or order volume, the five slowest operations, error rates, the three things support was asked about most, and any change in the client's own figures that the system can see.

Bring the numbers, not a pitch. In practice the review produces the next proposal by itself: a manager sees that one operation takes eleven steps, or that half the orders are still entered manually, and asks what it would take to fix. That question is worth more than any outbound sequence, and it arrived because a meeting was in the calendar.

Referrals work the same way. A satisfied client will refer, but rarely without being asked, and almost never in response to a broad request. "Do you know anyone who needs software" produces nothing. "Who else runs a distribution business your size and complains about stock counts" produces a name. Ask at a defined moment — after a good review, after a milestone the client is pleased with — and make acting on it trivial: a short introduction you have already drafted, and something forwardable that describes the work in terms the recipient recognises. Making delivered work legible to outsiders is its own discipline, covered in turning delivered work into proof.

The early shape of churn

Accounts rarely announce their departure. They fade, and the signals appear months before a renewal date.

• Usage falls. Fewer logins, fewer orders passing through the system, one branch quietly back on a spreadsheet.
• Tickets stop. Silence is not satisfaction; more often it means the client has routed around you.
• Replies slow. Someone who answered within an hour now takes two weeks.
• The champion leaves, is promoted, or moves department. This is the most reliable predictor of all.
• Invoices are paid later than they were. Finance signals before anyone says anything.
• A new IT manager arrives, or the phrase "we are reviewing our vendors" appears.

Act on the signal, not on the renewal date. When usage falls, ask directly what changed; often the process changed and the system no longer fits it, which is a project rather than a loss. When the champion leaves, request a meeting with their successor within two weeks and present the system from the beginning: what it does, what it replaced, what it costs to run, what breaks if it stops. Institutional memory does not transfer in a handover email, and a successor who does not understand why the system exists will one day be asked to justify its cost and will have no answer. Several of these signals also appear during delivery, where they mean something similar — see early signs a software project is going wrong.

What compounds over years

Consider a company with ten delivered systems under support at between 8,000 EGP and 15,000 EGP a month each. That base covers a small team's payroll floor before a single new project is signed. It is never the headline number in a proposal, but it changes every decision about which work to accept.

Then the second-order effects arrive. Retained accounts produce second systems, which are estimated more accurately and delivered with better margin. Reviews produce proposals. Referrals produce clients who arrive pre-convinced and negotiate less. After three to five years of this, the account list rather than the outbound list is the main source of revenue, and outbound becomes something you do to choose your next sector rather than to make the month work.

If you have a system that was delivered and then left running with nobody responsible for it, we can scope what operating it properly would involve. If the next step is a second system rather than a support agreement, the same conversation covers that.