We're live-coding on Twitch! Join us!

How to (Not) Code a SaaS in 2020

Coding a SaaS in 2020 is much different than coding a SaaS 10 years ago. Developers have had a great rush of incredible tools in the past decade to help us build and grow our businesses.

While there are more tools than ever, that abundance brings about the question of "which tools should I use?"

There are hundreds of ways to build and grow a SaaS. Falling into the "analysis paralysis" trap can often happen.

In this article, let's look at some of the ways to build out our apps and especially look at what parts of building our apps we should focus on. This is the written version; if you want the video version, check it out on YouTube: Building a SaaS, Part 2: Developing Your App, From Front to Back

Really when we build a SaaS, one of the biggest questions we have for ourselves (besides "how can I provide value") is "what's the fastest way to get paying customers?" This is something I wanted to explore in today's ecosystem.

The Main Takeaway

The main takeaway I hope that people get from this article:

Focus on what makes your SaaS unique. Don't be afraid to outsource everything else.

better.dev Get Started w/ JavaScript for free!

The thing I like about today's ecosystem of coding tools is that we can outsource so much functionality that isn't core to our value we provide to users. For instance, our users don't care if we built our authentication ourselves or if we used something like Netlify Identity, Okta, or Auth0.

If your SaaS bombs, then at least you didn't spend months upon months building it!

The Story of Scotch.io

I learned a lot of lessons while building Scotch.io over the past 6 years. It all led to a great point of being acquired by DigitalOcean. The progression of Scotch.io looks similar to many SaaS companies:

  • Build as a side project
  • Provide real value
  • Gaining traction and growth
  • Monetize (ads, sponsorships, subscriptions, sales)
  • Maintain and grow customer base
  • Either sell the company
  • Or keep growing the company and revenue

From building our own blogging platform on Laravel, our own CMS, and redesigning our site 8 times, I've figured out what went well and what went wrong.

The biggest mistake when building Scotch.io was that I stopped focusing on our main value: high quality content.

I focused too much on performance improvements on the site and spent too much time redesigning when I could've been writing new content. The two circles below are when I focused on redesigning and rearchitecting our platform on Laravel. At the end of the redesign, the users didn't see a major difference in overall performance. They only cared about the design and new content.

It's all good though! Scotch was able to grow and follow a good path! Our guest authors were able to write great content and keep the visitors coming.

Scotch was made in 2013 in a slightly different coding environment. Let's move forward and see what it takes to code up a SaaS in 2020.

What is Your Main Value to Users?

Before we get into the coding, we should always determine what value we are offering to our users.

What is the problem we are trying to solve?

