With profit margins being relatively constrained for IT consultancies, when one of our IT consultancy clients told me that its new strategy for scaling involved starting to offer and provide its own proprietary SaaS, it made a lot of sense.
When you swap selling time for selling a solution, there is greater potential for a larger revenue stream than just consultancy alone. This in turn positively affects monthly and annual recurring revenues which drives valuation (multipliers way better for SaaS than professional services). Not only that, but the tax man makes it attractive too, with the possibility of R and D tax credits, and even potentially a 10% corporation tax rate for revenues from patented software.
However, there are some pretty big IP and other legal ‘niceties’ that need to be taken into consideration before starting to sell SaaS solutions, whether as a reseller or software developer.
1. Who actually owns the IP?
As my client has a long history of delivering IT consultancy, it is probably fair to assume that any software has been developed off the back of clients’ business. The first question to ask is whether, under the terms of its historic client contracts, it is actually free to market this software to other clients? Is there any client confidential information or client-owned processes, which would need to be stripped out and/or recoded?
As well as the potential minefield of how much of the IP is actually owned by the consultancy, there is another question about the individuals who have actually developed the software and their employment status. For example if the software has been developed by the consultancy’s employees then most likely the ownership position is fine (generally the employer is the owner automatically). However, if it has used contractors, do the contracts explicitly state who owns the IP that they develop in the course of their engagement?
As a consultancy, open source coding can be real time-saving benefit. However, the licencing for any open source coding used needs to be examined in detail. The last thing any software developer wants to do is create some proprietary code based on open source code, which because of the type of open source code licence, must be made freely to all the world at large. Further the valuation of that software may be impacted – who will pay for software that they should be able to access for free from the open source community?
2. End user software licence agreement
When you “sell” any piece of software, in fact it is a licence to use rather than a sale. With SaaS, this in fact is a contract to provide the solution rather than technically a licence (although the vernacular very much points to “licence”. So you will need an “end user licence agreement”. But you will also need to think about who will support any end user technical problems. Does your company actually have the in-house support to be able to do this? Or will you need to outsource this service? What response time can you offer? You may find that whether you like it or not you are obligated to some extent to supply technical support for your SaaS. Furthermore, clients will expect a warranty that the SaaS meets the specification and/or provides the stated functionality. And you will also have think about availability service levels and backing these off to your cloud provider (in reality the other way around in fact).
3. “Freedom to operate” searches
The name of your SaaS is very important from both a brand and a marketing perspective. Before you can go to market with your product you need to have undertaken trademark searches, or even just a simple Google search, to determine whether you are free to use your preferred solution name.
Also, in heavily patented industries such as mobile telecoms, it is possible to have developed entirely legitimate software without copying from anyone else, but nevertheless it may still infringe someone else’s patent monopoly. So you may have to consider engaging a patent agent to carry out a patent landscape search.
4. Different PI insurance cover may be needed
The PI risks for an IT consultancy vs an IT software, reseller or hardware provider tend to be different. Probably the biggest risk that an IT product seller has to mitigate is IP infringement. (This is less of a risk for an IT consultancy. Consequently, this change in level of risk often means a hike in PI insurance premiums.
5. A general contract review
Your existing contracts, particularly any framework agreements, with your suppliers and customers may also need to be slightly tweaked to take account of the new type of business you are doing. For example, are there any restrictions on competition contained in those contracts which the new business may overlap with? For the vast majority of clients these are going to be mostly tweaks, but still worth a once over.
Expanding your revenue stream by offering SaaS as well as professional services is a sensible move for an IT consultancy. However, some thought needs to be given to the intellectual property position, in particular, to avoid a potential minefield. Also, there needs to be a mindset shift when moving from time-based charging to charging for SaaS: previously your culture will have been to say yes to any client who wants development work done provided they are happy with the rates proposed. But once you go down the SaaS route, whilst of course you need to give the market what it wants, you need to be very wary of agreeing to every request for a tweak or added functionality that the client may ask for. You need to set your own roadmap and only if it is a no-brainer divert from that path otherwise you are just following clients’ whims not setting out your own vision for the product. This is a live issue I know for a number of our clients and I will write more on this at a future date.
For more information on the relevant areas mentioned in this case study, please click below: