b2b-saaskit: an Astro starter kit for products whose customer is a team

The customer is an organisation, and that is the whole premise

The kit is an open source starter toolkit for developers who want to stand up a SaaS product quickly where the customer can be a team of users, in other words a business.

The B2B framing is taken seriously rather than used as a label. In the simplest terms given in the documentation, a B2B product is one where after signing up a user can create an organisation, invite others, and do something as a team. The documentation also notes that B2B companies are fairly common, with over 40% of Y Combinator funded startups self-identifying as B2B, and that B2B specific starter kits appear to be quite rare, which is the stated reason for the effort.

That premise decides the shape of everything else. A starter kit for single user products can leave multi tenancy to you, because you can add an account id column later. A kit for B2B products has to model organisations, membership and invitations from the first migration, and that is exactly the part most people get wrong when they start from an empty repository.

The two design goals are stated plainly. Start with a fully functional, relatively complex application and then modify it to become your own product. And be able to build an app to validate your idea for the cost of a domain name, because all the third-party services used by the kit offer meaningful free-forever starter plans.

Three services are required and four more are optional

The kit is TypeScript, Astro, React and Tailwind CSS, and then it leans on a set of hosted services for the parts that are essential but peripheral to a product: secrets management, user authentication, a database, product analytics, customer support, payments and deployment infrastructure.

Three of them are required. Doppler handles secrets, Supabase is the database, and PropelAuth handles user authentication, with the PropelAuth base elements, node and react packages in the dependency list. You cannot run the kit without accounts for these three.

Four more are optional. Stripe for payments, Vercel for deployment, Fogbender for customer support and PostHog for product analytics, with the posthog-js and posthog-node packages in the manifest. The repository also uses tRPC for the API layer, Drizzle ORM for the database, and Prettier and ESLint for formatting and linting.

The consequence is worth stating before anyone starts: this is a kit that is wired to a specific set of vendors. The value is that those decisions have been made coherently, and the cost is that the first thing you might want to change, say the database or the identity provider, is also the thing the kit is most opinionated about.

The free-forever starter plan assumption is what makes the cost of validating an idea a domain name, and it is also the assumption most likely to break first, when usage grows past a hobby project's traffic.

Getting the example app onto your laptop

The documentation walks a specific order, and the first step is to look at the example rather than the framework. Prompts with Friends is a real application built with the kit, a way to collaborate on GPT prompts with others, and the plan is to check it out, get your own copy running locally, learn how to deploy it, and only then start building your own product by modifying the app.

The prerequisites are Node.js 22.14 or Node.js 24, and Corepack, which pins pnpm 10 from the packageManager field. There is a detail worth catching here: Node 24 still bundles Corepack as experimental, and Node 25 and later do not ship it, so the instruction is to install it first with npm i -g corepack.

The clone and start sequence is:

git clone https://github.com/fogbender/b2b-saaskit.git
cd b2b-saaskit
corepack enable
corepack install
pnpm install
pnpm dev

Then you open http://localhost:3000 in a browser tab and should see a page titled Welcome to Prompts with Friends. The detailed configuration instructions live on http://localhost:3000/setup, and once you have been through them you should have a working copy of the application on http://localhost:3000/app.

That setup page being part of the running app is a deliberate choice. The configuration steps for the seven hosted services are long, and running them as a page inside the app means the instructions match the version of the code you actually have.

Drizzle migrations need a hand written security policy

Database migrations are managed with Drizzle ORM, and the documentation is unusually specific about a step that is easy to miss.

A schema change starts in src/db/schema.ts, and it affects only the TypeScript code, not the actual table data. So a new table does not exist in the database until a migration runs, and accessing it before that gives you a runtime error.

Drizzle migrations happen in two steps. The first generates a migration file:

doppler run pnpm drizzle-kit generate

That produces a file with a name like src/db/migration/1234_xyz.sql containing the auto-generated SQL that applies the changes from schema.ts to the database. Under normal circumstances you would not need to touch it, but since the kit uses Supabase Postgres, the Row Level Security policies have to be added by hand for new tables. The documentation gives the exact statements to append, with the table name changed:

ALTER TABLE example ENABLE ROW LEVEL SECURITY;
CREATE POLICY "service" ON "public"."example" AS PERMISSIVE FOR ALL TO service_role USING (true);

The migration is then applied with:

doppler run pnpm migrate

And a note that catches people: migrating your development database does not migrate production. For that you run migrate with the production configuration, doppler run pnpm migrate --config prd.

