Helm

How do freelance web developers build recurring revenue?

A one-off project payment on one side and a repeating monthly income stream on the other
The same clients, arranged differently.

The short answer

By selling the things a client needs every month rather than the build they need once — hosting, maintenance, content updates and reporting. The fastest route is to stop giving away small edits free and package them, and the most durable is to hand clients a dashboard so they self-serve the trivial changes while you keep the retainer for work that needs you.

On this page

The problem with project work

You finish a site, invoice it, and your income for that client returns to zero. Every January starts empty. Every quiet month is genuinely quiet, and you are always selling.

Meanwhile the same client emails you four times a year asking for small changes, which you either do free — because they are small — or bill awkwardly at a rate that makes both of you uncomfortable for twenty minutes of work.

That email is the recurring revenue. It is just not packaged.

The four things that recur

Hosting. The most common starting point and the least interesting. Real margin exists but it is thin, and you have taken on responsibility for uptime. Worth doing as part of something larger, rarely worth doing alone.

Maintenance. Updates, backups, security, the plugin that broke. Genuine ongoing work with genuine value, and easy to explain: things break, someone has to notice.

Content updates. The emails you already answer. Packaging them removes the awkward conversation and turns an interruption into revenue.

Reporting. A short monthly note on what the site did. Cheap for you to produce, and it is the thing that makes the whole retainer feel worth paying, because it is the only part the client sees every month.

The trap

The obvious package is "unlimited small changes for a monthly fee". It sells easily and it is where most freelancers start.

It goes wrong in a specific way: your best clients — the ones whose business is growing — send the most requests, so your most valuable relationships become your least profitable hours. And you cannot raise the price without it looking like a penalty for their success.

Cap it, or price by response time rather than by volume, or move the trivial changes off your desk entirely.

Moving the trivial changes off your desk

This is the version that scales, and it is counterintuitive: give the client the ability to make small edits themselves.

The instinct is that this removes your recurring revenue. In practice it removes the unprofitable part of it. Nobody enjoys the twenty-minute price change, including you, and it is not what a client is happy paying a professional rate for.

What is left is work that genuinely needs you — new pages, integrations, design changes, the thing that broke, advice. That is defensible at a real rate, and the client is more satisfied because the small stuff stopped waiting on your inbox.

The practical requirement is a site with a content layer the client can safely use. Either you build that, or you build on something that already has it.

What to charge

Two structures work.

A retainer — a fixed monthly fee covering a defined scope, with anything outside quoted separately. Predictable for both sides, and the scope definition is the whole job.

A care plan in tiers — hosting and monitoring at the bottom, adding maintenance, then content work, then strategy. Easier to sell because the client picks their own level, and easier to grow because upgrading is a small decision rather than a renegotiation.

Either way, put what is not included in writing. Nearly every retainer that turns sour does so over an unstated boundary rather than a price.

Starting from where you are

You do not need new clients for this. Go through the ones you have and count the small requests from the last year. That number is your first pitch, and it is a factual one: here is what you asked me for, here is what it would have cost as a plan, here is what you get on top.

The version where you do not build the platform

The arithmetic above assumes you are providing the plan yourself, which means you are also providing the hosting, the uptime, the backups and the phone call at 3am. That is a real business, and it is a different one from designing websites.

The alternative is to introduce the client to a platform that does the running, and take a share of it. Helm Partners is that arrangement: you bring the client, Helm builds or attaches the site and runs it, the client gets a dashboard with their branding — Helm's name never appears in front of them — and you are paid a one-off share of the build plus a share of the subscription for a set number of months.

The terms are written into your own agreement rather than published as a rate card, so treat any specific number you read anywhere as somebody else's deal. Payouts run in your own currency, Whish and OMT included, which is not a detail if you are billing from Lebanon.

You do not have to be a developer to be a partner, and most are not. The portal is partners.usehelm.host: a pipeline for clients you are tracking, an earnings view with downloadable statements, and a submission flow that takes a repo link if you have already built the site.

Which route is right depends on the count you did in the previous section. If the small requests are frequent and the clients are yours, a plan you run is more profitable. If you would rather stop owning infrastructure, this is the trade.