Changelog


I am very excited to announce that Makerkit now supports Lemon Squeezy subscriptions! 🍋

## Why Lemon Squeezy?

Lemon Squeezy is a subscription management platform that allows you to sell subscriptions (and one-off payments) to your customers.

But why use Lemon Squeezy instead of Stripe? Lemon Squeezy is a Merchant of Record (MoR), which means that they are responsible for collecting sales tax for you. Not only this means it's easier for you
to get started with selling subscriptions, but it also means that you don't have to worry about collecting sales tax yourself, which saves time and ultimately plenty of headaches.

Lemon Squeezy charges a 5% + $0.50 fee on all transactions, which is a bit higher than Stripe's 2.9% + $0.30 fee. For payments outside of the US, it will also charge 1.5%. With that said, it can be worth it if you don't want to worry about sales tax.

## Makerkit + Lemon Squeezy = 💖

Lemon Squeezy has been integrated as a different branch on top of the original `main` branch, named `main-ls`. If you'd like to use Lemon Squeezy instead of Stripe, you can use the `main-ls` branch instead of `main` when creating your app.

For more information, please consult the documentation for your kit. At the time of writing, Lemon Squeezy is supported in the following kits:
- Next.js + Firebase
- Next.js + Supabase

Support for the Remix kits will be added soon.

The current integration with Lemon Squeezy will allow your customers to:

- subscribe to a plan
- switch to a different plan
- cancel the current subscription
- resume their subscription

At this time, to support more complex workflows such as trial periods, prorations, etc. you can customize the Lemon Squeezy integration yourself, in fact, the code is fairly concise and easy to understand.

In the future, we may support a basic customer portal and more complex workflows.

Check out the demo below:

<TweetEmbed>
  <blockquote className="twitter-tweet" data-dnt="true" data-theme="dark">
    <p lang="en" dir="ltr">Announcement ✨<a
      href="https://twitter.com/makerkit_dev?ref_src=twsrc%5Etfw">@makerkit_dev</a> now supports <a
      href="https://twitter.com/lmsqueezy?ref_src=twsrc%5Etfw">@lmsqueezy</a> 🍋 for SaaS subscriptions! 🎉<br/><br/>Adding
      an
      MoR was highly requested 👉 you can now accept payments for your SaaS and never worry about sales tax! 😎<a
        href="https://twitter.com/hashtag/buildinpublic?src=hash&amp;ref_src=twsrc%5Etfw">#buildinpublic</a> <a
        href="https://t.co/qCCvD9QuCu">pic.twitter.com/qCCvD9QuCu</a>
    </p>&mdash; Giancarlo (@gc_psk) <a
    href="https://twitter.com/gc_psk/status/1641410695412563975?ref_src=twsrc%5Etfw">March 30, 2023</a>
  </blockquote>
</TweetEmbed>

## Conclusion

Adding a MoR was one of the most requested features for Makerkit, and I'm very happy to finally be able to deliver it.

I hope you enjoy using Lemon Squeezy with Makerkit! If you have any questions, please feel free to reach out to me on Twitter or Discord.

Announcing: Makerkit now supports Lemon Squeezy subscriptions! 🍋


I'm excited to announce that Makerkit is adding support for Multi-Factor Authentication (MFA) the Supabase kits. This is a sneak peek to our coming feature.

## What is MFA?

Multi-Factor Authentication (MFA) is a method of authentication that requires more than one piece of evidence to verify the user's identity. It is a way to add an extra layer of security for your users' accounts.

## Should you add MFA to your app?

If you're building an app that requires a high level of security, then you should definitely consider adding MFA to your app. For example, if you're building an app that requires users to manage their finances, then you should definitely add MFA to your app.

Your users will feel more secure knowing that their accounts are protected by MFA, and it can be a potential differentiator for your app. I don't see a reason not to offer this functionality to your users.

## How does MFA work?

Supabase allows us to use TOPT (Time-based One-time Password) to generate a one-time password (OTP) that the user can use to login to their account using their second authentication factor.

## Supabase MFA in Practice

### Step 1. Users will enroll an authentication factor (e.g. Google Authenticator)

The first step for your users is to enroll a new authentication factor using an Authenticator app (such as Google Authenticator or Authy).

1. The first thing they are required to do is to specify a name for their new authentication factor: Supabase supports up to 10 factors (more than enough for sure!). This name will be used to identify the authentication factor in the Authenticator app, and will help users remember which factor they are using.
2. Then, they're required to scan the QR code with the authenticator app. This will generate a secret key that will be used to generate the OTP.
3. After confirming the one-time code generated by the authenticator app, the user will be able to use their new authentication factor to login to their account.

