SaaS has become the dominant paradigm in delivering an application to users. But what is SaaS?

You could say that SaaS applications are software applications that are delivered to their users over the internet and in a browser, often paid for by way of a monthly subscription fee.

And while that is technically correct, that single-sentence definition glosses over a lot of complexity! A lot of complexity for the user, the vendor, and most certainly for you—the developer of such applications!

In this chapter, we will start to build an understanding of SaaS, with a basic understanding of the technical, operational, and functional knowledge required to build a SaaS application from the ground up using Microsoft technologies. We will expand on that previous definition to the point that you—the reader, and soon-to-be SaaS developer—can confidently approach and solve problems by delivering SaaS-based solutions!

Let’s start by expanding on that definition a little.

SaaS is typically understood to be applications that are delivered and interacted with through a browser. The software is not purchased or “owned” by the user and installed on their computer. Instead (typically), a monthly membership fee is paid, which grants the user access to the service.

From the user’s point of view, the benefit of this is that they can access the application anywhere, at any time, on any device. They do not have to worry about installing the application or keeping the app up to date. All of that is just part of the service.

Many of the biggest tech companies in the world provide SaaS applications, and there is a good chance that you are using at least one of them!

Gmail is a great example of a SaaS application that is provided by Google. While it is free to most users, there is a fee for corporate or professional users who must pay for access to the G Suite tools. As well as a SaaS mail client, Google also offers a calendar application and a contact management application, as well as Office tools for authoring documents, building spreadsheets, or creating slides for a presentation.

For a small monthly fee, you can use your browser to access the Shopify application, which is—of course—a SaaS application.

All social media sites are also examples of SaaS applications, and while they may be free to use for the vast majority of the user base, there is a cost to the businesses that use the platforms to advertise their products.

As well as the examples given previously featuring enormous, multinational, billion-dollar corporations, there are many more examples of businesses that are supplying their software using the SaaS paradigm. There are software vendors—and from the vendors’ point of view, there are many benefits to delivering software in this way. The primary and most obvious benefit of this is that they have a huge market reach—a truly global market that they can tap into, with multiple very high ceilings on the revenues that are available. In addition, the tech team needs only support one version of the application, and the support team also only has one version to support. The vendor can push out updates, and all users will instantly be on the latest (and hopefully greatest) version of the application. In theory, at least, SaaS is a clear choice in almost every instance. However… SaaS is hard!

While the benefits to the business are many, the challenges that the team tasked with building the application will face are also many. And from the technologist’s point of view, this is where things get interesting!

But before we dive into the details of SaaS applications, let’s first consider what the alternatives are!

This book will describe SaaS, but while discussing what SaaS is and why it is a good choice in many instances, it will be contrasted with other types of delivery mechanisms for other types of applications. Some of the other traditional delivery mechanisms are discussed in the following sections.

Desktop application

This is the traditional type of application that was the major paradigm for many years. The software is packaged up into an installer and is somehow distributed to the end user. The distribution mechanism could be on a floppy disk or a CD or downloaded directly from the internet.

The application stores all of its files and data on the user’s machine.

Typically, these types of applications are supplied with a product key that activates the software. Alternatively, licensing servers could be installed, allowing companies to more easily license the product on multiple computers.

On-premises web application

This type of application has largely been completely replaced with SaaS systems, but it was common for a while to develop a web application that could then be sold to multiple customers and installed on a server on the premises of the customer’s organization.

This provided some of the benefits of SaaS but came with a lot of the baggage of a desktop delivery model.

The main benefit of an on-premises web application is that the purchasing company retains full control of the application. This means that they can choose to install an update—or not—based on an internal assessment of the costs and benefits of an updated version.

Another big plus of this delivery mechanism is that any data either stored in the database or transferred between the clients (web browsers) and the server can be retained entirely within the company’s internal network infrastructure and need not ever touch the wider public internet. In theory, this does allow for additional data security.

A counterpoint to the aforementioned points: while it may seem more secure for a company to keep its data inside its own network, cloud services such as Amazon Web Services (AWS) from Amazon or Azure from Microsoft have put an incredible amount of resources into ensuring that stored data and data in motion is secure—indeed, their businesses depend on it. It is not guaranteed that a company’s internal network is more secure.

