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:
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.
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.
Comments
Post a Comment
Thanks for taking an interest.