SaaS Under The Surface

The Unknown Unknowns of Building a SaaS Application

Some vital parts of a sustainable software business easily get overlooked.

Building a Software-as-a-service(SaaS) is much more complicated than it looks on the surface. Creating a piece of software that you charge other people money for means that you have added an order of magnitude more complex than an application used for internal purposes.

SaaS products are like an iceberg.

The Application Lives Above The Surface

You see the core functionality and value at the top. The business value. The fun stuff. What people see and think, “This is it. Easy peasy.” When the truth is, the application is only what’s visible above the surface.

Service Code Lives On The Surface

Service code is the functionality that turns “software” into “software as a service: Authentication so people can log in, and billing so they can pay you monthly for the privilege. The happy path of these lives above the surface. What people tend to forget is all other administration parts of the features when customers run into problems:

• How can users reset their passwords?
• How do they update their email address? 
• Do you need to consider Two-factor authentication? some company have security policies which require that applications they use to have two-factor authentication, so this is something to heavily consider if you sell B2B software to companies of any scale
• What happens when someone upgrades or downgrades their plan?
• What if someone wants to cancel? 
• How do you handle refunds? No matter what you do, managing customers who want their money back is inevitable.

Under The Sea

Now we get to the boring but essential parts of running a SaaS. These services don’t tend to provide a lot of visual business value. But if they didn’t exist, a problem could cause your business to collapse. If you were running the kitchen on the Titanic, these would be the cleaning supplies and fire extinguishers in the supply closet.

Transactional emails – Transaction emails are emails that your application sends throughout the user’s lifecycle and use of the application. Examples include weekly summaries and confirmation emails. These are different and typically use a separate piece of software that marketing emails, such as newsletters—an often overlooked part of an application that can bring a lot of value. Emails are part of the user experience. You should be mindful of what emails, when you send them, and their voice and tone.

Monitoring  -monitoring tools keep an eye on all the different parts of the system and collects analytics useful for understanding how everything works under the hood. Monitoring is useful for debugging issues and identifying opportunities for optimization.

Error Logging – If one of your servers when down, how long would it be until you found out? You’ll need a way to know when errors happen and how frequently they occur. Error logging keeps track of errors and can notify you of severe issues immediately.

A Staging Environment. Applications live in different environments. The live version of your application is the production environment or “production” for short. Copies of the code that live on the developer’s laptops are development environments. In between, you have something called “staging.” It’s an environment that mimics production as closely as possible with a different database. Use it to test features, research issues you found due to your error logging, and to demo upcoming features to customers before they go live.

Backups – You need a way to safely store and recover data if something goes wrong or you make a corrupting change to your database that needs undoing. When it comes to paying customers, two is one, and one is none.

Hosting – You’ll have to decide where and how to host your application. There are several options, but hosting is a more irreversible decision. Think long and hard about your hosting needs now and what they could be 1-2 years from now. A common choice is Amazon Web Services (AWS).

Analytics – You’ll want to keep track of how many users are using your application, as well as how they are using it.

Reporting – Analytics answers questions about using your application in a broad sense, while reporting is for drilling down. Think of analytics as the results of a poll, while reporting as the answers a subset of people gave in a survey. You’ll want to use data generating by your application to make data-driven decisions, and you can’t do that without reporting.

God mode – god mode is something that you don’t know you need until you need it. As the owner of an application, do you want to ask a developer to make a change for you every single time you need one? Here’s an example: a user mistyped their email and wants you to fix it. You didn’t build this into your MVP, but you could do it manually. A developer could manually access the database and make the change, but what if you had a simple interface where you could? Tools like active admin for rails are one example of tooling explicitly designed for admin panels.

Fortunately, Ice isn’t that expensive.

The one good thing about these under the surface problems is that everyone has them. These problems aren’t new, so there are several off-the-shelf solutions available. 

Some examples:

• Authentication – auth0 and AWS Cognito
• Billing – Stripe Checkout
• Transactional Emails – SendGrid
• Monitoring – AWS Cloudwatch
• Error Logging – Rollbar
• Analytics – Google Analytics and Hotjar

Building Your Iceberg

These service-level problems can either be solved by custom code in your application or by integrating with 3rd party services. Doing so reduces initial development costs but adds to monthly billing, dependency on a 3rd party for core functionality, and complexity to the system’s architecture. 

Part of building a SaaS is deciding when to make the build vs. buy tradeoff when creating something valuable for your customers. Factors to consider when deciding when to build vs. buy.