I make mistakes. I always have, and I probably always will. But I like to think that I learn something, every time I go astray. -Donald Knuth, From The Errors of TEX (1987)*
As a technical founder of a SaaS company, I am particularly sensitive to the notion of technical debt. Technical debt is a term used in software to describe the cost of creating, using and maintaining poorly designed software that incurs increasing costs over time.
Technical debt is a particularly expensive kind of debt for a young SaaS like FileSpin.io and I take particular care to reduce it at every decision point. This post is an attempt to mark the signposts for those such as CIOs, CTOs, Enterprise Architects and Technology Leads who have to make decisions to buy software or use a SaaS.
Managing the technology and software infrastructure of a company and ensuring it meets the business goals is a tough gig. The role of CIOs, CTOs, Enterprise Architects and Technology Leads is being re-defined and has gotten more challenging and varied in the last few years due to the extraordinary rise in SaaS. Using SaaS for core business critical functions is increasingly seen as a perfectly viable option for enterprise buyers.
Generous use of SaaS within critical business functions leads to one of the biggest problems companies face with SaaS and software in general: you end up paying for the technical debt of your vendor’s software screw-ups.
In truth, every software created has technical debt, some have a small molehill of it but most stand on a mountain of debt. Any non-trivial software necessarily will be imperfect and have bugs since there is only a finite amount of time to create it, test it and release it.
Buyers and sellers make compromises to meet a business need.
Consider this scenario that plays out every day in the software industry: A vendor’s Consultant meets with a Customer to discuss a new feature that Customer has requested. At the end of the discussion, the consultant knows the feature customer wants is not complex. Unfortunately though, it is a one of those square pegs and the vendor software only has round holes. How to fit the feature in?
Consultant is keenly aware of the limitations of the vendor software. He is standing atop the peak of a mountain of technical debt; beneath his feet lies a tangled web of intractable and inscrutable connections that even the core product team is afraid of touching, let alone changing. In his considered opinion, there is no way this feature can be built out of this pile of… existing components. Still, customer is king and an expensive solution is put together to satisfy the customer’s needs. The technical borrowing and debt servicing continues.
Let us pause here. Living in the real world, we understand that all good things come at a price. Depending on how embedded the SaaS is within the IT infrastructure, we may negotiate to get the feature implemented or reconsider if we really need the feature.
All said and done, the money-question then is: What is the technical debt of your SaaS provider and how much of the debt are you servicing?
This is a tough question to answer because the technical debt of SaaS is opaque to you as a customer and there is little incentive to dig deeper when life is good. However, invariably life gets harder at times. A complex business requirement has come up that must be met within weeks; IT budget cuts have impacted projects and SaaS spending. In these scenarios, the biggest impact on your wallet will be determined by the purchase decision you make at the very beginning: which vendor’s software is good for your business.
The early decisions could end up helping a business or hindering it in the long run. I’ll leave you with the criteria that I have always considered when purchasing a software:-