SaaS


Are you thinking of building your next SaaS project and not sure what to use? This blog post shares our thoughts on why you should consider using Next.js.

## Next.js is extremely popular

While popularity in and by itself is not a reason for choosing a technology,
it is also true that choosing a popular tech is usually the safe choice for
various reasons.

Riding on the popularity of React, Next.js has established itself as the
de-facto framework for building full-stack applications with React.

While it is no longer true that Next.js is the only player in town (like Remix,
Redwood, etc.) it is undeniably the most famous, well-funded, and trusted
framework today.

### Easy to work with

Next.js has gained the love of many developers due to it being incredibly
easy to work with. **The API layer is tiny**, so you don't need to
spend weeks memorizing tons of hours on it.

Secondly, Next.js is fairly production-ready from the get-go, with minimal
intervention for bootstrapping a runnable project.

### Plenty of documentation and content

Its popularity means having access to a ton of good documentation, Q&As,
blog posts, and content about it on the Internet.

This is one of the deciding
factors when choosing a technology: will you be alone when you encounter
issues, or will you be able to easily solve your problem with a simple Google
Search?

### Easy to hire talent

If you plan on hiring talent, you should know that Next.js is among the
favorite frameworks among web developers, making it easier to hire talented
developers worldwide.

It's one of the most popular frameworks in the world, and its popularity means that a ton of people know it well and can help you build your product.

The possibility of never running out of great talent can be a big factor in
using such a popular technology for companies of any size.

### Easy to sell your projects

Given its popularity, selling a SaaS built with Next.js and React can be
easier than selling a project made with a more obscure (or less in-demand)
technology.

The reason is simple: it's a lot more likely that the buyer is already able
to use Next.js than other technologies,
be this an individual or a team of developers.

If I were to build a project with the goal of flipping it, Next.js would be
at the top of my list.

## Next.js offers all the tools to build a modern SaaS

But why is Next.js so popular? Here are some reasons why the
framework built by Vercel managed to capture the love of so many developers.

### Access to a ton of open-source projects and libraries

Another reason you should consider using Next.js for your SaaS is that it gives
you access to many open-source projects and libraries already built.

That means you can take advantage of all the
hard work other developers have already put into those projects and libraries instead of reinventing the wheel yourself.

Being built using React, you have an incredible number of libraries made by small and large companies at your disposal.

### Serverless and native Vercel Hosting

Many developers don't want to be hassled with maintaining servers;
fortunately, its native integration into Vercel's hosting makes Next.js one
of the easiest frameworks to deploy to a serverless environment.

This means you can focus on what's important: **growing your business**,
not spinning and restarting servers.

You'll also have access to all the benefits of a serverless environment,
including scalability, security, and cost savings.

### Next.js is very fast

While not the fastest, it's safe to say that Next.js delivers incredible
performance, which is more than enough for most web applications,
and that can make your little application beat more established
companies when it comes to performance.

Thanks to Vercel's Edge runtime, Next.js can also get much faster for
certain use-cases, such as authentication, A/B testing, and more.

### SSR and SSG

One of the main selling points of Next.js is the ability to automatically
detect if a page needs to be server-side rendered or if it can be a simple
statically generated HTML page.

#### Can statically render pages SSG

For example, if you are rendering a blog post and this page does not need to
fetch any data at render-time, Next.js will generate a static HTML page
instead of rendering the page on the server.

Why? Of course, with no runtime
involved, **a static HTML page will be loaded considerably faster than a
server-side
rendered one**. Furthermore, it will allow developers to save money on computing
time.

This is ideal for static pages such as your marketing landing page,
blog, documentation, etc.

#### Can render pages server-side SSR

