Analysis of Runtime Behavior of Boutique Software-as-a-Service

We define a boutique Software-as-a-Service (SaaS) as a business from one to fifty people, which primarily sells a software product through an online subscription service. We were curious to find out the technology stacks behind those businesses, as well as the usage of administrative features (User profiles, Billing, etc.) that need to be built up as part of running a Software-as-a-Service but which are not core to the service delivered.

There are a lot of studies on the pricing, sales and revenue metrics of Software-as-a-Service businesses ( Insightful Study of 386 SaaS Startup Pricing Pages is one we would recommend to read), but there are few surveys to our knowledge to the actual mechanics and engineering cost to build minimal consumer or enterprise-ready SaaS features. We thus embarked on surveying:

1. The technology stack of a wide variety of boutique SaaS businesses.
2. How much users interact with the administrative features of a Software-as-a-Service product (User profiles, Billing, etc.) vs. the actual product being delivered.

Decomposition of the technology stack

We analyzed the technology stack of 38 businesses with 1-10 people and 53 businesses with 11-50 people delivering a software product as a subscription service.

We used BuiltWith to retrieve information about a site technology stack. We also used the Google Developers tools to retrieve HTTP headers when necessary to decide what technology is used. When this wasn't enough, we relied on job postings and other outside communication from the company.

Sometimes static home pages or pricing pages are served by other means than the technologies used to implement the Software-as-a-Service business logic. So we did all the analysis on a registration or login page as these are the most likely candidate for the actual framework used.

Nginx makes up for the overwhelmingly majority of front-end proxy web servers (68%). Apache is second with a total of 16% across the board. We can find Cowboy, Express, IIS, markers for Google AppEngine and sometimes gunicorn directly.

Outside of Rails that represents around 40% of the backend application framework used, the set of application framework and programming languages used on the server is widely fragmented, each taking a few percentage points. This is often a reflection of the CTO's experience.

Analysis of HTTP requests by features

There are great posts on website's requests from a browser perspective and Optimizing for rendering speed. Here we are interested to analyze what happens server-side to a request hitting an application hosted on DjaoDjin.

DjaoDjin's infrastructure is built of a generic HTTP server, a session manager proxy and customer web applications. Typically requests for static content are completed by the generic HTTP server (nginx in our case). Other requests are forwarded to the session manager. All pages and APIs that deal with the administrative part of a Software-as-a-Service (ex: /login/, /billing/, etc.) are completed there. Other requests given a green light by the subscription firewall are forwarded to a customer application. Thus DjaoDjin's customers need only implement a micro-service for the business logic actually delivered to end users.

We completed an analysis of the last three months and found out that the lion share of requests are for static assets (Images, CSS and Javascript files) which are completed by the generic HTTP server. Out of the dynamic requests, roughly 1/3 are for administrative pages (registration, cart checkout, statements downloads, finding a customer, etc.) and 2/3 are actual product logic pages and APIs.

From earlier measurements of DjaoDjin customers code bases, we found out that 80% of a boutique Software-as-a-Service product deals with the administrative component of running a business online. That means 80% of the code base deals with less than 33% of the total requests a site handles every day. Regardless that code, which deals among other things checkout and credit card updates, is critical to run a business on the Internet.

When we started DjaoDjin we knew we were solving a big pain point. We strive to be good citizen to the community and opened source all pieces of DjaoDjin Software-as-a-Service infrastructure from the first day (djaodjin-multitier, djaodjin-pages, djaodjin-saas, djaodjin-signup, etc.). Today with enough customers to have statically significant results, it is good to be able to share real numbers.

We are looking forward to post about the struggles boutique SaaS have around subscription engineering (Plan upgrade, Charging overages, Chargebacks, etc.). If you have any stories to share, please write us a quick e-mail and let's start the conversation. Thank you.

More to read

If you are looking for more posts about what it is like to build a boutique subscription product, you might enjoy Breaking The Curse of Negative Cash flow in Software-as-a-Service or Boutique entrepreneur, LLC or Corporation?

Some of technical posts worth reading next include Whitelabel Domain with TLS. and Serving static assets in a micro-services environment

More business lessons we learned running a SaaS application hosting platform are also available on the DjaoDjin blog. For our fellow engineers, there are in-depth technical posts available.