<Video src="/assets/images/posts/mfa-setup.mp4" />

### Step 2. Users will login to their account using their email and password

After logging in, we will check if users have enrolled any MFA factor. According to Supabase, this rarely uses the network and it's a very fast check. After logging in using the first authentication factor, the users' assurance level is `aal1`.

If users are required to use MFA, then we will redirect them to the MFA page. This page will prompt them to select a factor: for example, a factor enrolled using a work smartphone. If only one factor is enrolled, then it will be automatically selected.

Then, they will be required to enter the OTP generated by the authenticator app for that factor. If the OTP is correct, then the user will be logged in to their account. Their assurance level is upgraded to `aal2`.

<Video src="/assets/images/posts/mfa-verify.mp4" />

## Conclusion

I'm excited to add this feature to our kits. I think it's a great way to add an extra layer of security to your app. I hope you enjoyed this sneak peek to our coming feature. If you have any questions, feel free to reach out on our Discord server.

Announcing support for Multi-Factor Authentication (MFA) with Supabase


As you may have seen, we are working on a new SaaS kit based on Supabase and Next.js 13 using React Server Components and the new app directory. We are excited to share a behind-the-scenes look at how we built the kit.

## A quick recap: what is a SaaS kit?

Makerkit's kits are a collection of templates that you can use to build your own SaaS products. 

The goal of the kits is to provide the building blocks that you need to build your own SaaS product and to help you get started quickly, such as a landing page, authentication, Stripe payments, emails, multi-tenancy architecture based on organizations, user invites, and more.

The kits are built using the latest technologies and are designed to be easy to customize and extend to fit your needs.

## The Supabase and Next.js RSC SaaS kit

The Supabase and Next.js RSC SaaS kit is a new kit that we are working on. It is based on Supabase, Next.js 13 React Server Components and the new app directory.

### A rewrite of the Supabase and Remix SaaS kit

It's mostly a rewrite of the Supabase and Remix SaaS kit so the two kits are very similar. While competing, the two frameworks are extremely similar, and the migration was mostly a matter of changing the framework-specific code.

In short, both frameworks are great and you can't go wrong with either one. It's important to remember that while Remix is production-ready, (at the time of writing) the Next.js app directory is still in beta.

### The Next.js app directory is in beta

Therefore, this kit is going to be a beta kit as well until the Next.js app directory is out of beta.

## Enter React Server Components

The most striking difference that you will find in the new kit is the use of React Server Components. 

The new Next.js app directory leverages React Server Components by default: Server components are rendered on the server and then sent to the client as a serialized stream. 

What the above means is that the client can render the component **without having to download the JavaScript bundle**: as you can imagine, this allows Next.js to deliver a much faster initial page load.

### Did you notice performance gains?

Generally speaking, yes. 

But the performance gains don't come for free: your components need to be written in a way that allows them to be rendered on the server, which means they will mostly be data-fetching and rendering components, and no interactivity. 

Interactive components (client components) will be rendered using SSR and hydrate on the client just like you're used to the traditional Next.js `/pages` directory.

When you're able to write your components in a way that allows them to be rendered on the server, combined with carefully written `laoding.tsx` loading handlers, you can **take advantage of the performance gains** that server components unlock and provide a **much smoother user experience** than possible today.

## The new Next.js app directory

The new Makerkit app directory will look like the following tree:

```
- app
  - (app)
    - components
    - dashboard
      - page.tsx
    - settings
      - organization
        - page.tsx
      - profile
        - page.tsx
      - subscription
        - page.tsx
    - layout.tsx
    - loading.tsx
  - (site)
    - about
      - page.tsx
    - faq
      - page.tsx
    - pricing
      - page.tsx
    - layout.tsx
    - loading.tsx
    - page.tsx
  - api
    - organizations
      - route.ts
    - stripe
      - checkout
        - route.ts
  - auth
    - components
    - password-reset
      - page.tsx
    - sign-in
      - page.tsx
    - sign-up
      - page.tsx
    - layout.tsx
    - loading.tsx
  - invite
    - [code]
    - components
    - layout.tsx
  - onboarding
    - page.tsx
  - components.css
  - globals.css
  - layout.tsx
  - loading.tsx
```

If you're not familiar with the Next.js app directory, here is a quick overview:

