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

Norman's Autobiography

The following is an unfinished autobiography written by my father who passed away earlier this week at the age of 93. Cheerbye Dad (you were the only person I knew to use this expression). You were a huge influence on my life. Thanks for taking the time to record so much that I never knew about your own life and those of our immigrant ancestors. Dad's the one in the middle ;-) The HorBraJacSac Saga by Norman Horwood  9th June 1926 (or possibly earlier!) - 27th June 2019 The Families' Backgrounds. We have four families; Abrahams/Horowitz/Horwood; Bralofsky/Braley; Jacobs and Tchaikofsky/Sacof. Taking my pair, the (Abrahams) Horowitzs/Horwood and the (Bralofskys) Braleys. They escaped from different parts of "Mittel Europe" at different times. Abraham and Rachel Abrahams, nee Gess, (Horowitz), had been in England longer than the Bralofskys, having come here from Lithuania in about 1897 as a married couple without children. It is certain that Abraham

Prepare for Alien Contact

I've not gone barking mad or joined some weird religious cult (aren't they all?). But I do predict that we will make contact with intelligences from other planets soon. Here's my reasoning: There are approximately 100,000,000,000 stars in our galaxy (easy way to remember this order of magnitude is it's one hundred, thousand, million). Usefully there are also approximately the same number of galaxies in the universe. And assuming every star has about the same number of planets orbiting it as our Sun, and that the Milky Way is an average size of galaxy, that means there are around 100,000,000,000,000,000,000,000 planets in the universe. A lot. Scientists have long debated the probability of life, as we would recognise it - reproducing, eating, etc - existing outside Earth. Most agree mathematically that it's a certainty. What they did was take all the components they believed were required for life to have evolved on Earth and then extrapolate what they know about