March 13, 2024
Archie Named Top AI & Data Product in the 2024 Product Awards
Archie by 8base awarded Best Product in AI & Data; recognized as one of the best products for product managers
Check out our latest blog post on 8base Academy!
Read Post
.png)
After founding 3 SaaS ventures myself and participating in dozens more I've noticed that in almost every case, non-technical founders encounter lots of challenges along the road to building their SaaS products. This article is intended to help make the journey easier by demystifying some of the essential architectural decisions non-technical founders and their teams will need to make when developing SaaS applications.
Product development in startups can be compared to navigating seas filled with icebergs - what you see above the surface (your user interface) can be beautiful and precisely what you want it to be. Still, what's below the surface (your application infrastructure) is where most of your effort and risks lie.
Building and running a Software-as-a-Services (SaaS) business has nothing to do with your ability to write code; this is especially true for the 65% of founders, and maybe you, who are non-technical. It’s more about strategically marketing, selling, and speaking with customers.
“Customers care about your product, but they don't care about your code.”
Yet a code barrier does exist -- it stands between you and success.
What happens if:
What if you actually do need to embark on a product rewrite, God-forbid?
By itself, code does not make your startup work, but a properly constructed product consisting of well-formed code is critical to SaaS success. Your product needs to be great; but, its greatness depends on how your code is written within your overall software architecture - thus, “well-formed code”. When the product doesn't work or can't quickly adapt to changing business conditions, sales and marketing become too expensive, and customer retention takes a nosedive.
Most non-technical founders have never managed a CTO or engineers, yet they are entirely dependent upon them to make the right choices.
So, let's dig deeper into some of the critical areas of SaaS design and architecture in hopes of demystifying some of the concepts.
Once upon a time, most software was purchased outright via a perpetual license, installed on customer's computers, and subject to annual maintenance fees. With the advent of the World-Wide Web, Software-as-a-Service – or SaaS – was born. In the SaaS delivery model, the software is centrally hosted and delivered to customers' web browsers running on their desktop or mobile computing device.
SaaS products are generally subscription-based, with customers paying monthly fees for their use. Salesforce.com is the most widely recognized SaaS company and was a pioneer in employing the SaaS model.
It's common for people to call SaaS products single-instance, multi-tenant, but what does that mean?
Single-instance means that there is one production copy of the software that serves all customers. Yet every customer has nuanced implementations of your product. For this reason, SaaS applications need to be highly configurable for each customer. Building configurability into your SaaS product is highly essential. Most SaaS products allow customer Administrators to manage configurations through "Settings" panels. Well designed SaaS applications also allow Administrators that work at the SaaS company to configure multiple customers through the same or similar Settings panels. We often see these areas of SaaS systems poorly stitched together. More advanced products allow for customer self-subscription and self-service of configurable features.
Multi-tenant refers to the ability to accommodate multiple customers (Tenants) using a single instance of the software and a single logical instance of the database. The most popular form of multi-tenant architecture is where a Customer Table is present in the data model and is connected to each of the tenant tables in the database; this creates a logical separation between the data for each customer.
In advanced forms of multi-tenancy, customers or groups of customers are sharded into different physical databases while still logically connected in a "control plane" at the multi-tenant level. It is common for SaaS companies that grow to be very large to employ a sharding architecture.
Poor implementations of multi-tenancy are where individual, disconnected database environments, and sometimes software environments must be deployed for each customer. Such implementations are expensive to deploy and even more expensive to support and maintain, in addition to being harder to scale.
This SaaS model provides tremendous benefits, including:
Early SaaS products used frameworks and languages such as PHP (LAMP Stack), Ruby-on-Rails, and Microsoft .Net. -- when using such environments, web pages are rendered on a web server and sent to a client-side-browser. This monolithic architecture became problematic with the advent of mobile computing because the tight coupling of backend and frontend did not easily allow for varying frontend requirements driven by different types of devices and form-factors.
Software architects solved this by separating application backends from application frontends and connected them through Application Program Interfaces (APIs).
In modern web and mobile software, the backend is created as an isolated and logically centralized application. The backend typically consists of database(s), server-side computing, and other core application functions such as user authentication, workflow management, notifications, etc. In other words, the backend controls your data and business logic.
The backend is made available to the frontend through Application Program Interfaces (APIs). Most web products utilize REST APIs. Since 2015, a new standard called GraphQL has been used to power modern web and mobile applications. Think of APIs like you would think about the cables that connect your television set to your Cable box. REST is sort of like the red, yellow and white wires we use that each have a different purpose. GraphQL is more like an HDMI cable that is able to connect all of the devices' resources to each other.
Well-built frontend applications are dedicated to managing the user interface. Single-Page Applications (SPAs) are modern web applications that interact with the web browser by dynamically rewriting the current web page with new data from the API(s), instead of the default method of loading entire new web pages. The goal is to enable faster transitions and rich interactions that make the website feel like an installed, native application.
API-first architectures enable an essential separation between backend and frontend. This architecture:
Additionally, some companies productize their API(s) and make them available to customers and their developers. This elevates a company's ability to partner, create new channels, and introduce high-margin, high-growth revenue streams.
The separation of backend and frontend provides a technology company with a powerful advantage but has also increased the complexity of SaaS application development. The two most common approaches are outlined below:
With the advent of mobile computing, REST (Representational State Transfer) became the standard for designing web APIs. With REST, each form of data-request made between a frontend and a backend produces a different endpoint. In complex systems, REST endpoints may number in the hundreds, creating a maintainability problem. Most engineering departments that utilize REST have a strong separation between frontend (UI/UX) and backend developers, who handle the backend data, logic, and API layers. This separation of duties can be wasteful and often lead to bottlenecks in completing projects.
For instance, when a frontend developer needs to display a new field on a screen, in addition to making a simple change to the frontend application, he/she requests the backend team to add a field to an API. This results in a backend developer making a change to a query and then another change to the API.
With GraphQL, the frontend developer can construct his/her own database operation without a dependency upon the backend developer. This frees up backend developers to work on more complex and personally enriching tasks while unclogging development bottlenecks for frontend developers.
With GraphQL, data is specifically requested to suit the needs of the frontend user interface. For instance, a mobile interface can often require less information than a desktop interface. With REST, multiple API endpoints need to be created to support this. With GraphQL, the same endpoint handles both scenarios. This reduces bandwidth requirements and computing requirements on the end user's device.
GraphQL can be a strategic weapon for SaaS companies, allowing them to move faster and with more compact teams, consisting mostly of frontend developers. However, essential to note is that the use of GraphQL does not preclude a company from employing REST APIs for specific use cases.
In the early days of the Internet, it was common for startups to spend their first $500K on computer servers, networking devices, and specialized facilities in their offices to house them. Later came co-location facilities, which were specialty real-estate plays to securely house computing systems. The advent of "Virtualization," further improved computing power-per-square foot of data center space, resulting in lower costs for companies.
And then came Cloud-based providers like AWS, Azure and Google Cloud, who afforded us computing services on-demand without having to own the hardware.
Serverless is the newest model of cloud computing. Serverless fulfills computing needs like your power company fulfills delivering electricity to your home --- using a micro-unit based, fully elastic, and metered service.
Serverless also minimizes the need for DevOps or IT admin personnel, which translates to less cost for startups.
Serverless is especially crucial for applications that require large bursts of capacity. Before Serverless, companies needed to allocate the maximum amount of capacity needed to support their peak loads.
With Serverless, developers no longer need to worry about provisioning or managing servers. Server capacity is provided automatically for every piece of code they execute.
Serverless is a strategic weapon of choice for modern SaaS companies as it allows them to run DevOps-free and scale precisely to meet their user workload demands. This results in a lower cost of computing and personnel with the added benefit of virtually infinite scalability.
The launch of the iPhone in 2007 and the Apple App Store in 2008 marked a critical inflection point for mobile computing. In the months that followed, a gold-rush-like attitude led to an explosion of native mobile apps. Specifically, native apps are installed on a smartphone after downloading from the Apple App Store and later, the Google Play Store. For SaaS companies, maintaining individual browser-based and native apps became cumbersome and expensive. Yet, in those early days, accessing a SaaS system via the smartphone's browser provided a poor experience due to its limited screen size.
In response to this new need, Responsive Web Design (RWD) was born as an approach that makes web pages render well on a variety of devices and window or screen sizes. A site designed with RWD adapts the layout to the viewing environment by using fluid, proportion-based grids. In many cases, the use of RWD eliminates the need to build and maintain native mobile apps.
Since 2015, a new form of application software called Progressive Web Application (PWA) has emerged. PWAs are delivered through a mobile browser and can be installed on a smartphone's home screen.
PWAs help developers build cross-platform apps more easily than using a native-app approach. Some PWAs also allow for the app to be used without an Internet connection. PWAs have become an excellent alternative for SaaS companies to avoid the additional overhead of maintaining separate browser-based and native apps.
SaaS applications rely heavily on data, so the choice of database technologies is a crucial one. Most new SaaS systems today utilize open-source databases, which have matured tremendously. The most important decision to make about database selection is whether it's better to use an SQL database (Structured Query Language) or NoSQL database.
Relational databases consist of a collection of tables that are connected. Tables are like spreadsheets of data with interrelationships between them. Because of its structured nature, the relational database's schema is decided before inserting the data. Common relational databases include MySQL, PostgreSQL, Oracle, Microsoft SQL Server, and others. The relational structure of the data slows down the writing of data but speeds up retrieving data, especially for reporting applications. Business applications commonly use SQL because of this property. Although SQL has evolved to handle large datasets, No-SQL emerged to liberate large web-scaling problems encountered by companies such as Facebook, LinkedIn, and Google. Another critical advantage of SQL is ACID compliance (atomicity, consistency, isolation, durability). ACID is a set of properties of data transactions that guarantee data validity despite errors, power failures, and other mishaps. Financial transactions, for instance, rely tremendously on ACID-compliant processing.
NoSQL databases have risen in prominence in recent years due to their horizontal-scaling capabilities and ability to handle rapidly evolving datasets. While in relational databases, everything is structured to rows and columns, in NoSQL databases, there is no common structured schema for all records. Most of the NoSQL databases contain JSON (JavaScript Object Notation) records, and different records can include different fields. There are four different types of NoSQL Databases, including document-oriented, columnar databases, key-value databases, and Graph databases.
For purposes of SaaS applications, the most common database technologies are either SQL or NoSQL (Document) because the other forms of NoSQL databases are generally used for different types of applications, as follows:
If you are building specialized SaaS products, for instance, data science applications, you might likely use a combination of database technologies that include SQL and NoSQL (Graph). The same is true if you are building a SaaS logging application, etc.
The most straightforward database for a developer to implement today is one of the NoSQL document databases. This is because they can quickly write and read data from it without defining a data schema. However, the ease of implementation can create significant technical debt ongoing as reporting, ACID-compliance, and complex functions become more difficult.
SQL databases remain the most popular choice for SaaS applications. If choosing NoSQL, make sure that it's because it's the right choice, not the easy choice; otherwise, your data will be as organized and maintainable as cooked spaghetti. Find more information on on SQL vs. NoSQL
Your choice of a programming language is not the most important decision you will make in architecting your SaaS product; however, making the right choice can impact your speed, cost, and hiring.
There are successful SaaS products written in commercial environments and open source environments. Open-source languages/frameworks include Ruby-on-Rails, PHP, Java, Python, JavaScript and others. Commercial environments include Microsoft's .Net Framework. Microsoft provides potent tools for SaaS development, but most Silicon Valley companies build using the open-source approach.
Considerations for selecting languages and frameworks include:
The separation of backend and frontend may also dictate the use of different languages. This need adds complexity to your development team's makeup because it inhibits your ability to hire full-stack developers, which can be problematic in smaller teams. Because of this phenomenon, full-stack languages such as JavaScript and its superset TypeScript have emerged.
JavaScript was initially created to support rich interactions on web browsers, but the advent of Node.js, a server-side runtime environment for JavaScript, propelled it to a prevalent full-stack programming language. One of the most significant benefits of JavaScript is that 70% of professional developers understand it, and thus finding talent is easier than with other languages.
Building tech products is a never-ending journey for an entrepreneur, but the decisions made early on are table stakes to make a venture successful. Choices like:
Sticking the landing on these three decisions gives an entrepreneur a fighting chance. Making a mistake in any of the three can mean delays, staff turnover, added costs, and perhaps failure. In my experience, having worked with hundreds of founders, mistakes are the norm rather than the exception.
Non-technical founders should "trust but verify" when it comes to the foundational decisions related to building their products. Critical-thinking and healthy, respectful debate are essential elements of adequately launching a successful SaaS product. Technical teams are not always great communicators, but it's the non-technical founder's responsibility to ensure these conversations are had, whether they are uncomfortable or not.
I invite you to add comments or reach out to me with questions at albert@8base.com.
---
Written by Albert Santalo, Founder and CEO - 8base (www.8base.com).
We're excited about helping you achieve amazing results.