While the ability to pick and choose versions and deploy updates at a time of the purchasing company’s choosing may seem beneficial, this requires that the buyer employ people to install and manage the application, as well as to support their users.

What is “the cloud”?

Core to SaaS and delivering applications in the browser is the concept of the cloud. At its most basic, the cloud is just someone else’s computer… but while accurate, that doesn’t really quite do it justice. The cloud enables applications to run with very high levels of availability, and with essentially infinite—and instant—scalability.

For a SaaS app, the cloud is absolutely crucial. In almost every case, every component (database, application programming interface (API), and user interface (UI)) will be hosted using a cloud provider. The most commonly used cloud providers are Microsoft Azure, Google Cloud, and Amazon AWS.

The large cloud providers are essentially just providing access to an enormous amount of computing power, for a cost. This is termed infrastructure as a service (IaaS) and is a very important pillar of SaaS.

While this is not a history of programming book, I think that it’s worth taking a short look at the last 60-ish years of application development to see how we have arrived at the place that we have.

My first introduction to professional programming was visiting my father’s office sometime in the late 1980s when I was around 6. I was shown the computer room, which contained an enormous VAX “mainframe” machine that did all the thinking. I was then shown around the offices where workers had terminals on their desks (complete with green text, just like in The Matrix) that connected back to the mainframe. The cost of the actual computer was such that there could be only one, and everyone simply got dumb terminals on their desks that looked something like this:

Figure 1.1 – A VAX terminal

Despite the simplicity of the preceding display, I was instantly captivated, and this experience clearly resonated with me as I followed in my father’s footsteps and became an application developer myself, albeit working with very different tools!

We were a long way off SaaS in the 1980s (although the “mainframe” and “terminal” configuration was perhaps instructive in some of the thinking that came later)!

While internet technology has existed since the 1960s, it has not done so in a way that is recognizable to the current generation of TikTok-addicted teenagers. The internet was little more than a technical curiosity until deep into the 90s and was far from the bedrock for delivering applications that it now is.

A huge technical pillar required to build a SaaS application was achieved in August 1994, when Daniel Kohn made the first secure credit card transaction. He bought a Sting CD—there is no accounting for taste! In November of the same year, Netscape Navigator introduced the Secure Sockets Layer (SSL) protocol, making it technically possible for anyone to transact over the internet without fear of having their information stolen.

Almost immediately building upon this new payment tech, Amazon launched the following year and was joined shortly by eBay. This was the very beginning of people willingly typing their credit card details into the internet with some degree of trust, but this practice was so far from mainstream at this point. (Sidenote—I made my first online purchase on Amazon in June 2001, buying Happy Gilmore on DVD; there is no accounting for taste!)

The first true SaaS app did not take long to emerge. Salesforce released what is considered to be the first true SaaS app, with its CRM platform launching in 1999.

However, to say that SaaS started in 1999 is not really giving the full picture. Sure—Salesforce was miles ahead of the curve, and its investment in its SaaS app has surely done wonders for the company (and its balance sheet) over the following decades. But the internet was still a curiosity to the vast majority of the population in 1999. While Salesforce could lean on its corporate clients with (relatively) fast internet connections, the reach of a SaaS app was tiny. Relatively few households had the internet, and none had broadband connections. The huge majority of the population would never consider putting their real name on the internet, never mind their credit card details! The era of SaaS ubiquity was still some time off.

By the time I started my career as a developer in the early 2000s and entered a corporate programming environment for the first time since the 80s, things had moved on considerably. There were no more VAX mainframes. By now, we all had blazing fast (by comparison) computers on our actual desks, so there was no need to delegate the computations to a centralized mainframe computer anymore. You could do the computations right there on your own computer. And so, we did! Throughout the 90s, thousands of developers churned out millions of “gray box” desktop applications, often written in VB6 with arcane installation guides that (hopefully) covered any and all eventualities. This was not really a high point for application development, certainly not enterprise applications, which constituted the vast majority at the time.

