Skip to main content

Advice for Buying Software Solutions

I have been building companies in the software services sector for over 30 years. Basically there are two types of companies selling such services. Those who offer proprietary products (ie everyone gets the same thing, today usually known as Software as a Service or SaaS), and those who offer bespoke solutions (ie they will build what you need... or at least you hope they will). India for example is  awash with firms offering bespoke development. SaaS is far cheaper to buy and use than Bespoke and will be easier and more reliable to operate long term. But SaaS offerings usually won't do everything you require, and they're all available to your competitors. However, commissioning bespoke software is complicated to do well and always painful.

There are countless examples of governments spending fortunes on projects that overrun and sometimes have to be cancelled. It happens a lot in industry as well, but you don't hear about them for obvious reasons. The biggest reason for experiencing pain is naivety on the side of the client - they think they know what they want, and naivety on the side of the supplier - they think they know what the client wants.

There is an old software adage that says:  

You can have it CHEAP. You can have it FAST. And you can have it GOOD... But only ever two of these

So if it's cheap and delivered fast, it won't be good. If it's fast and good, it won't be cheap (all purchasing departments will beat up suppliers to reduce budgets). And if it's cheap and good, it will take a long time to build... and risk putting the supplier out of business as each party blames the other for delays, but only one holds the purse strings.

When large corporations are seeking software solutions to solve problems, the choice is rarely as clear cut as SaaS vs Bespoke. They will typically want to adapt and blend new software with legacy processes and systems - and this means Systems Integration. In other words, making something new try to work with something old. And legacy resources will usually include employees who are often wedded to old ways of doing things - and maybe naive newcomers who don't understand all the implications of making changes.

