Software as a Service (SaaS) business is unlike .COM, which provided internet based alternatives for conducting commerce (example: Amazon), auctions (example: eBay), travel (example: Expedia), and finance (example: E*TRADE) using desktop browsers initially, and now using mobile applications.
SaaS is a paradigm shift in the implementation, delivery and usage of software applications.
SaaS uses two ways to distribute software applications:
- Web apps: use the public internet to deliver software to users, making delivery costs close to zero
- Mobile apps: use proprietary app stores, which slap on extra penalty of 30%. As a result, most SaaS mobile and desktop applications are “free” to download, and have payments setup through their webapp.
This post will explore engineering initiatives & practices and their impact to popular SaaS business metrics.
Minimizing CAC, Customer acquisition cost
In SaaS articles and forums, I see repeated discussions and guidance to focus on marketing and sales. There is very little discussion on how automation of cloud service install & configuration can be tremendously useful to minimizing CAC.
As an example, I was in a startup where we had a large professional services team to set up and configure new customer accounts. It took us two engineers, and a quarter to automate configuration and data transfer from existing customer systems. I named this project: Customer go live. The impact was rather dramatic, and even surprised me. We were able to fully automate customer set up end to end. This freed up professional services teams completely, and allowed sales to set up different demo accounts quickly. In fact, if a customer agreed to it, we could spin up a trial account in a single call with the customer.
In enterprise circles, this is often termed as the See, Try, Buy experience. As the product sprawl increases over time, it becomes harder to automate cloud service install & configuration.
Increasing DBNRR, iACV
DBNRR is a measure of how an existing customer expands their existing purchases over time. iACV is incremental annual contract value for customers. Both rely on having a range of premium features or extensions being available for customers to purchase alongside the main product offering.
Extensibility of the platform can play an outsized role in accelarating the build out of value added features.
Many times features are considered as direct code changes required on cloud web services and UX screens. If we allow customers and partners to add new services and screens as part of the platform, it opens up other people to add capabilities in an existing platform.
In my current role, I oversee management of extensions for our core product. We allow customers and partners to add custom new REST API, and HTML, JS applications. The result is that customers and partners continue to enrich our solution offerings at the cost of managing their customizations for them.