Two things are visible in those commands. The secrets for the database connection come from Doppler rather than from a local file, so migrations need a Doppler context. And the production path is a separate configuration, which is the safer default, since it stops a development run from touching production by accident.

tRPC for the API, Drizzle for the data, and the ORM you would rather have

The choice of tRPC for the API part of the app comes with its reasons spelled out: its integration with TanStack Query, formerly React Query, and with Zod sealed the deal, because the team considered ease of refactoring and type safety very important for a codebase that is meant to be heavily modified.

That is the right reason for a starter kit. The code you get is code you will break and rebuild, and the value of tRPC here is that the client and the server share types, so a change to a procedure breaks the type checker rather than the browser at runtime. The documentation also notes other reasons to like tRPC, including a set of built-in features, and the package list shows the whole stack in place, with @trpc/client, @trpc/react-query and @trpc/server all in the dependencies alongside @tanstack/react-query and its devtools.

The alternative is named too. Drizzle is what the kit uses for migrations, and the documentation points out that Prisma is another popular ORM option, adding that if you would like to use Prisma instead of Drizzle and need help, you can get in touch with the maintainers.

That offer tells you something about the intended shape of the project. The kit is a starting point that is meant to be modified, and swapping the ORM is an anticipated activity rather than a mistake. It also means the Drizzle workflow above, including the manual security policy step, is the path of least resistance rather than a requirement of the architecture.

The scripts tell you what the project considers a passing build

The package manifest is short and gives a clear picture of the working rhythm.

The dev and start scripts both run astro dev, build runs astro build, and preview runs astro preview. The check scripts are the interesting part. ci:check runs astro check and tsc --noEmit, and full:check chains the fix script, then ci:check, then a production build run through Doppler with the prd configuration: pnpm fix && pnpm ci:check && doppler run --config prd pnpm build.

So a full check is not just a type check. It reformats the tree with prettier, runs eslint with the fix script, type checks, and then produces a production build using the production secrets. That is a deliberate bar, and it tells you that the project expects the same command to work locally and against production configuration.

The lint configuration is strict in the same spirit: eslint with --max-warnings 0 and --report-unused-disable-directives, so a warning is a failure and a disabled rule that is no longer needed is reported. The migrate script runs tsx src/db/scripts/migrate, and the astro script is a shortcut for the Astro CLI.

The dependencies describe the front end as well: Astro 5.1.8 with the React and Vercel integrations, React 18.3.1, react-router-dom, jotai for state, clsx, cookie and js-cookie, nanoid, jsonwebtoken, @t3-oss/env-core for environment validation, @resvg/resvg-js for rendering, astro-seo, and the Fogbender React package.

Where the kit stops being the right answer

Three limits are visible in the project itself.

The first is the vendor dependency. Three hosted services are required rather than optional, and the free-forever starter plan is the assumption the cost story rests on. The moment your usage, your team size or your compliance requirements outgrow that assumption, you are migrating services in an application you were also planning to rewrite. That is a real cost, and it arrives earlier for a B2B product, where the paying customer is a company with expectations, than for a hobby project.

The second is that the kit is scaffolding, not a library. It is published as a private package, the version in the manifest is 0.0.1, and there are no GitHub releases, so you take the code and edit it. The point of the exercise is that you are meant to replace most of it, which is also why the deployment guide lives at promptswithfriends.com/setup, in a section on production deployment to Vercel, rather than in the repository.

The third is a detail that a careful reader will notice: the repository root contains a .env file. It is probably a template, but it is worth reading before you copy anything into your own project, and it is the sort of thing that should never be copied verbatim into a repository of your own.

On maintenance, the project is not archived, the last push was on 2026-09-29, and the licence is MIT, so the code is yours to take, modify and ship. What you are really deciding is whether the wiring it gives you saves more time than the rewrites it imposes.

Editorial conclusion

Adopt b2b-saaskit if you are building a B2B product where the customer is an organisation with several users, you want the authentication, database, payments, analytics and deployment wiring already in place, and you accept that the kit is a starting point you will rewrite rather than a dependency you will import. Do not adopt it if you need to own the database, the authentication or the deployment, since three hosted services are required rather than optional. Verify first that the free starter plans of the services it depends on fit your expected usage, that the Node and Corepack versions in your environment match what the setup assumes, and that the row level security policies are added to every new table, since the migration step does not do it for you.

Frequently asked questions

Official sources

1. fogbender/b2b-saaskit on GitHub
2. Issues
3. License: MIT
4. Project website
5. README