The two approaches - proprietary and bespoke... or rent vs buy - aren't mutually incompatible. It is possible for SaaS vendors to offer customisation services. Equally you can find examples of software development companies who 'productise' something they've built for a client (assuming they're allowed to), or more usually, the client might try to productise it themselves (dangerous if they're not already a SaaS provider - there's a lot more to it than just hosting).

The problem with adapting SaaS products to fit a client's requirements is that the original SaaS product wasn't usually meant to be fiddled with. All changes have the potential to cause problems for the core product, which might have unintended issues for existing users and potentially be catastrophic. So SaaS companies will usually resist changing their product unless they've already built an optional module that might better suit a client than the standard package. They will also have, and sometimes publish, a 'roadmap' listing future enhancements that all users will have access to (sometimes part of the core standard offering, more usually a chargeable add-on). Roadmap components may or may not be delivered, but the hope is that clients will absorb a short term functionality deficit in the expectation of delivery in due course.

It's very hard for SaaS suppliers to make money in the short-term. And it's very hard for Bespoke suppliers to make money in the long-term.

SaaS products usually require significant investments to deploy what is known as an MVP (Minimal Viable Product). This has to satisfy actual (not imagined) market needs, in sufficient volumes, and with a sufficiently low cost of acquiring paying users (known as Customer Acquisition Cost or CAC) to generate sufficient Life Time Value (LTV) from each customer to pay back the initial investment, cover overheads (especially customer support), and fund future developments to remain competitive. Most SaaS start-ups never reach an MVP, but if they do, they can switch their development costs over to marketing to find more users.

Bespoke service providers on the other hand, don't have an MVP to aim for. They agree with their clients what to build, employ enough people to do the job, and then look for more clients requiring their development capability. If they can't find enough work to keep their staff optimally occupied, they lose money. It's far harder to trim the size of their business to match market conditions, so they tend to charge high fees to compensate for quiet periods. The larger the bespoke software business, the easier it is for them ride the peaks and troughs. But smaller development organisations bounce from feast to famine, which can be hard to sustain.

Corporations who need a digital solution to solve a problem, and who have healthy budgets, will be tempted to commission a bespoke solution - usually to procure a competitive advantage and to own the IP. That's fine for the buyer, but often a poisoned chalice for the supplier who will enjoy the feast, but will have to then manage the probable famine once the system is delivered. If it's delivered. All the bespoke projects I have ever observed, have not lived up to expectations. They've taken longer, cost more, and not worked as had been hoped or anticipated by either party. Typically the clients have been naive in specifying what they require, and development houses have been incautious in agreeing what to deliver.

By their nature, every bespoke solution has never been built before, so experts have to provide their best estimates over what will be required to build and support it. This includes assessing in advance what skills need to be made available, in what quantity, and for how long. Unlike Bespoke software, if you're building the same thing like a house over and over, you can guess quite accurately how long the next will take. But all software can go wrong. The problem then is working out what is failing and how to fix it without hurting things around the bit that needs to be changed. Many Bespoke solutions never see the light of day, where a license for a tried and tested SaaS solution might have resolved the majority of the requirement. And potentially in the fullness of time, all of the requirement and more when the SaaS provider's 'roadmap' of enhancements is progressively and safely deployed. Indeed SaaS providers, in their determination to fight competitors with their checklist of functionality, often think of enhancements clients won't have considered.

So Bespoke solutions can be expensive and disappointing, but their biggest disadvantage is that they become obsolete very quickly as brighter and shinier SaaS systems fight for market share. Bespoke systems also go wrong or need modifying as the client changes processes. If the original team who built the solution are no longer available to work on it (and why would they be - they need to quickly get stuck into their next project), the new development team needs to get trained up not only in the techniques and languages used by the original authors, they also need to fully understand why bits of the program do what they do. And that can be really hard for a software programmer to understand. Why should he or she know a great deal about accounting subtleties for example. So as time progresses, Bespoke solutions become bigger and bigger liabilities.

This doesn't mean all SaaS implementations work perfectly out of the box every time. Most will require integration with a client legacy system or systems, or possibly customisation to assume the style determined by the client (known as white-labeling). And that can often take longer and prove harder to perfect than originally estimated. Fortunately these days, most systems have back doors  built into them known as Application Programming Interfaces (APIs) which facilitate other systems plugging in.

So although it might look to a corporation that over a long period they can save large amounts of money by paying once for a solution that promises to perfectly solve all their needs, it won't, it will be late, it will cost more than budgeted - and not just upfront, but every year as they make continuous and increasingly expensive corrections and modifications to the system using a team who are becoming less and less familiar with it. But the good news is that they own it.

There's another old saying regaled by wags in expensive city bars. If it flies, floats or f--ks, rent don't buy. That's good advice for software too.


Popular posts from this blog

Phillips screws - yes I'm angry about them too

Don't get me wrong. They're a brilliant invention to assist automation and prevent screwdrivers from slipping off screw heads - damaging furniture, paintwork and fingers in the process. Interestingly they weren't invented by Mr Phillips at all, but by a John P Thompson who sold Mr P the idea after failing to commercialise it. Mr P, on the otherhand, quickly succeeded where Mr T had failed. Incredible isn't it. You don't just need a good idea, you need a great salesman and, more importantly, perfect timing to make a success out of something new. Actually, it would seem, he did two clever things (apart from buying the rights). He gave the invention to GM to trial. No-brainer #1. After it was adopted by the great GM, instead of trying to become their sole supplier of Phillips screws, he sold licenses to every other screw manufacturer in the world. A little of a lot is worth a great deal more than a lot of a little + vulnerability (watch out Apple!). My gromble is abo

Introducing Product Relationship Management - it's what customers want.

Most businesses these days have Customer Relationship Management (CRM) systems which store and process vasts amounts of information about us. They use this information to generate communications, amongst other things, which target us to buy their products and services. CRM is all about how a business relates to its customers: Past (keeping them loyal through aftersales and service), Present (helping them buy through bricks and clicks channels) and Future (prospecting). Most businesses will at some stage have declared themselves 'customer-centric'. They will probably have drawn diagrams on whiteboards that look something like these: But there's a problem with this whole approach of keeping the customer at the centre of your world and the focal point for everything you do. Is it what the customer wants ? Of course companies who ignore their customers eventually go out of business. And those who treat their customers well, tend to thrive. But is it really in the best inte

The Secrets of Hacker Golf

Social media is awash with professional golfers selling video training courses to help you perfect your swing, gain 50 yards on your drive and cut your handicap. They might help a few desperate souls, but the rest of us hackers already know everything we need to complete a round of golf without worrying the handicap committee or appearing on a competition winner's list. What those pros don't realise is that for us hacking golfers who very occasionally hit shots that if you hadn't seen how they were hit, end up where the pros might have put them, we already know everything we need to know - and more. Unlike pros who know how to time the perfect swing in order to caress a ball 350 yards down the centre of a fairway, we hackers need to assemble a far wider set of skills and know-how to complete 18 holes, about which pros have no comprehension, need, or desire to learn. Here are some of them: Never select your shot until after you've hit it. A variation on this is to alway