SaaS Boilerplates and Starter Kits
A complete guide on SaaS boilerplates, when you should use them, and how to choose the right one for your project.

A developer starting a new project

A developer starting a new project. Image by Midjourney.

SaaS boilerplates, or SaaS starter kits are an increasingly popular way to kickstart a new project. It's not an exaggeration to say that using the right boilerplate can cut the development time of a new application in half—or even more. But, choosing the right boilerplate for your project can be difficult.

In this guide, we'll outline what a SaaS boilerplate is, help you determine whether a boilerplate makes sense for your project, and, finally, help you choose the right one.

Here's where we're headed:

What is SaaS?

Before we dive in, a quick refresher on the SaaS in SaaS boilerplate.

SaaS—short for Software as a Service—is essentially software on the Internet. Gmail, Salesforce, and even Twitter are technically all SaaS applications, since they are hosted in the cloud and used in a browser instead of being installed on your device.

In the business world, SaaS often specifically refers to a subscription-based billing model. Anything that you pay a monthly subscription for—from JIRA to ChatGPT pro—falls in this category. Business-to-business (B2B) SaaS applications—which charge a monthly subscription to other businesses—are the most popular category for SaaS businesses (and arguably startups in general).

From a technology perspective most SaaS apps share a lot of the same functionality. Among other things, they all need user accounts, a front end, a billing system, and the ability to be deployed and hosted on cloud infrastructure.

This is where boilerplates enter the picture.

What is a SaaS boilerplate?

A SaaS boilerplate, also known as a starter kit, is a pre-built foundation for a SaaS application. It helps developers save time by eliminating the need to build every aspect of the application from scratch—instead starting with a lot of things already built, and adding their specific application logic on top of that.

There's a good analogy between boilerplates and programming frameworks. In the early days of the web, making applications was a complete nightmare. You had to code your own network protocols, database access, and design your front end from scratch. But, eventually frameworks came along, providing a lot of those pieces for you. Django in the Python world, Rails for Ruby, React and Next.js for JavaScript, Bootstrap and Tailwind for CSS, and so on. With frameworks, building web applications was much faster and easier!

Boilerplates are to frameworks, what frameworks were to the underlying languages. In the Python world, instead of starting with Django, you start with a Django-based boilerplate, and you can ship even faster.

Boilerplate Stack

Boilerplates sit on top of frameworks, which in turn sit on top of programming languages. Each layer provides additional functionality on top of the layer below it.

A typical SaaS boilerplate will have the following pieces:

  • A back end: including connecting to a database, data models for users, teams, and any other default functionality, APIs, business logic, integrations, and so on.
  • A front end: with pre-designed user interfaces, templates, dashboards, UI components, and so on.
  • Development support: tooling and infrastructure that help with development of code on top of the boilerplate.
  • Deployment support: the tools needed to push your app to production and host it on the cloud.

Each boilerplate will have a specific set of features implemented—with user accounts and billing being the ones most common to all boilerplates. Other common features include teams/multitenancy, a content management system (CMS), APIs, background tasks, and integrations with 3rd party tools for analytics, email, monitoring, and so on.

Pegasus Features

An example feature listing, from the SaaS Pegasus boilerplate.

Most boilerplates will be built for a specific technology stack (e.g. Django) or a specific combination of back end and front end, (e.g. Django + React)—and you can typically find boilerplates for any popular tech stack.

Boilerplates can be either free/open-source or paid. Some paid boilerplates also offer support and access to a private community of developers using the boilerplate.

How do SaaS boilerplates work?

Fundamentally, a boilerplate is just a codebase. You download the code, follow the getting started instructions, and are up and running with a new blank application. From there, you follow the documentation and start building your app.

Most boilerplates are distributed like any other codebase: on Github. A handful1 allow you to customize your project before you download the code, letting you enable/disable certain features and choose from different technologies (e.g. your CSS framework).

Once you've downloaded the boilerplate code, development is typically just like any other project, and you can manage your project on Github just like you would any other. Some boilerplates offer upgrades—usually in the form of code merges—as new features and fixes are added to the boilerplate, though upgrading tends to be optional.

What are the benefits of using a SaaS boilerplate?

By far the greatest benefit of using a boilerplate is speed. You can ship an app much faster if large portions of it are already done for you. A mature boilerplate likely includes hundreds of hours of work that you don't have to reproduce.