Round about this time, the internet was starting to mature to the point that it was a day-to-day business tool and was rapidly becoming as common as running water in the typical household. But even in the mid-2000s, the concept of “web apps” or Web 2.0 was still to emerge into the mainstream. Sure—there was PHP and ASP, and you could use those technologies to build web-delivered applications. But these were often more akin to clever websites, rather than what we would currently consider a fully-fledged “web application” these days. Despite the fact that online payments were becoming very common, there was still not really the concept of paying a monthly fee for a “service.” The expectation was still that you would “buy” and therefore “own” and subsequently “install” software yourself.

This would, of course, change over the following two decades.

ASP.NET took what had been started with “classic” ASP and really ran with it. WYSIWYG editors were provided with Visual Studio, making the workflows very familiar for anyone who had been building the now old-fashioned “gray boxes” with VB6. “The Enterprise” almost immediately embraced “web apps” to replace the gray-box apps that had become typical and often universally hated.

This move from the enterprise to deliver software in the browser taught a generation of office workers about the benefit of web-delivered software, and before too long, they would start demanding that for all applications, even ones used in their personal life.

Email was most likely the first service catering to an individual that went fully web-based. The Gmail beta launched in 2004 with a then huge storage capacity of 1 GB for free… with more available for a cost! The monthly “subscription” for consumer-grade software was born.

These days the consumer market for SaaS applications is huge, with a multitude of task-list, note-taking, journaling, and email services provided. Not to mention that entertainment is now supplied “as a service” with monthly subscriptions to Netflix, Spotify, and many others now in many—if not most—households.

There are no residual concerns about entering payment information on the internet. There are barely any homes not serviced by broadband internet, and even developing countries often have robust mobile data networks and smartphones in the hands of many. There are no longer any barriers in place to delivering cloud-based applications over the web, for a monthly subscription.

It is clearly apparent that SaaS has eaten the world and taken over as the dominant method of delivering software! The era of SaaS is upon us!

SaaS is becoming an increasingly popular choice across many different industries and many different sizes of enterprises. It is becoming ubiquitous across all manner of business models. There are a number of reasons for this, but for the most part, this is derived from the ability to add value to the user and revenue to the vendor. It is a win-win paradigm.

All manner of different applications can be developed and delivered over the internet and in the browser. The same tech stack—and, therefore, the same development team—can be used to deliver essentially any kind of application that the business can dream up. This makes it almost equally appealing to a start-up as it does a multi-national.

Using a traditional desktop application model or on-prem web app, the business needs to have a direct line to all of its customers for invoicing, providing updates, and so on. Acquiring new customers requires a sales team, and deploying new instances for new users requires a tech team. Given that each install is in a different environment, it is very likely that a sizable support team is also required to help with a myriad of different installations.

All of this melts away with SaaS. The only scaling consideration is the availability of virtual servers, which are near infinite in the era of Azure and AWS.

Because SaaS adds value for both the user and the vendor, it has become an obvious choice for businesses of all sizes.

The range of tools that could be used to develop a SaaS application is huge. The nature of developing a SaaS application is such that specific tools will be needed to build and test databases, APIs, and frontends, as well as many auxiliary tools such as static analysis, build pipelines, source control, and containerization tools, to name but a few.

This book will focus on the Microsoft tech stack, and as such will primarily use tools from Microsoft. But we will use a lot of them—such is the nature of building a SaaS app.

Database development

Starting at the bottom of the tech stack, we will use SQL Server Express for all database work. This can either be installed directly onto your developer machine or run in a container using Docker. Both methods will be described in detail in this book, although we will generally prefer containerized solutions.

API development

An API is a set of rules and protocols that specifies how two systems should communicate with each other. It is a way for one system to access the functionality of another system, such as a web-based software application or a server. APIs allow different software systems to interact with each other and share data and functionality. They are often used to enable integration between different systems, such as a mobile app and a backend server, or a website and a database. The API will be developed using C# and .NET 7. Sticking with all things Microsoft, we will use Visual Studio Community Edition. This is a free and extremely powerful IDE that makes developing the C# application very straightforward.

