Recurring revenue
The typical work of software agencies, consultants, and freelancers is project-based. You win the project, provide the service, and receive the agreed payment. But project work can be feast or famine, and a large cause of stress within agencies.
Your pipeline can be full, but then some projects get delayed or fall through. You can have zero work scheduled, but then within a week you have triple the amount you can handle. This makes forecasting difficult, and results in very lumpy payment schedules.
Recurring revenue brings reliability to your bank balance and longer-term scheduling. It can help shed the limiting mindset of “project-based work”, and get you (and your client) thinking more of a long term partnership.
What is recurring revenue? 👩💻
Recurring revenue is income you receive from a client after recurring time, e.g. monthly. This is different to project payments which generally occur after a certain delivery or milestone is complete.
Some recurring revenue streams such as retainers and maintenance contracts rely on you completing a set amount of work in a specific period. But others, such as ongoing support, are payments that take place irrespective of whether any support work took place within the period.
Below I run through some of the more common forms of recurring revenue I implemented within my agency. I also mention a couple of types that may be common, but I never implemented, and why.
Ongoing support ☎️
“Just remember that when nobody was there for you, I was. And when nobody else gave a damn, I did.” – Drake
Software isn’t as easy as “build it and forget it”. Bugs happen, third-party APIs change, and customers have unexpected urgent requests.
A ongoing support agreement is a contract between you and your client outlining how you will providing future support services for them.
You agree to terms such as:
- Your availability to support their system in a certain timeframe - e.g. Monday to Friday, 9am to 6pm.
- Your response time and medium for any issues they report - e.g. get back to them within 4 hours after reporting an issue, contact via email.
- Your rectification time, or ideal rectification time - e.g. 24 hours.
The specific variables (timings) depend on two things. What your client requires, and what you are willing to provide. I had support agreements requiring 24 hour support, 365 days per year, with a 15 minute response time. I recommend avoiding that if possible as it's a big commitment!
Be clear whether you are supporting the application software, the infrastructure/system, or both. You may be happy supporting all components, but have clear written expectations. If infrastructure is not your thing (and you didn't set it up), then supporting it may not be in your best interest.
Why would a client pay a recurring fee for ongoing system support?
An issue with a system is never good news for a client. It could mean loss of income or customers, as their business may not be functioning. A support agreement provides the client with confidence that you have the time to help them.
They pay for you to be available to them at the time they need. Like car insurance, they most likely won't need it, but if they do you will be there. So it's money well spent.
Why would you offer system support?
As your business and client base grow, it’s hard to drop everything when something goes wrong. You don't want to delay current projects trying to fit in these unexpected fixes. Pre-booking time in your schedule allows you to handle these events. If it doesn't get used for support that's fine too. But it allows you to have padding if issues do arise... which they can.
What happens if the client has no support issues that month?
That’s great for them! But like insurance, they still pay the monthly support fee. This is hard for some clients and they may not want to do it. Or they may ask for the support time to roll over to the next month. But like insurance that doesn’t work. With integral systems that need high availability, ongoing support agreements benefit everyone.
Clients may ask to use the pre-paid hours for new feature development or improvements. I would not recommend this, as in its very nature support is for supporting existing features. It’s up to you (I have done this in the past), but it muddy’s the water if support hours get used for anything other than support.
Retainers are a better method for new feature work, which I discuss later on.
What happens if the client has too many support issues that month?
It's up to you. Your client has agreed to "buy" X hours per month. If your clients wants more hours and you have the capacity - then charge for that work. But if you are too busy, you are under no obligation to do more.
System Maintenance 🛠
“Intellectuals solve problems, geniuses prevent them” – Albert Einstein
Often bundled together, it is important to distinguish between support and maintenance. Support is reacting to an event, maintenance is mitigation against an event from occurring.
Some examples include:
- Ensuring all frameworks and libraries have critical security fixes applied
- Ensuring the system OS has critical security fixes applied
- Database maintenance including performance monitoring and index application
- Monitoring system performance, disk space etc
- Periodic cleanup of any temporary files or log files
- Updating any components that are near end-of-life
Be clear if you are maintaining the software, the system (or infrastructure), or both. Being responsible for keeping JS libraries up to date is not the same as keeping the core OS up to date. Make sure it’s clear in your agreement what you are maintaining, and you charge accordingly.
Why would a client pay a recurring fee for ongoing system maintenance?
Because prevention is the best medicine, and that means someone checking their systems. If not, your clients might only know an issue has arisen when their end users start complaining.
Why would you offer system maintenance?
Because you want the systems you build to function great. System maintenance before an issue occurs helps avoid interruptions to your project schedules.
What happens if the client has no maintenance issues?
This shouldn’t be a thing. You will outline in the agreement what maintenance activities and on what timeframe. These are regular checks and confirmations, so they will be ongoing.
Your client will likely never suggest maintenance activities, it’s up to you. Ensure the software you build is up to date, secure, and adhering to best practices. Even if things change over time.
As mentioned, support and maintenance are often bundled into one agreement. I recommend you explain the difference to your client, as they may choose not to go ahead with one of them. If they agree to both, make sure you have a separate amount of hours allotted to each.
Retainers 🔄
“Do what you do so well that they will want to see it again and bring their friends.” – Walt Disney
A retainer is you agreeing to “keep your time” per month for a specific client, for a pre-agreed fee. This will have a timeframe such as 12 months. In that period you will be at least doing that many hours of work for that client - which is a win for scheduling.
Retainers are a sign of strong relationships, and a benefit of retainers is ongoing communication. Even if my agency were only doing a small amount of monthly retainer hours for a client, I found we were talking and planning more than with project work. This enhances collaboration and sharing of ideas, leading to more work in the backlog. A better outcome for all.
Why would a client pay a recurring fee for a retainer?
Because they want to ensure you are available when they need it. As you win larger projects or get busier, wait times get longer for clients. Pre-booking recurring time in your schedule benefits everyone.
Why would you offer retainers?
Because you want your future pipeline full. Combined with a less lumpy sales cycle, your clients get the work they want when they want it.
What happens if the client has no retainer work that month?
No matter how proactive you and your client are, this will happen. The specifics of this should be in the signed agreement, but the two common options are.
- Retainer hours must be used within the calendar month, and unused hours are still paid for. This puts the onus on the client to ensure they have work for you to do in the time they are paying for. Like renting an AirBnB for 1 week per month - if you don’t use it you don’t get your money back.
- Unused hours roll over to the next month. Issues happen, and sometimes your client may want to stop (or slow down) one month and do more work the next. Put a cap on the number of hours allowed to roll over. For example, with 20 retainer hours per month you could allow hours to roll over for 1 month (to 40 hours), but after that they must use them.
Paid workshops 📢
I have written about paid project workshops, which are self-contained scoping workshops. But there are many valuable types of workshops you can run long-term with your clients.
For clients who do not commit to a retainer, you can run product planning workshops. You spend a day with them and their stakeholders to augment their future product plans with your technical perspective. Then prepare a report with important notes, caveats, and tech recommendations.
For those who do not commit to maintenance, you can recommend a security review. Bundled with a workshop to take them through the results, and propose a plan on how to deal with any feedback.
Thinking about the services you offer, and the services your clients need. You will discover some regular paid workshops you could be running. This may initially be out of your comfort zone, but it benefits everyone. You are adding more value to your clients, and their end users or customers.
Hosting revenue 🖥
Many software development companies make extra income on the top of website hosting. For example, you host your client's website on AWS which costs around $11.55 per month, charge $50.00 and you make money. This is another form of recurring revenue. This is separate to support and maintenance of the hosting, it’s reselling hosting at a higher rate.
I never did this, as I preferred my clients to own their own data. They hosted their projects under their own accounts, and on their own cloud-based infrastructure. I would ask them to register for AWS (or similar) and invite me as a user with full access.
I educated them why we did this, as I believed it avoided “vendor lock-in” on their end, and built greater trust. I look at it like providing a client with detailed documentation to their software. It is exactly that - their software, their systems, and their data. I liked my clients to stick with me because we did a great job, not because it would be difficult to leave us.
Licensing revenue 📝
You might develop a valuable software component, and re-use it across client projects. Charging clients an ongoing licensing fee for its use within their software. This could be anything, as long as it’s valuable for the client, and for you has practical applications for reuse.
I never went down the licensing path, but I'm not discounting it. As with my comments on hosting, I was cautious of vendor lock in. I didn't want the hassle of having to sell these licensable components. I wanted my clients to be able to leave my agency if they weren't happy. And they deserve to take everything with them.
Yes, I probably left money on the table by never going down the licensing path, but I am ok with that.
Leaving the confines of rigid project work helps grow your business. And doing better long-term work for your clients is a win-win.
I recommend incorporating some level of recurring revenue early on with your clients. This is not to squeeze extra money out of them, but to show you have value on all sides of a project. Before, during, and after. Make sure they feel the investment is worth the value, and it’s up to you to prove your worth.