- pages are defined using the special filename `page.tsx`
- layouts are defined using the special filename `layout.tsx`
- loading handlers are defined using the special filename `loading.tsx`
- directories will create a new route, for example, `app/dashboard` will create the route `/app/dashboard`
- directories using parenthesis are "pathless", .e.g. `(app)` will not create the route `/app`, but will start from the root of the app directory, for example, `(app)/dashboard` will create the route `/dashboard`. The same goes for `(site)`

### Pathless directories

Pathless directories are useful for defining routes that are not part of your app: for example, the `(site)` directory is used to define the routes for your landing page, pricing page, and more. Instead, the `app` directory is used to define the routes for your app, i.e. the ones behind authentication.

### Data-Fetching Layouts

What makes these particularly useful is the fact we can define data-fetching layouts that can fetch the data that is common to the pages in the directory: for example, it may not be useful to fetch the current organization in the `site` pages, but it is useful to fetch the current organization in the `app` pages.

Or, for example, we want to ensure that logged-in users can't access the `auth` pages, but we don't want to do the same for the `app` pages. By using layouts in such a way that we can control both data-fetching and authentication, we can write our pages in a way that is more declarative and easier to reason about.

## Co-locating components

Another interesting feature of the Next.js app directory is the ability to co-locate components with your pages. As you can see, we define the directory `components` close to where they're used, such as near the `auth` pages. 

In this way, we can easily see which components are used by which pages, and we can easily move them around if we need to.

Given we have `shared` components, we can also define a `components` directory at the root of the app directory, which will be shared across all pages.

## The good parts of the Next.js app directory

The Next.js app directory is a great way to organize your Next.js app. In fact, I quite enjoyed the experience of using it. 

### Layouts

Layouts allow us to define components that wrap your pages and provide a consistent look and feel across your app.

Additionally, layouts also help you to fetch data that is common to all pages in your app, such as the current user, the current organization, and more.

#### Data loading

We can use Layouts for fetching data that is common to all pages in its directory. For example, we can fetch the current user in the `auth` directory, and we can fetch the current organization in the `app` directory, and so on.

In Makerkit, we define "data loaders" such as `loadAppData` and `loadAuthData` that are used to fetch the data that is common to all pages in the `app` and `auth` directories, respectively.

These also perform some validation such as ensuring that the user is authenticated and that the user is part of the organization, and so on. In such cases, we define a `redirect` property that tells the layouts not to proceed and redirect somewhere instead.

Let's see the loader for the authentication pages:

```tsx
import getSupabaseServerClient from '~/core/supabase/server-client';
import configuration from '~/configuration';

const loadAuthPageData = async () => {
  try {
    const client = getSupabaseServerClient();

    const {
      data: { session },
    } = await client.auth.getSession();

    if (session) {
      return {
        redirect: true,
        destination: configuration.paths.appHome,
      };
    }

    return {};
  } catch (e) {
    return {};
  }
};

export default loadAuthPageData;
```

Now, let's use the loader above in the `auth` layout:

```tsx
import { use } from 'react';
import { redirect } from 'next/navigation';

import loadAuthPageData from '~/lib/server/loaders/load-auth-page-data';
import Logo from '~/core/ui/Logo';
import I18nProvider from '~/i18n/I18nProvider';

function AuthLayout({ children }: React.PropsWithChildren) {
  const data = use(loadAuthPageData());

  if ('redirect' in data && data.destination) {
    return redirect(data.destination);
  }

  return (
    <I18nProvider>
      <div
        className={
          'flex h-screen flex-col items-center justify-center space-y-4 md:space-y-8 lg:bg-gray-50 dark:lg:bg-black-700'
        }
      >
        <div>
          <Logo />

          {children}
        </div>
      </div>
    </I18nProvider>
  );
}

export default AuthLayout;
```

As you can see, we:
1. fetch the data
2. if the data contains a `redirect` property, we redirect to the destination (for example, when the user is already logged in)
3. otherwise, we render the children (such as the sign-in page, etc.)

The other layouts will work in a very similar way.

### The new Next.js Route handlers

Next.js has also released an alternative way to define API routes, using the new Route handlers. This new API is still experimental and will replace the "old" `pages/api` API handlers.

Let's take a quick look at the new API handlers. We have added a new directory called `api` that contains the API handlers. To define a route, we create a directory within `api` and create a file called `route.ts`.

For example, we create a route handler for the `/api/stripe/checkout` route:

```tsx title="app/api/stripe/checkout/route.ts"
export async function POST(
  req: Request
) {
  const payload = await req.text();

  /// handle webhook here

  return NextResponse.json({
    success: true,
  });
}
```

As you can see we can define the method handlers by simply exporting the method name using its uppercase form. For example, we can define a `GET` handler by exporting a `GET` function.