Frontend development

There are a plethora of good options with which to build the frontend for a SaaS application. The selection will largely come down to personal choice or the availability of developers on the market.

At the time of writing, by far the most commonly used frontend technologies are JavaScript-based—typically, Angular or React. However, the future is WebAssembly, and Microsoft has recently released Blazor using this technology, which allows the frontend to be built using familiar .NET languages, such as C#. This book will demonstrate a frontend using Blazor, but given that the JavaScript frameworks are (for now) more popular, I will take care to keep the explanations generic enough that the learnings with Blazor can be applied to any other frontend framework.

Authentication and authorization

Regardless of which frontend technology is used, it is of vital importance to get the authentication and authorization correct. We have dedicated an entire chapter to this later in this book. We will use an implementation of the OAuth 2.0 protocol, and will demonstrate how to secure your SaaS application from the UI all the way through to the database, and back again!

Hosting

Every SaaS application needs somewhere to live, and that will typically be in the cloud. While the bulk of this book will focus on developing on a local developer machine, we will also investigate how to build a deployment pipeline, and show your app “going live.” We will use the Azure portal for all application and database hosting.

Docker

Developing a SaaS application really is the epitome of “full stack.” We will be working with a wide array of tools, from databases to the frontend, not to mention many different testing frameworks to test all of these components. Accordingly, we will lean on Docker a lot to wrap up all of these dependencies and simplify the development process. Docker is a truly huge topic on its own, and it is outside the scope of this book to fully explain what Docker is and what Docker does. Put simply, Docker allows all sorts of complexity to be wrapped up in a very simple-to-use container.

For example, consider executing a few thousand unit tests against a UI and an API, and maybe a few integration and end-to-end (E2E) tests as well. There can be many dependencies involved in running these tests locally, and it can often take some time to configure a developer machine to successfully execute the test suite.

With Docker, it is possible to encapsulate a full testing suite within a Docker container to run the tests with a very simple Docker command. Further, these tests will run identically on any machine with the Docker client running. So, the Dockerized test suite will run just as happily on a Mac, Windows, or Linux, as well as in a pipeline on a cloud server.

In a nutshell, Docker wraps up complexity and facilitates simple interactions with complex systems.

Really, there will be no specific techniques that we will use that are not used in developing any other type of software application. However, I will briefly mention the techniques that I will use in this book.

Test-driven development (TDD)

One of the huge benefits of SaaS is that the application can be updated very quickly and essentially rolled out to each and every user at the click of a button.

This is great assuming that everything works as expected, but it is much less good if there is a bug in the code. Of course, we could build an extensive set of manual regression tests and build business processes into the release pipeline… but in doing so, you are losing a lot of the supposed advantages of SaaS—the ability to release often and early.

The only way to facilitate rapid deployments with some level of confidence that they will work is to build automated tests. And really, the best way to build an automated test suite is to do it as you go along, by following a TDD approach.

I am aware that TDD has a somewhat mixed reputation in the industry at present. In my opinion, that is because TDD done wrong is a nightmare, and TDD is done wrong very often. I will present a variety of TDD that I feel is an excellent support structure when developing SaaS apps.

Domain-driven design (DDD)

DDD is defined as an approach to software development where the problem is specified by domain experts and not by middle management.

DDD is a software development approach that concentrates on understanding and modeling the business domain of an application in order to improve the design and implementation of the software. It emphasizes the importance of domain knowledge in software development and encourages the use of domain-specific language in the design and implementation of software systems.

In DDD, the business domain is understood as the core area of expertise or focus of an organization, and the software being developed is viewed as a tool to support and enhance the work being done in that domain. The goal of DDD is to create software that is aligned with the business needs and goals of an organization and that accurately reflects the complexity and nuance of the business domain.

SaaS products are often simply made available to anyone with a web connection, and there is no dedicated sales team individually approaching every customer and actively selling the product. Therefore, the product must sell itself, and so it must be useful. In order for this to be true, it is essential that the product is meeting a specific user need and addressing a particular problem domain.

