SaaS Application Development for Non-Technical Founders (Part I)
PART I — SaaS Application Architecture
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.
The Challenge for Non-Technical SaaS Founders
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:
- You overengineer your product, take too long to bring it to market, and run out of money?
- Your product quickly falls apart when too many customers are using it?
- New enhancements take too long and too often break the system?
- Your engineering team talks to you about continuous integration pipelines, writing test scripts, docker containers, and Terraform scripts, but customer-centric tasks are never completed quickly enough?
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.
What is a SaaS Application?
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.
What Does Single-Instance, Multi-Tenant Mean?
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.
What are the Advantages of Single-Instance, Multi-Tenant Architecture for SaaS Application Development?
This SaaS model provides tremendous benefits, including:
- Lower costs through shared infrastructure and economies of scale: With multi-tenancy, each new client can be added at a marginal cost approaching $0.
- Ongoing maintenance and updates: Customers don’t need to pay costly maintenance fees to keep their software updated. Vendors roll out new features and updates that are included in SaaS subscription fees.
- Saas companies can more easily analyze cross-customer data and bring data-driven insights and benchmarks to their customers.
- Customer configuration is accomplished while leaving the underlying codebase unchanged. Maintaining a single code base for all customers dramatically lowers complexity while speeding innovation.
Monolithic Applications, Single-page applications (SPAs) and API-First Architecture
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.
Strategic benefits of an API-First architecture for SaaS Application Development
API-first architectures enable an essential separation between backend and frontend. This architecture:
- Allows developers teams to work in parallel more easily.
- Reduces the cost and time to develop applications through facilitated re-use of code.
- Increases speed to market.
- Improves your developer experience (DX).
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.
API Architecture Options for SaaS Applications
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:
REST APIs
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.
GraphQL APIs
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.
Serverless Computing for SaaS Application Development
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.
Response Web Design (RWD), Progressive Web App (PWAs) and Native Apps
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.
Databases for SaaS Application Development
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.
SaaS 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:
- Columnar Database- Data science or logs. Popular choices include Cassandra.
- Key/Value Database — Used for in-memory caching. Popular choices include Redis or Memcached.
- Graph — When data is graph-like (like social networks or anti-money laundering). Popular choices include Neo4J.
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
Programming Languages for SaaS Application Development
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:
- What current developers at your company know the language already?.
- Is it easy to hire web developers who know the language or train developers who don’t?
- What language is growing or stagnating in use, but not decreasing?Is there a large selection of useful libraries available (open-source or paid for) that suits your domain?
- Do you have a specialized use case that a certain language is best suited for handling? (i.e. Python is excellent for programming data-science applications).
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.
Conclusion
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:
- Who is deciding what the product does?
- Who is designing and building it?
- What underlying technologies are utilized?
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).