But speed isn't the only benefit of a boilerplate. There are several others:

  • Boilerplates are battle-tested. The most popular boilerplates have been used/maintained by hundreds of applications over years of time. This means that all the little fixes and tweaks that inevitably arise when building an app have been found and fixed. You get the benefit of a huge amount of real-world experience, ensuring you're starting on a battle-tested foundation.
  • Boilerplates have best practices. Good boilerplates will typically incorporate industry-standard best practices for coding, architecture, performance, and so on. They'll expose you to tools and practices that are common in the chosen framework, without you having to do all the research yourself.
  • Boilerplates are consistent. A boilerplate—like a framework—will often provide a consistent way of doing things. By following the boilerplate's standards, your app will be more consistent, and it will be easier to onboard new team members.
  • Boilerplates help you learn. Boilerplates make it easier for less experienced developers to understand how things work and learn by example when building out their own apps.
  • Boilerplates give you access to additional resources. Many boilerplates—especially commercial products—will have high-quality documentation and access to a community via Slack or Discord where you can ask questions to other people using the boilerplate and the boilerplate author(s). This can be a huge help in getting unstuck when you're building out your app.

It's worth keeping in mind that most of the above benefits rely on the boilerplate being a mature, high-quality product, and may not be true of all boilerplates. This brings us to one of the many drawbacks of using boilerplates.

What are the drawbacks of using a SaaS boilerplate?

The biggest drawback of using a SaaS boilerplate is uncertainty. There is a huge variance in boilerplate quality, ranging from full-time-business-built-by-the-literal-creator-of-the-framework2 all the way down to some-random-college-kid's-side-hustle. A good boilerplate will have all the positive attributes listed above, but a bad one might have the opposite problem. It could be a tangled mess of untested, unscalable code that leads you in the totally wrong direction.

But, assuming you choose wisely (see "Choosing a SaaS Boilerplate" below), there are still some disadvantages of using boilerplates:

  • Boilerplates are opinionated. Remember how consistency was listed as an advantage? Well it can also be a disadvantage—e.g. if you don't like the way the boilerplate has chosen to do things. For many developers, the idea of starting in someone else's code and style is off-putting, and they'd rather have everything exactly how they like.
  • Boilerplates can be inflexible. Sometimes you'll want to do something slightly differently from how the boilerplate does it. In this case, you may find yourself having to retrofit the boilerplate's implementation to your needs, which, in the worst case, can be as complicated as just implementing the feature yourself.
  • Boilerplates can add complexity. You probably won't use every feature included in the boilerplate. And—unless your boilerplate is configurable—this means a lot of additional complexity in your codebase that you're not using. You can of course delete this extra code, but that might not be easy.
  • Boilerplates are less likely to be fully understood. If you write your app code yourself, there's a good chance you'll understand how it works. However, with a boilerplate, you might not. So, if there's a bug or change you need to make, it might be harder to figure it out.

Overall, the pros of using the right boilerplate will usually heavily outweigh the cons, but it's worth understanding these tradeoffs before you make any big decisions about the foundation of your product.

Choosing a SaaS boilerplate

One of the hardest parts of using a SaaS boilerplate is deciding which one to use. It's a big decision, and one that has big implications for the future of your project.

Here are some recommended tips for how best to pick a SaaS Boilerplate.

Pick your tech stack first

Before you pick a boilerplate, first decide what your technology stack will be. Regardless how good the boilerplate is, you're still going to be doing lots of development on top of it—and you'll be maintaining it for as long as your app is running. So it's definitely important to pick a tech stack that you want to work in.

When choosing a tech stack, you'll have a few high-level options. Django (Python), Rails (Ruby), and to some extent Laravel (PHP) are all comparable—mature frameworks with lots of batteries included, with mostly server-rendered HTML by default. JavaScript is the outlier—with a more fractured ecosystem, but tighter integration with the front end. Within JavaScript there's a whole suite of options—React, Next.js, Svelte, Vue, and so on.

As a rule of thumb, if you already know and like one of these frameworks, use that one. If you identify as a front-end developer, you'll probably end up with JavaScript. If you identify as back-end, stay in the Django/Rails/Laravel world. The only other big considerations are that JavaScript and Python are probably the most popular languages, so will be easier to find developers for. These days, Python also is popular for AI projects.