Microservices

SaaS projects need to be flexible so that the product can evolve with the market and with customers’ demands. It is very important that the product is architected in such a way that allows the straightforward addition of new features, with a minimal impact on existing features. A microservice-based architecture fits this requirement.

Multi-tenancy

Because every user is a tenant in the same deployed version of the application, the users’ data must be kept separate in the data storage and retrieval systems. There are a number of ways to approach this, which are discussed in a subsequent chapter of this book.

Reactive design

A SaaS application lives online and is accessed through a browser. In the modern era of smartphones and tablets, there is no way to know what type of device will be used to access your application. The frontend really needs to work on any type of device, or at the very least “fail gracefully” if it cannot operate on any given device.

Accordingly, the design of the UI must be “reactive,” meaning that it can be rendered in a way that is befitting the device that it is being displayed on.

Progressive web apps (PWAs)

Something “nice to have,” but I feel it is worth considering. When we are building SaaS apps, we really want the user to feel that they are using a full-blown “application” and not a glorified website. However, by definition, a website cannot be shown if there is no available internet… PWA-based designs work around this by allowing limited functionality to work where there is little or no internet available.

Of course, with no access to the backend, many of the functions of the site will be unavailable. There is no way around that, but PWAs can be used to make that a little less painful for the user, and so it is an important technique that authors of SaaS applications should be aware of.

We will demonstrate a PWA using Blazor for the frontend technology.

Reasons for choosing SaaS as the go-to paradigm for all manner of businesses, large and small, old and new: as we have highlighted previously, much—if not most—of the population is using some form of SaaS application, from Gmail to Netflix. If SaaS is really eating the world, there must be a reason for that.

No installations needed

This is the biggest and most important thing that drives businesses toward a SaaS-based solution.

Using a traditional application model, a new customer will often have to contact a sales team and sometimes also a tech support team to get the software installed on-premises and appropriately licensed.

With SaaS, a new customer can discover the app and sign up for an account in seconds without needing any contact from the company that is providing the application. This is a significant saving for the company that has developed the application in that no additional sales or support teams are required to onboard the new customer. This also prevents a time lag from discovery to installation, during which the customer could change their mind or discover a competitor.

Browser-based delivery

The users of a SaaS application are not limited to accessing the application on a specific computer or in a specific network environment where the license server resides. The users can have access to the application from any internet-connected machine anywhere in the world. In the modern era of smartphones and tablets, the user of a SaaS application may not even need a computer to take full advantage of the provided service.

Scalability

In a traditional model, this is simply not possible. Convincing people to install any application on their computer is hard. Convincing companies to do so is doubly hard. Scaling up the user base of a desktop application requires a dedicated sales team and also a dedicated support team to first make the application, and then hand-hold people through the installation process. With a SaaS app, users simply sign up on an online form.

Because the SaaS application is hosted in the cloud (Azure, Google Cloud Platform (GCP), or AWS), near-instant scale-up of the infrastructure is possible should a sudden spike in demand occur. There is no other software delivery paradigm that could face an overnight 10 times increase in demand and not leave the vendor floundering!

Upgradability

Under the “legacy” methods of delivering applications, upgrading the apps tended to become nightmarishly complex and expensive for the vendors of the apps.

If you consider a traditional desktop application, the same application could be installed on hundreds of machines across hundreds of different businesses. No two businesses will be running the same hardware or OS versions, and so it is impossible to keep everyone on the same version of your software. It is similarly completely impossible to roll out an upgrade to a new version. At best, you can withdraw support for a particular version at a particular time and hope that everyone stops using it (note—they will not stop using it).

This is a similar problem for an on-premises web application. While there are fewer induvial installations, there will still be many different versions out there, servicing specific business requirements.

This problem completely melts away when you move to a SaaS paradigm. The vendor has full control of the upgrades and can roll them out to all customers all at once at the click of a button.

Only having one version of an app to support is a huge saving for the vendor and also a huge advantage for the development team.

Iterate quickly