Once we figure out a problem to solve (it's often a problem we have from our own experiences), we can determine if the segment of users is large enough. I don't want to focus too much on this section for this article; we can tackle this in another article if you're interested!

One of my colleagues at DigitalOcean did a webinar on Customer-Driven Product Development if you want more info on that side of things.

The Anatomy of a SaaS

Let's start talking about actually building a SaaS.

When building a SaaS, it's important to determine if you'll be building this alone or building this with a team. If you're building with a team, you have to put practices in place early to get everything streamlined. GitHub workflows, language formatting, and more will change based on your team. You want everyone on the team to be comfortable with all the decisions.

Here's a diagram of how most app architectures will look. Each box will vary greatly, but from a high level overview, this is the core stuff you'll need.

You'll usually have the following:

Let's talk about the things every SaaS will need.

The Core Coding Choices

All of these things, you'll have to decide for your team. At the end of the day, it should come down to what you and your team are comfortable with. The majority of the time, it isn't worth it to learn a whole new language or database just to build your app.

  • Language: PHP, Ruby, JavaScript, Go, etc?
    • Framework: A few choices for framework in each language
  • Database: MySQL, Postgres, MongoDB, Fauna
  • API: REST, GraphQL
  • Where to host code?: GitHub, Bitbucket, Gitlab
  • Where to host app?: DigitalOcean, Netlify

Ultimately, you should pick what gets you to ship your product fastest.

Even though we can go far into the weeds with these technical decisions, we must always focus on our end goal: providing value to our users. Customers care about the product, not what database powers your app.

Once you get past choosing your code choices, you still have many more choices ahead of you!

The Extra App Choices

After you've got your main code options ready, we can talk about bringing extra functionality to your application. Here are some of the things that every application will need to take their core application and extend it to become a real SaaS:

Building Extra Functionality

Growing and Maintaining


If we think of every SaaS we've ever used, all of the above are parts that we can see. There are the core functionalities and then the extended things that are also essential. Figuring out what to build and what to outsource is crucial.

As we add on new features to our app, our amount of code increases and the amount we have to maintain increases.

But if we have outsourced some of these functionalities, then we are able to keep the code we are responsible for slimmer:

What if we could even outsource more to the point where we just have to worry about our UI and UX?

The Quickest Way to a Code a JavaScript SaaS

We have to choose a language when we want to experiment with quickly building a SaaS. Since I'm deep into the world of JavaScript lately, I'll be focusing on the JAMstack.

  • JavaScript: React
  • APIs: A CMS that gives me an API to grab content
  • Markup: Generate my markup with Gatsby

I've been working with React, so I'll go with React for my language.

I want to put my focus on the frontend since that's where my users will interact with my app.

I don't want to put too much work into building out my database, schema, or API. I don't really want to do much backend work.

Using a CMS

In the past, I would've spun up a Laravel instance, created my database schema and models, created controllers, and finally create and authorize an API. Then we could use Laravel's views or use the new API we created to create a UI in React.

To build our own backend and API could take months.

Today, I realize that building out a database and API isn't my main competitive advantage. I would use a tool that could build out my database and API automatically. Headless CMSs like Strapi to build out my backend. Just by installing Strapi, I'll be able to get a full backend including a CMS and a REST API all within 5 minutes. This sure beats building out my own backend with Laravel or even Node. This definitely beats having to maintain that custom backend that I could've created.

There are other great options for Headless CMSs that can give us a database, API, and dashboard out of the box.

Using the REST API

Gatsby will be my tool to generate my site. Gatsby excels at static site, but it can also handle creating dynamic apps like e-commerce and more. Next.js is another great tool to build dynamic apps.

Luckily for us, Gatsby has a Strapi integration where we can pull our content from our REST API.

We could bring in our content from our new API with GraphQL:

plugins: [
    resolve: `gatsby-source-strapi`,
    options: {
      apiURL: `http://localhost:1337`,
      contentTypes: [`article`, `user`],
      singleTypes: [`home-page`, `contact`],
      loginData: {
        identifier: "",
        password: "",

And some more code to bring in our content:

  allStrapiArticle {
    edges {
      node {

This article is meant to be a high-level overview, but we can dive into actually creating this Gatsby site in a future article. Once we build out our frontend with Gatsby, we may want to take our app further.

Adding More Functionality

Let's say we wanted to add authentication. Let's say we wanted to add payments. Again, users wouldn't care about how we handle auth or payments. They just want to know that its secure and that they can login and pay.

Our core advantage and the reason why users come to our product is because we offer something more than just authentication and payments.

Using something like Auth0, we can add authentication like this:

// login a user

// get user info

With a payments tool like Paddle, we could add payments like this:

Paddle.Checkout.open({ product: 12345 })

When we can so quickly add parts to our applications using these outside tools, why would we focus on building out these features for months at a time?

Won't It Cost More to Outsource to Start?

It could potentially cost more when you bring in all these 3rd party services. I would rather pay a bit upfront, get a product out quickly, and start gaining revenue from customers than spending hours and hours of engineering hours building (and maintaining) these features.

Time is the biggest expense. Don't spend it engineering.

Is It OK to Have 3rd Party Providers Hold My Data?

It could be a problem if you don't 100% trust the company. For authentication and payment providers, you must really be sure they are fully compliant with all the laws and best practices.

For authentication and payments, you also don't want to be holding all that info on your own servers, especially payment information.

Going Beyond the Minimum Viable Product

Building the SaaS is one thing; everything that comes after building the initial app is where large companies are born.

  • Maintaining the code
  • Building new features
  • Marketing to get new customers
  • Support to keep current customers

I've heard people say that whatever the time and cost it takes to build something, you need to multiply that by four to maintain it.

It can be tempting to build something in-house. Don't forget to factor in maintenance.

Once our app starts growing, we can start thinking about scaling. Don't fall into the trap of overthinking and overengineering.


No matter what decisions you make, always remember to focus on the customer. Don't fall into the coder's trap like I did where I thought I wanted to create everything in house. Building a CMS was one of the things that took up so much of my time when I could've been creating content.

I know this article was supposed to be about coding a SaaS and it leaned more towards not coding a SaaS. Now that we've figured out what to outsource though, we can focus on how we want to build our apps!

Like this article? Follow @chris__sev on Twitter