```tsx
export async function GET(
  req: Request
) {
  const data = await getData();

  return NextResponse.json(data);
}
```

While I have created a folder named `api` which looks a lot like the `pages/api` directory, it is important to notice that you can co-locate API handlers with your pages, for example, you can create a `checkout` directory in the `app` directory and create a `route.ts` file there and execute a request against the `/app/checkout` route.

In my opinion, it can still be useful to define API handlers in a separate directory, such as the `api` directory, as it allows you to define API handlers that are not part of your app, such as the `stripe` API handlers. This is just my preference at this time, and it can likely change in the future.

## Difficulties with the Next.js app directory

While everything has been generally smooth, there have been a few difficulties with the Next.js app directory.

### i18n

At this time, the biggest difficulty with the Next.js app directory has been i18n using `i18next`. I have been able to get it working, but it has been a bit of a struggle. 

The examples online are either lacking or simply don't work, and I have had to spend a lot of time trying to figure out how to get them working.

### Mutations

Next.js is still working on mutations, which will likely allow us to define mutations in the same way we define API handlers, and automatically refresh the loaders when the mutations are executed, similar to how Remix works.

To work it around for the time being, mutations are executed using fetch requests wrapped with `useMutation` from `swr`, and manually calling `router.refresh` when the mutation succeeds. Ideally, we will be able to remove the `router.refresh` call once mutations are supported.

## Conclusion

The Next.js Supabase SaaS kit is slated to be released in March, and I am very excited about it. Do you have any questions about the kit? Let me know! 

If you want, sign up for the newsletter to be notified when the kit is released.

Ciao!

A sneak peek at the Supabase and Next.js RSC SaaS kit


Originally, Makerkit was built using Headless UI, a set of headless components built by the Tailwind team.

It was a great choice for a project like Makerkit, as it allowed us to build a UI library that was completely customizable, and that could be used in any project.

However, as Makerkit grew, we started to notice some limitations with Headless UI, highlighted by the fact many members of the community were asking for more components or to use Radix UI instead.

As a result, we decided to migrate Makerkit to Radix UI, a set of React UI components built the Modulz team, now at Work OS.

## Why Radix UI?