An emergent property of the upgradability advantage of a SaaS app is the ability to iterate on the solution extremely rapidly. Feedback about new features can be incorporated and pushed out to all users in very quick cycles. This allows for a very fast turnaround from a developer writing a feature to that feature providing value to the users and revenue to the vendor.

Consider how long it takes for that value to be realized in a traditional app. The code may well sit in a Git repo for many months before it is even included in the “annual release,” and then, the users may choose not to upgrade immediately.

Analytics

Because the users are all funneled through a single web application, it is extremely easy to analyze how the application is being used. This can guide the business to make smart decisions to upgrade the most used parts of the application and defer working on less well-used parts. Couple this with the ease of upgrading and the fast iterations, and this can provide a huge boost in value to the users and should come with a boost in revenue to the vendor.

Global market

With SaaS, the ability to reach customers anywhere is a massive boost for the business supplying the product. There is no case where a sale is missed due to time-zone issues or a sales rep failing to reply to an email.

The ability to gain access to a truly global audience has allowed some companies to become the biggest companies in the world—bigger than banks and oil and gas majors. This access to a market also allows thousands of smaller companies to thrive in a truly global environment.

Flexible payment model

There are many different payment models available to a business offering SaaS. This allows it to capture customers large and small and derive the most value possible from each tier or size of the customer. Some types of payment models follow:

• Tiered pricing
• Freemium
• Free trial periods
• Per-user pricing

Security

Access to the SaaS application will be through a user login that protects sensitive data and files, which are securely stored in a cloud system. This is (in most cases) far more secure than storing data on a server on-premises—or on a local user machine, in the case of a desktop application. While it may seem that keeping all of the data locally or within a local network is more secure than sending the data to a server on the cloud over the internet, this is often not the case. A huge amount of effort goes into securing the cloud services that are typically used to host SaaS applications, and often that effort cannot be replicated on a site-by-site basis, whether that be securing an on-premises web app or individually securing the data on desktop-installed applications.

In theory, the development process for building a SaaS app is rather similar to any other type of application, but in practice, there are nuances and considerations that you must note as a developer working on a SaaS project.

Release often, release early

There is no “annual release cycle” for a SaaS app. The expectation is that functionality will be broken down into manageable slices, developed, and then pushed out as soon as they are ready. This requires a bit of a mindset shift if coming from a more traditional release cycle. All changes have to be incremental, generally contained to a small part of the applications, and ready for release ASAP.

This mindset of getting the code into the hands of the users will have to be backed up by automated pipelines that build and release the new code without much manual intervention.

While it is possible to roll out the updates to sections of the audience to make sure there is nothing catastrophic in there, it is much more typical for a small-to-medium-sized SaaS application to simply push the updates out to all of the users all at once. For this to be successful…

Testing, testing, testing

If the code is released to the entire user base in one go, and often with no real way of rolling back the change, you had better hope that it works!

The only way to build any sort of trust that the code will operate as advertised is to test it, and in a “release often, release early” mindset, this means automated testing. While this doesn’t necessarily mean adhering to a TDD mentality, this can certainly be useful.

You’d better be full stack

Okay—this is not absolutely required. I’m sure that the larger SaaS applications are worked on by specialists in the database/backend/frontend disciplines. But it will certainly help to have a good knowledge across the different application layers.

The way that SaaS applications “grow” in an almost organic way through the fast cycles and near-instant releases means an understanding at least across the layers, and an understanding of how a decision in the database may affect the frontend is invaluable.

Know thy user

While this may not be required for each developer in the team, it is absolutely essential that the team as a whole understands who is using its product, why they are using it, and where the value is. This knowledge and understanding will come from assessing the analytics and also from “softer” approaches, such as focus groups and interviews with users.

This understanding should flow down into the development process through user stories. From the developers’ point of view, this may manifest in seemingly sudden shifts in direction, if a particular feature has not landed well with a focus group or user interviews have shown that a particular path is the wrong one. The ability to pivot quickly is important across the team.

This chapter has served as an introduction to what SaaS is, where it has come from, why businesses and users love it, and finally what is required of you as a developer to effectively build a SaaS application.