But overall, any popular framework is a good choice. Just don't go with anything too new or too obscure.

Find the available options for your chosen tech stack

Once you've chosen a tech stack, you'll want to evaluate the boilerplates for that stack.

The first place to go is the awesome-saas-boilerplates listing on Github. This is the largest, and most up-to-date list of available boilerplates out there.

Read through the choices (they are generally ordered by popularity), and figure out which ones you want to evaluate. Once you've got a list of options you're ready to start evaluating them.

Evaluating a boilerplate

Here are some recommendations for evaluating a boilerplate.

Don't choose based on features

It can be tempting to evaluate a boilerplate based on the list of included features, but this isn't necessarily the best strategy. For starters, most boilerplates will have similar feature sets. But more importantly, quality is the most important aspect of the boilerplate, and a high-quality boilerplate with fewer features will be a much better foundation than one with lots of half-baked features thrown in.

Unfortunately, it's difficult to evaluate the quality of paid boilerplates, because most of them don't let you try them before purchasing. So you need to look for other signs of quality.

The best three to use are 1) social proof, 2) the project history, and 3) the project's creator(s).

Look for social proof (reviews)

The best way to find out the quality of a boilerplate is to see if it's actually being used, and, if so, how well it is liked. Google "<boilerplate name> reviews" and see what turns up. Look on sites like Reddit and Hacker News and see if other people have mentioned the boilerplate and what they've said. The best boilerplates will have lots of happy users saying good things about them, while the bad/unknown ones won't have much of anything.

Look at the project's history

Another thing you want to know about a boilerplate is the project's history. This will tell you how stable it is, and also how actively developed it is. If the last update to a boilerplate was months or years ago, it's a sign that the boilerplate may no longer be actively maintained, and the creators have moved on. Conversely, an old project with recent updates is likely something that is and will be maintained for a long time.

Look at the project's creator(s)

A final signal of quality is looking into who created the boilerplate. The best boilerplates will be built by people with long ties to the frameworks the boilerplates are built on. Were they an original contributor to the framework, or former CTO building on top of it? Or did they just start using it a few years ago.

Specific product recommendations

The following are recommended SaaS boilerplates that meet all the properties above. They have strong founders, rich communities with many positive reviews, and are still actively maintained.

Python/Django: SaaS Pegasus

SaaS Pegasus

SaaS Pegasus

In the Python/Django space, I recommend SaaS Pegasus. It has stellar reviews, comprehensive documentation, is actively maintained, and the author, Cory Zue, is a former-CTO with a long history of building apps and companies with Django.3

Rails: Bullet Train

Bullet Train

Bullet Train

In the Rails world, I recommend Bullet Train. It's got a rich history, has an open-source offering, great docs, and the author, Andrew Culver, is a longstanding member of the Rails community and an all-around nice guy.

Honorable mention: Jumpstart Pro is also great, and Chris Oliver, the creator, is also a pillar of the Rails community.

Laravel: Jetstream


Laravel Jetstream

For Laravel, it's hard to consider anything other than Jetstream, the official starter kit, that is maintained by Taylor Otwell, creator of Laravel itself.

Node.js/React: Gravity



For Node.js, Gravity4 is a great choice. Again, it has great reviews, good docs, and a dedicated founder in Kyle Gawley.

Of course, these are just recommendations. Do your own research, and pick one that makes the most sense for your specific needs.

Wrapping up

Hopefully now you agree that SaaS boilerplates and starter kits can greatly streamline the development of your next application. While not perfect—overall the time and effort saved by using a saas boilerplate outweighs any downsides. They will generally lead to a higher-quality MVP built in less time.

The hardest part about using a SaaS boilerplate is deciding which one to use. Hopefully this guide has provided a framework for making that decision, and some high-quality options for your next project.

Now go get out there and build something!


  1. Specifically SaaS Pegasus and Divjoy, to my knowledge. Though there may be more. 

  2. This was the case for Laravel Jetstream, which was made by Taylor Otwell, the creator of Laravel. 

  3. He's also quite handsome. And—in full disclosure—wrote this guide. 

  4. This—along with one or two others—is an affiliate link. The existence of affiliates in no way impacted the recommendations in this article, they were just tacked on after it was already written. 

Subscribe for Updates

Sign up to get notified when I publish new articles about building SaaS applications with Django.

I don't spam and you can unsubscribe anytime.