[Radix UI](https://radix-ui.com) is a rich headless UI library that comes with many primitive components by default, with a strong focus on accessibility and usability. Additionally, it plays well with Tailwind CSS, which is a big plus for us.

Many of the components we added are an adaption of the [Shadcn UI kit](https://ui.shadcn.com/): a set of React UI components that are pre-styled with Tailwind CSS. If are planning on adding more components, I recommend you check it out.

## What's new?

The new components added are:

- Dialog
- Dropdown
- Tooltip

As a result, we also removed some libraries such as Tippy, since no longer needed.

## Preview

Below is a quick preview of some of the components we added to the Makerkit kits.

### Select

Here is a preview of the new Select component - as shown in the Makerkit's Organizations selector:

<Video src="/assets/images/posts/radix-select-example.mp4" />

### Tooltip

We've removed Tippy in favor of the Tooltip component from Radix UI:

<Video src="/assets/images/posts/radix-tooltip-example.mp4" />

### Dialog

The new Radix dialog behaves similarly to the previous one, but it's more customizable and has a better look and feel:

<Video src="/assets/images/posts/radix-dialog-example.mp4" />

### Other components

Now that we're using Radix UI, you can easily add more components to the library.

Install the library that you need and use the primitives using Radix UI, then follow the same conventions for decorating the primitives with Tailwind CSS.

## Credits: Shad CN UI Template

A big thanks to [Shad CN](https://twitter.com/shadcn) for creating the [UI Template](https://ui.shadcn.com/) that we used as a base for the new components and adapted to the Makerkit look-and-feel.

My recommendation to clients wanting to build new components using Radix UI is to check out the UI Template, as it's a great starting point for decorating the Radix primitives using Tailwind CSS and re-exporting them.

Makerkit ❤️ Radix UI


I am super happy to announce the new design for the Makerkit subscriptions pages. This includes both a new dynamic pricing table and a much-improved subscription management page.

In this blog post, I want to introduce the new design and explain why we made the changes shipped today.

## The new pricing table

The new pricing table introduces the ability to have multiple plans with multiple variations. For example, you could have 3 different plans (Basic, Pro and Enterprise), each with a monthly or an annual price.

<Image src='/assets/images/posts/pricing-table.webp' width="2832" height="1884" />

The dynamic variant switcher will automatically show the prices for the selected variant.

### Configuring the plans

Below is how to configure the new Makerkit's configuration for Stripe:

```ts
stripe: {
  products: [
    {
      name: 'Basic',
      description: 'Description of your Basic plan',
      badge: `Up to 20 users`,
      features: [
        'Basic Reporting',
        'Up to 20 users',
        '1GB for each user',
        'Chat Support',
      ],
      plans: [
        {
          name: 'Monthly',
          price: '$9',
          stripePriceId: 'basic-plan-mth',
          trialPeriodDays: 0,
        },
        {
          name: 'Yearly',
          price: '$90',
          stripePriceId: 'basic-plan-yr',
          trialPeriodDays: 0,
        },
      ],
    },
    {
      name: 'Pro',
      badge: `Most Popular`,
      recommended: true,
      description: 'Description of your Pro plan',
      features: [
        'Advanced Reporting',
        'Up to 50 users',
        '5GB for each user',
        'Chat and Phone Support',
      ],
      plans: [
        {
          name: 'Monthly',
          price: '$29',
          stripePriceId: 'pro-plan-mth',
          trialPeriodDays: 0,
        },
        {
          name: 'Yearly',
          price: '$200',
          stripePriceId: 'pro-plan-yr',
          trialPeriodDays: 0,
        },
      ],
    },
    {
      name: 'Premium',
      description: 'Description of your Premium plan',
      badge: ``,
      features: [
        'Advanced Reporting',
        'Unlimited users',
        '50GB for each user',
        'Account Manager',
      ],
      plans: [
        {
          name: '',
          price: 'Contact us',
          stripePriceId: '',
          trialPeriodDays: 0,
          label: `Contact us`,
          href: `/contact`,
        },
      ],
    },
  ],
}
```

There are various options available, such as:

1. Adding a custom label using the `label` property in each plan. Useful, for example, if you want to add a "Contact us" button instead of a "Checkout" button.
2. Adding a custom link using the `href` property in each plan. Useful, for example, if you want to link to a contact form instead of a checkout page.

## The new subscription management page

The new subscription management page is a much-improved version of the previous one. 

It now includes a much better overview of the current subscription. Thanks to granular labels and descriptions, you can now show the exact state of the subscription.

Furthermore, we simplified the plan selector by reusing the same pricing table used on the pricing page.

### Plan selector

The old plan selector has been removed. Instead, we now use the pricing table from the pricing page. This makes it easier to understand the different plans and variants when picking a plan from within the subscription management page.

<Image src='/assets/images/posts/plan-selector.webp' width="2832" height="2024" />

### Subscription Status

The subscription status has been improved to show the exact state of the subscription. This includes the current plan, the current status, the next billing date, and whether the subscription is set to be renewed automatically.

Furthermore, unless the subscription is active, users will now see a badge in the top-right corner of the page to indicate the current status of their subscription.

<Image src='/assets/images/posts/subscription-status.webp' width="2844" height="2024" />


## Conclusion

I am super excited about the new design for the Makerkit subscription pages. I hope you like it as much as I do. 

If you have any questions or feedback, please let me know!


Changelog: New Stripe Subscriptions Pages


## A quick retrospective on 2022

2022 has been particularly busy: I released two kits based on Next.js/Remix and Firebase, and am about to release a third based on Remix and Supabase. Additionally, I wrote over 60 blog posts for this website and dozens of documentation pages for the kits.

While it started out as a side project mostly for fun, Makerkit is now used by over 60 customers, many of which I support directly: **I cannot thank you enough for your support and feedback**.

## A plan for 2023

Next year, I have fairly big plans for Makerkit. 

From a product perspective, I plan to focus on the following:

1. **Upgrading the Next.js kit to the app directory**: this is a big change, but will make the kit even better and faster
2. **More kits**: I plan to release a kit based on Next.js/Remix and Supabase. After having completed the combos Next.js/Remix/Firebase/Supabase, I want to release kits for other technologies, such as **React Native** and a **Shopify App Kit**.
3. **Shopify Storefront**: Once Shopify Hydrogen is ready, I'd like to release an eCommerce template for storefronts. Since I'm familiar with Remix these days, I'm hoping it to be super fun.
4. **More blog posts**: I plan to write more blog posts about the kits, and the technologies I use. I feel like the greatest value I can provide is by sharing my knowledge and experience with others, which alongside the kit, can help you build your own products.
5. **More documentation**: I plan to write more documentation for the kits. Too many kits often assume that you know how to use the technologies they're built on, which is not always the case. I want to make sure that the kits are accessible to everyone, and that you can build your own products with them.

## Courses?

I've been thinking about releasing a few courses on Makerkit or building a SaaS in general, but I'm not sure where to start. 

I'd love to hear your thoughts on this.

## A micro SaaS?

Of course, I'd also love to release a few micro SaaS so that I can validate the kits and ensure I dogfood every template I build: this is the only way I can ensure that the kits are the best possible products they can be.

## And you?

What about you? What are your plans for 2023? 

Send me a message on Twitter or Discord, I'd love to hear from you! 😊

Planning Makerkit's 2023


We are excited to announce the Makerkit UI Storybook. This is a collection of all the components that make up the Makerkit UI. You can use this to see how the components work and to get inspiration for your own projects.

## What is Storybook?

Storybook is an open source tool for developing UI components in isolation, which can improve component reuse, testability, and development speed. It allows you to browse a component library, view the different states of each component, and interactively develop and test components.

## Where can I find the Makerkit UI Storybook?

You can find the Makerkit UI Storybook at [https://ui.makerkit.dev](https://ui.makerkit.dev).

It still early days for the Makerkit UI, so I am
working hard on writing more documentation and examples so to help you use
the Makerkit components in your projects.

If you have any suggestions for components you would like to see, please let us know in the Makerkit Discord.

## What will you be working on next?

My goals for the Makerkit UI are to:
- providing a more consistent and accessible UI for all the kits
- document all the components and how to use them in a better way, and I do
think the Storybook will greatly help with this
- break more components into many smaller components, so that they can be
used in more places and be more flexible
- ultimately, adding more components to the Makerkit UI, so to be a
standalone UI kit

## Conclusion

I hope the Makerkit UI Storybook can be helpful in its current state already.
If you have any questions or suggestions, please let us know in the Makerkit Discord.

Ciao!


Introducing the Makerkit UI Storybook


Hi there! Since version 0.4.0, we worked hard on providing improvements to
the overall look and feel of the application, we reduced the bundle's size
by tweaking the Firebase tree-shaking configuration, minor fixes, and added
one of the latest change to Firebase Storage that helped us reduce
complexity in certain parts of the codebase.

## 1) Design Improvements

The biggest design changes affected the authentication pages.

1. The overall background has a darker shade
2. Smaller gap between controls

<Image src='/assets/images/posts/auth-0.5.0.webp' width={"1346"} height=
  {"1596"} />

Furthermore, we updated the `Sidebar` layout to take the full space of the page:

<Image src='/assets/images/posts/sidebar-layout-0.5.0.webp' width={"2738"}
       height={"2056"} />

## 2) Bundle Size reduction

Because of a bug in either Reactfire or Next.js, tree-shaking isn't working
correctly when importing Reactfire.

To work it around, we added a list of externals to the webpack configuration,
which helped us **shave off at least 50kb** from the production bundle!

## 3) Firestore rules in Firebase Storage

Using [Firestore rules in the Firebase storage rules](/blog/tutorials/firestore-storage-rules)
helped us reduce the complexity of the code for handling group security.

In fact, to restrict
users from reading and writing only to the organizations they're part of, we
needed to use custom claims, and update them every time the user changed
organization.

Thanks to the new updated, we were able to clean up a lot of
code and simplify the whole process. Cheers, Firebase team!


v0.5.0: Design Improvements and code-cleanup


The new version 0.4.0 dropped some more cool stuff, such as:

- ✅ **Phone number** authentication 🚀
- ✅ Ability to **link a phone number** once signed up
- ✅ Ability to **update a phone number** from the profile page
- ✅ Authentication pages design overhaul
- ✅ Added **dynamic sign-in/up page** based on configuration
- ✅ Added oAuth providers logos

Let's take an in-depth look!

## Phone Number Authentication

We can easily add phone number authentication by tweaking the global
configuration:

```tsx
auth: {
  providers: {
    emailPassword: false,
    phoneNumber: true,
    emailLink: false,
    oAuth: [GoogleAuthProvider],
  },
},
```

And the result will be the below:

<Video src='/assets/images/posts/phone-number-auth.mp4' />

Once enabled, we will be able to tweak the configuration in multiple places,
such as the `Authentication` tab:

<Image alt='Auth providers linking'
       src='/assets/images/posts/auth-providers-linking.webp' width={'1167'} height={'994'} />

Additionally, the phone number can be added or removed from the user's
profile page:

<Video src='/assets/images/posts/add-remove-phone-number.mp4' />

## Dynamic Auth Configuration

By tweaking our global configuration, we can easily choose the
authentication providers we want to use. For example, by choosing the below,
we will enable `Email Link authentication`, `Google Auth` and `Facebook Auth`:

```tsx
auth: {
  providers: {
    emailPassword: false,
    phoneNumber: true,
    emailLink: true,
    oAuth: [GoogleAuthProvider, FacebookAuthProvider],
  },
},
```

<Image src={'/assets/images/posts/dynamic-auth-config-example.webp'}
       width={'2336'}
       height={'1980'}
       alt='Dynamic Auth configuration' />

### Updating your Makerkit codebase

To update your Makerkit codebase, run the following command:

```
git pull upstream main --allow-unrelated-histories
```

And then, solve the conflicts you will likely encounter.

🎉 That's it for version 0.4.0. Time to update your applications!


v0.4.0: Phone Authentication


The 0.3.0 release is the biggest update to Makerkit yet. The main highlights of the release are:

1. Support for **Firebase Multi-Factor Authentication**
2. Support for **linking user accounts to multiple providers** (Facebook, Twitter, Etc.)
3. Redesigned the home page of the website

Let's take a look!

## Support for Firebase Multi-Factor Authentication

Multi-Factor Authentication allows users to add an additional layer of protection when logging in to a website, which is ideal for services that tend to be more sensitive or where privacy is paramount. 

At the time of writing, Firebase Auth supports only SMS MFA.

### Enabling Multi-Factor Authentication

Enabling MFA in your Makerkit application requires two steps:

1. You need to upgrade to Google Cloud Identity Platform from the Firebase Console, as it is needed to support MFA
2. Flipping the variable `auth.enableMultiFactorAuth` to `true` in the configuration file, as it is disabled by default

```tsx title="configuration.ts"
auth: {
  // flip this to "true"
  enableMultiFactorAuth: true,
}
```

Let's see what MFA looks like in Makerkit!

### Verifying Emails as a requirement for MFA

Enabling MFA will require users to have their email verified. In case they haven't, we will show an alert prompting them to verify their email.

<Video src="/assets/images/posts/send-email-verification-link.mp4" />

### Enabling Multi-Factor Authentication with Phone Number

Once the user's email gets verified, we will see a button for setting up MFA.

<Video src="/assets/images/posts/enabling-multi-factor-authentication.mp4" />

### Authentication with SMS verification code

Once enabled MFA, users will be required to use the verification code sent to the phone number they registered in various situations:

- when they sign-in
- when they reauthenticate (eg. when they update their password, or their email, or perform certain actions that require a recent sign-in)

<Video src="/assets/images/posts/authenticate-with-phone-number-mfa.mp4" />

### Disabling Multi-Factor Authentication

Once set up, users have the choice to disable Multi-Factor Authentication. After disabling, they're required to reauthenticate.

<Video src="/assets/images/posts/disable-mfa.mp4" />

## Support for linking user accounts to multiple providers

Assuming your SaaS allows your users to sign in using multiple providers, such as Password, Google Sign-in, Twitter Sign-in, you can allow them to link their account to other accounts, so they have more choices for signing in (or if they simply want to replace how they sign-in, without having to waste support time).

<Video src="/assets/images/posts/linking-account.mp4" />

## Redesigned the home page of the website

The home page of the website has been redesigned and enriched with more sections.

<Video src="/assets/images/posts/home-page-redesign-0.3.0.mp4" />

Well, that was quite a bit of stuff! 😅

v0.3.0: Multi-Factor Authentication and Multi-Provider accounts


The newly released version 0.2.0 adds the ability for the owners of an organization to transfer ownership to another member of the organization.

Check out the video below for a quick demo:

<Video src="/assets/images/posts/transfer-ownership.mp4" />

When the owner of an organization transfers the ownership to another member, the owner's account will automatically be turned into an `Admin` account.

<Alert type='warn'>
You will need to update the code if you have added custom roles, eg. if you replaced the "Admin" role with another one.
</Alert>

Furthermore, I strengthened some checks around the ability to remove members from an organization and update a member's role:

```tsx
function assertUserCanUpdateMember(params: {
  organization: Organization;
  currentUserId: string;
  targetUserId: string;
}) {
  const members = params.organization.members;
  const currentUser = members[params.currentUserId];
  const targetUser = members[params.targetUserId];

  if (!targetUser) {
    return throwNotFoundException(`Target member was not found`);
  }

  if (!currentUser) {
    return throwNotFoundException(`Current member was not found`);
  }

  if (currentUser.role <= targetUser.role) {
    return throwUnauthorizedException(
      `Current member does not have a greater role than target member`
    );
  }
}
```

The function above can be reused when a user is performing an action that affects another user. 

Generally, we use user roles hierarchically, which means if a role is equal to or smaller than another, then it cannot perform an action that affects this user's permissions.


To update your repository, run the following command:

```
git pull upstream main
```

If you encounter too many conflicts while updating, please [feel free to reach out](/contact)!

v0.2.0: Transferring Ownership of an organization


The React Team has finally released React 18 after a long and "suspensful" time.

Developers have long awaited this feature-packed release, which takes Suspense and Concurrent Rendering out of beta, and are now stable for developers to use.

Fortunately, the API has remained relatively stable, except for two main changes:

- the `React.FC` interface has changed, and the `children` property is no longer part of it; this means that we had to apply a different interface to most components
- the hook `useEffect` now runs twice to spot memory leaks

Makerkit is now compatible with the changes above, and you can use it with React 18 for developing your next SaaS.

### Introducing React.FCC

As someone who quite liked the `React.FC` interface, I was slightly bummed by the decision to change it.

As a result, I introduced a new interface, which reflects the old `React.FC`:

```tsx
declare module 'react' {
  type FCC<Props = Record<string, unknown>> = React.FC<React.PropsWithChildren<Props>>;
}

const MyComponentWithChildren: React.FCC<{
    body: string;
}> = ({ body, children }) => {
    //...
};
```

It can be read as React Functional Component with Children.

### What about Suspense?

While Suspense is now stable, Makerkit hasn't yet adopted it, but it's very
high on our list before our final version is out.

### Packages Update

Nearly all the packages got a version bump:
 - Pino was updated to the recently released version 8
 - Stripe as update to version 9.6.0
 - Cypress was updated to version 10
 - Many, many minor bumps to all the packages

We're working hard towards a stable release. Stay tuned :)


Makerkit upgraded to React 18


Hey everyone, happy new year!

Here at MakerKit, I started my 2022... making, of course!

More specifically, I improved MakerKit to support payments and
subscriptions using Stripe Checkout!

The last time I had used Stripe, the Checkout product was still unavailable:
it is incredible the amount of work it can save developers.

As incredible as is, Stripe Checkout cannot do everything for you. This is where
MakerKit jumps in.

At MakerKit, I wanted to make it dead-easy to define your Stripe plans,
automatically create a plan selector, and enable your app to
handle the webhooks received by Stripe to update your application's database
accordingly.

With this release, this is all possible.

## Defining the Plans

After having added and configured the plans in
Stripe, we do the same in your application.

We're going to add the plans to the `~/configuration.ts` file, which is
where we store most of our application's config:

```tsx title="configuration.ts"
plans: [
    {
      name: 'Basic',
      description: '3 users and 10 todos',
      price: '$249/year',
      stripePriceId: '<STRIPE_PRICE_ID>',
    },
    {
      name: 'Pro',
      description: 'Unlimited users and todos',
      price: '$999/year',
      stripePriceId: '<STRIPE_PRICE_ID>',
    },
  ]
```

These are already configured to work with the `PlanSelector.tsx` component,
which pulls the plans from the configuration and creates a checkbox with the
data entered.

It's going to look similar to the below:

<Image
  layout={'responsive'}
  width={'2390'}
  height={'1610'}
  src={'/assets/images/posts/stripe-plan-selector.webp'}
/>

You can select a plan by clicking on one and then proceeding by clicking on
"Continue to Checkout".

<Video src={'/assets/images/posts/stripe-plan-selector-video.mp4'} />

## Checkout

Once a plan gets selected, the user can then continue to Stripe Checkout,
which is a page hosted and managed by Stripe.

Once selected and subscribed to plan the user gets redirected back to the
subscription page.

<Video src={'/assets/images/posts/subscribe-to-plan.mp4'} />

## Billing Portal

Once the user has subscribed, they should also be able to perform the
following actions:

- cancel the plan
- update to a new plan
- update payment method
- see previous invoices

Thankfully, the Stripe Portal can handle most of these for us!

The application's side (MakerKit) takes care of handling the webhooks sent
by Stripe when the user takes any of the actions above.

<Video src={'/assets/images/posts/billing-portal.mp4'} />

In the video above, the user accessed the Stripe billing portal, canceled their
plan, and then went back to the subscriptions page.

The user can now pick a plan again or visit their Billing Portal (as we
now can identify the user with a Stripe ID), so that they can manage their
billing settings directly from the customer portal.

## Documentation

Check out <a href="/docs/stripe-configuration">the documentation for setting up
Stripe and MakerKit</a>.

Thank you for reading so far! If you have any questions, please <a
href="/contact">contact us</a>.