In the coming chapters, we will deep dive into all of the aforementioned areas, but with a focus on building the tools and understanding required as developers to build great SaaS applications that your users will love to use, and that (hopefully) you will love to build!

To illustrate the technical points and understanding required, we will build, test, and deploy a full stack SaaS application!

I have approached the writing of this book with the same mindset as I do when I am building an application. I aim to make this an engaging, interesting, and maybe even “delightful” experience for the user—which is you in this case!

Let’s get going!

What is technical debt anyway? Let’s start with a definition:

Technical debt accumulates as features are added to a project. It is inevitable that as complexity is added to certain areas of a project, some of the other parts of that project will no longer fit quite as well and will at some point have to be worked on. However, the realities of life as a developer are that products must be shipped and that bills must be paid, and therefore the time is not always allocated to tidy up every last corner, and over time, technical debt starts to accumulate.

Another source of technical debt that all projects will experience occurs when the underlying frameworks and technologies are updated. It is often not straightforward to update a major release, and sadly it is common for projects to languish in outdated versions—which represents a technical debt.

One final common source of technical debt is when users’ habits change. In the era before the iPhone, very few people accessed a website through a mobile device. That very quickly changed, leaving many teams scrambling to update their websites so that they functioned correctly when accessed through a mobile device.

All technical projects have some technical debt—there is no getting away from that fact, and it is important for all projects to keep on top of this. However, there are a few considerations specific to developing SaaS applications that must be taken into account.

The philosophy with most SaaS applications is to get the development work into the hands of the customers as quickly as possible. This is usually achieved through extensive automated test suites, coupled with build and release pipelines to push the code out to the production environments as soon as possible.

Contrast this with traditional release and delivery mechanisms, where there will be a year gap between releases, and (hopefully) some time in that year allocated to paying off technical debt.

With the constant develop-release-repeat cycle that is common to SaaS development, it is important that technical debt is kept on top of.

The first and most important way to assess and pay off technical debt is to allow the development team some time each week (or each sprint cycle) to do “chores.” These would be small housekeeping tasks that might otherwise be left to grow into serious technical debt issues. The development team are always the people who know best where the technical debt is. After all, they created it in the first place!

Static analysis is another extremely powerful tool to keep on top of technical debt. Static analysis is used to check the quality of the code when it is not running (when it is static!) and can check that standards are adhered to and the latest best practices are being implemented.

Similar to static analysis, linting should also always be performed to ensure that the code is formatted according to the agreed coding standards.

As mentioned previously, out-of-date packages can become a major source of technical debt. While being on the absolute cutting edge can be risky, there is rarely a benefit in being significantly out of date. There should be regular housekeeping done to ensure that any packages and frameworks that are being used are sufficiently up to date.

Finally, automatic performance testing should be carried out to ensure that there are no regressions in the performance of the application as it grows and changes over time.

Even if all of the aforementioned points are strictly adhered to, a project will still accumulate technical debt over time. There is very little that can be done about this. But with the preceding considerations and mitigations in place, the impact that technical debt has on the project—and, ultimately, the profitability of the company building the project—can be minimized.

This chapter has given a broad introduction to the concept of SaaS. We have covered a brief history of application development and looked at the paradigms that were prevalent in the pre-SaaS days. We have considered why SaaS is becoming so popular and looked at the technical, business, and user-centric reasons for its adoption. Finally, we have considered which tools and techniques you as a developer need to be effective as a SaaS developer.

Hopefully, this chapter has given you a strong foundational understanding of SaaS, which we will now start to expand on as we move through this book!

Building SaaS applications is challenging, but by far the best way to make progress is to start building and get your hands dirty! In the next chapter, we will get straight into the tools, tooling, and techniques that will be used throughout this book to build a demo of a SaaS application!

• For current business trends: https://www.datapine.com/blog/saas-trends/
• For some SaaS development tricks and tips: https://www.rswebsols.com/tutorials/software-tutorials/saas-application-development-tips-tricks
• For further information on scaling SaaS applications: https://medium.com/@mikesparr/things-i-wish-i-knew-when-starting-software-programming-3508aef0b257