Whenever a page requires data at render-time (ie. using the special
function `getServerSideProps`,
Next.js will automatically render the page on the server without any
configuration.

This allows you to dynamically generate pages and based on the user's
context. This is ideal for the internal pages of your application, i.e. the
ones behind authentication.

## Next.js has a bright future

### Vercel has hired plenty of superstars, including from the React team

Vercel has hired plenty of brilliant open-source developers (including from
the React Core Team) to help them
improve Next.js, Vercel, and the entire Javascript ecosystem.

The continued investment into open source technologies by Vercel will help
the framework and the technologies around it keep growing and improving.

The investment into technologies such as Webpack, SWC, Svelte, Turborepo and
others also means that other frameworks will be able to gain from Vercel's
work, making it a victory for everyone.

It's safe to say that the framework is in very good hands.

### Next.js will continue to innovate

Next.js will soon release incredible features that fully use the
newest React developments, such as *Concurrent Mode*, *Server Side
Components*, *Nested Routing* (that [*Remix*](https://remix.run) nailed very
well), the new Edge runtime, Middlewares, and much more.

The above are super-exciting: **Next.js is set to become faster, more
dynamic, and easier to use than ever before**.

## Conclusion: is Next.js a safe bet for your SaaS?

While we want to stress that many great frameworks exist, we're comfortable
saying that as of today, **Next.js is one of the best technologies to start
a SaaS due to its speed, ease of use, and popularity**.

[Makerkit](/) is a SaaS starter template built with Next.js and Firebase to
help you kickstart a SaaS in under 5 minutes. If you want to build
your SaaS with Next.js, take a look at what we offer!


Why you should use Next.js for your SaaS


Firebase is a serverless platform by Google that helps developers build and
grow apps. Millions of developers every day use Firebase for building
complex and profitable SaaS projects.

Why is Firebase so popular? Firebase offers many services for developers:

- **Analytics**: Provides data about how people interact with your app on
mobile devices
or the web without writing any code

- **Cloud Functions**: Runs server-side JavaScript code in response to events
such as user
actions or real-time messages from other platforms like Slack or Facebook Messenger

- **Cloud Storage**: Lets you store and access user-generated content like
images or videos in
the cloud

- **Firestore and RealTime DB**: two serverless and NoSQL databases with
different strengths for storing
your application data

- **Messaging**: allows sending push messages and notifications to the
connected
 clients

- **AppCheck**: helps secure your applications with the invisible Recaptcha v3

## Top Reasons why Firebase is great for building a SaaS

### 1) Firebase offers everything you need to build a large SaaS

As you can see, Firebase offers a complete solution for building a SaaS.

It's easy to set up and secure and scales out automatically as you grow. In addition, it's cost-effective and easy to use, so you don't need an army of developers to maintain your database or update its security rules.

In this post, we'll detail why Firebase is one of the best solutions for building a modern SaaS and its weaknesses, so you know how to complement it with other tools should you need to.

### 2) Developers can use Firebase with the whole suite of Google Cloud products

When Firebase doesn't support what you need, you can still use all the other Google Cloud's products, such as:

- SQL databases

- Caching stores such as Redis

- Analytics Tools and DBs such as BigQuery and BigTable

- Secret Management services

- ... and all the rest of Google Cloud's products and its Marketplace that
allows you to install apps with a single click

### 3) The Firebase Emulator helps you develop locally

The Firebase emulator is a fully-functional, real-time simulator of your app that you can use to test your code locally.

The emulator covers all the Firebase products, which means you can create a local environment that almost entirely reflects your Cloud application in production.

### 4) Create different projects for each environment

Firebase isn't stingy about how many projects you create, so you can easily create a project for each environment.: This helps you save money and develop projects that most likely won't cost you anything more.

### 5) It allows to build serverless products on the Cloud

The cloud is a great place to build serverless products. You don’t need to worry about database maintenance or server uptime and reliability because everything is taken care of automatically. Firebase lets you focus on building your core product while keeping costs low.

If you are a solo developer or a small team, relying on Google's cloud reliability is incredibly helpful: in fact, all your time is best spent on building the product and gaining product-market fit, rather than fighting CIs and servers all day.

### 6) It can be used for building web and mobile apps (iOS, Android, and Web)

While Firebase is often regarded as a PaaS for Mobile apps, the truth is that you can build any application with it: Web Apps, IoT apps, and desktop ones.

Firebase has developed its SDKs to work with multiple programming languages and platforms and offers a Rest API for the unsupported ones.

### 7) The Firebase SDKs have received huge updates

Firebase has often been criticized for its SDKs: heavy on the client-side, confusing due to the various published versions, and not the best API out there.

Fortunately, the Firebase SDKs have received more love recently: starting from version 9 (the current one at the time of writing), they are lighter, more straightforward to use, and better documented.

They're finally tree-shakeable, so your client-side will only load what it uses.

### 8) It's reasonably priced

Firebase is a very reasonably priced service for what it does.

Also, thanks to its very generous free tier, it's likely that you will not spend a dollar on developing your application during its first months if your traffic is light.

This is amazing if you are a solo developer, a small startup, or quickly prototyping an internal tool for your company.

## Makerkit is one of the complete Firebase SaaS starters with Next.js

The most complete Firebase SaaS starter kit today is Makerkit: **It's a
complete solution for building a SaaS, including all the modules you need to
start**.

It's built on top of Firebase, Next.js and Tailwind CSS and offers everything
you need to kick-start a fully working SaaS application that you can use as
a starting point for shipping your next SaaS idea.

Makerkit is built on the fastest growing technologies in recent years,
designed to be quick and easy to use.

## Conclusion

In conclusion, Firebase is an excellent choice for building SaaS applications; we think it's even better today than before and will continue to improve.

Therefore, we at Makerkit believe that Firebase is one of the best options available if you're looking to build a scalable, serverless product on the cloud that supports real-time notifications.

If you want to build a new SaaS with Firebase, take a look at our starter template for creating a SaaS with Firebase and Next.js. We made it so that starting a new SaaS project won't take more than 5 minutes. It's ideal if you are a solo developer or a startup or if you feel like prototyping something new.


Is Firebase good for building a SaaS?


The idea of a modern web application can vary greatly - but at MakerKit, **we have a good idea of what it looks like**.

Most SaaS companies use different codebases (or many) for the marketing website, the product application, and the documentation website. The marketing website usually is the top-level domain. The application gets hosted on a sub-domain (such as app.example.com), and the documentation at (docs.example.com)

Historically, there have been good reasons for doing so, such as:
- **Deployment**: separate deployment means **less risk of breaking one or the other** parts of the stack
- **Engineering Time**: having its dedicated marketing website (typically using a CMS such as WordPress) means that your company won't need to involve the engineers in technical aspects, **saving costly engineering man-hours**
- **SPAs**: the growth of client-side SPA (Single-page Applications) frameworks in the past decade made it **impossible to achieve the decent speed and SEO needed for any marketing website**
- **Concerns**: better **separation of concerns**; the marketing website needs to be an SEO beast, the product a fast and secure application
- **Analytics**: separate and **more straightforward analytics tracking**

As you can see from the above points, many would argue that having a separate codebase can be advantageous in many aspects. But it's not black and white, and for many reasons, **we at MakerKit think that a portion of websites would instead benefit from having a single codebase**.

## Technical Progress with SSR and SSG

While not anything new, it's only recently that SSR (Server-side rendering) and SSG (Static-site generation) have been popularized and democratized for Product applications.

Technical progress from frameworks (React, Next.js, Svelte, Vue, Angular Universal, etc.) and PaaS (Vercel, Firebase, etc.) have been outstanding and made it easier than ever to ship a full-stack application.

MakerKit uses Next.js and **makes the most of its incredible hybrid SSR and SSG** to ship dynamic pages for the product Saas, and static, SEO-optimized web pages for the marketing website's content and documentation.

## Branding and Styling

One of the most challenging undertakings for companies using separate codebases is **delivering unique and consistent branding and styling across all the codebases**. This is especially hard when outsourcing the marketing website to external companies or when built by a different internal engineering team.

One of the ways this can be solved is by using internal UI Components systems built with Web Components that you can reuse across various applications and websites. The downside to using Web Components is the added engineering cost of developing and maintaining the code necessary to deliver the needs of all the consumers involved.

A unified codebase means a **more consistent styling/branding**, **more reusable components**, and **fewer costs** associated with outsourcing your technology stack.

## Seamless Navigation and UX

Another issue with having separate codebases is that, in many instances, the navigation between the Marketing website, the SaaS application, and the documentation website happens across different domains and technologies. From a UX perspective, this is far from ideal.

The navigation will be slower, and the UI less consistent. Furthermore, it can be harder to deliver delightful experiences for your user, such as persisting the authentication, ad-hoc and personalized content to your visitors, etc.

A unified codebase means a **more seamless and much faster navigation and User Experience**, the ability to **deliver personalized content** (for example, providing an API key for users navigating through your documentation), and ultimately happier users.

## When not to use a unified codebase?

It's undeniable that, despite the solutions listed above, a unified codebase is not the most viable solution for every company.

It's not something we'd recommend in the following situations:
- **Company Size**: if your marketing speed and team outpace your engineering team, it's clear that having a codebase that needs development work and maintenance can hinder and slow down both your teams. Having a website that the marketing team can maintain is the best decision.
- **Mission-Critical product**: if your SaaS product is mission-critical (for example, a bank), it's clear that you will want to reduce any risk to your clients; in this case, a separate, ring-fenced codebase can be the right solution

## When should you use a unified codebase?

In our opinion, smaller companies, startups, solo developers, and indie hackers would benefit significantly from having a unified codebase. **SaaS starters such as MakerKit** would be the **best way to kick-start products and ship them quickly to your customers**.

These developers are the most likely to build all in-house and are usually more technical and agile.

Does it sound like you? [Contact us](/contact), and let's find out if MakerKit can be the starter for your next SaaS.


SaaS

Why you should use Next.js for your SaaS

Is Firebase good for building a SaaS?

Benefits of a single codebase for SaaS Marketing and Product pages