ShipFree: a TypeScript SaaS starter with billing and localization

What ShipFree packages for a new SaaS

ShipFree targets developers who want a broad starting point for a subscription or paid web application rather than assembling authentication, database access, payments, email delivery, localization, and monitoring separately. The README describes it as a free alternative to ShipFast. That positioning matters because the repository is not a narrow component library or a SaaS service. It is an application template whose conventions determine how routes, providers, and environment variables fit together.

The documented stack is TypeScript on Next.js 16.1.1, with Bun 1.2.20 declared as the package manager. Better-Auth handles user authentication, while Drizzle ORM and Postgres form the persistence layer. The package manifest also includes Stripe, Polar, Autumn Billing, Dodo Payments, Creem, and related SDKs. Email options include Resend, Postmark, Plunk, and Nodemailer. Sentry configuration files are present at the repository root, and `@sentry/nextjs` appears in `package.json`.

This is useful when a new product needs a complete application skeleton. It is less attractive when the project needs only Next.js and a database: a large provider surface creates decisions about credentials, webhooks, transactional boundaries, and dependencies. ShipFree gives the starting structure, but the README and package manifest do not establish which integrations are production-ready for a particular merchant, country, tax model, or subscription schedule.

Next.js request flow and locale-aware routing

ShipFree uses `next-intl` with automatic locale routing. The README documents English (`en`), French (`fr`), and Spanish (`es`) as the included languages. Its main routes use a locale segment, such as `/fr/about`, while the default English locale uses the `as-needed` prefix strategy and can appear without `/en`. This keeps French and Spanish URLs visible while avoiding a mandatory prefix for the default language.

The file `i18n/navigation.ts` exports wrapped versions of Next.js navigation components and hooks. Its `Link` adds the active locale, `redirect` preserves the locale during server-side navigation, `usePathname` hides the locale prefix from application code, and `useRouter` accepts a locale when replacing the current route. That separation prevents application components from manually constructing every localized URL.

Server and client components use different translation APIs. A server component calls `getTranslations` from `next-intl/server`; a client component calls `useTranslations` from `next-intl`. The namespace and message key shown in the README are examples, so a new application still needs complete translation messages rather than only a few visible strings. The README covers adding a locale by changing routing, creating a message file, and updating the language switcher, which gives an explicit path for extending the supported languages.

Database and application structure in the repository

The repository uses Drizzle ORM with Postgres. `drizzle.config.ts` is present at the top level, while migration commands are defined in `package.json`: `generate-migration`, `migrate:local`, and `migrate:prod`. The example environment defines `DATABASE_URL` for normal application database access and `PROD_DATABASE_URL` for production migrations. Its local example value points to a Postgres database named `shipfree`.

The application code lives under `src/`, while operational and deployment files sit around it. Examples include `docker/`, `vercel.json`, `proxy.ts`, instrumentation files, Sentry configuration files, and framework configuration such as `next.config.ts`, `tsconfig.json`, and `components.json`. The start and development scripts both launch `api.js` before invoking Next.js:

"dev": "node api.js && next dev"

The production script follows the same pattern:

"start": "node api.js && next start"

That ordering shows that `api.js` is part of both development and production startup rather than an optional example file. The README does not explain what responsibilities `api.js` performs, so adopters should inspect it before assuming that a standard Next.js deployment can omit it. For migrations, the repository distinguishes local and production scripts, but the README does not document deployment ordering or rollback behavior.

Installing ShipFree and making the first localized change

The README does not provide a repository clone or dependency installation command. It directs users to the external ShipFree documentation for full setup instructions. The repository declares Bun 1.2.20 in `package.json`, and its `.env.example` says to copy that file to `.env` and fill in the appropriate values. The documented development command is available through the `dev` package script shown below.

"dev": "node api.js && next dev"

For a first real change, replace a page with a locale-aware link. The following example comes from the README and causes `/about` to use the active locale. Passing `locale="fr"` explicitly selects French:

import { Link } from '@/i18n/navigation'

<Link href="/about">About</Link>
<Link href="/about" locale="fr">À propos</Link>

A client component can also navigate without manually adding a locale prefix. This example comes from the README:

'use client'

import { useRouter, usePathname } from '@/i18n/navigation'
import { useLocale } from 'next-intl'

const router = useRouter()
const pathname = usePathname()
const locale = useLocale()

router.push('/dashboard')
router.replace(pathname, { locale: 'fr' })

The first command navigates with the current locale, while the second changes locale for the current path. In the full README component, the router and pathname calls occur inside a React component and are used by event handlers. A new project should preserve that client boundary rather than moving `useRouter` into a server component.

Authentication, billing, and email configuration burden

ShipFree places authentication and monetization close together. `better-auth` is the core authentication package, while the manifest includes payment-related adapters such as `@better-auth/stripe`, `@creem_io/better-auth`, `@dodopayments/better-auth`, and `@polar-sh/better-auth`. The README describes Stripe, Polar, Autumn Billing, Dodo Payments, Creem, and Comet integrations. The visible package excerpt also shows Stripe, Lemon Squeezy, Polar, Autumn, Dodo Payments, and Creem dependencies, but that excerpt is truncated, so it would be unsafe to claim that the current tree supports every named provider equally.

Email delivery also has several paths: Resend, Postmark, Plunk, and Nodemailer are named in the README. That flexibility can reduce dependence on one provider, but it moves work to the adopter. Each selected path requires its own environment configuration, error handling, and verification of webhook behavior. The visible portion of `.env.example` ends before the full provider list, so it cannot serve as a complete setup checklist.

The boilerplate also contains a separate feature for selling the Premium version of ShipFree. According to the README, this uses Stripe Checkout for a one-time purchase, collects GitHub email and Twitter handle information on success, displays a Discord invitation, and tracks purchase state in client-side `localStorage`. The README states that this flow is isolated from billing intended for an application's own customers and gives files to delete if it is unnecessary.

Removing ShipFree's premium-purchase storefront code

The Premium purchase feature is template-specific rather than part of the customer subscription system. The README identifies `app/api/premium-purchase/`, `app/api/webhooks/premium-purchase/`, `app/[locale]/(site)/premium-purchase/`, `lib/premium-purchase.ts`, `lib/premium-purchase/hooks.ts`, and `app/[locale]/(site)/pricing/premium-button.tsx` as files or directories associated with it.

The pricing page must then be edited to remove the `PremiumButton` import and its JSX usage. The relevant environment entries use the `PREMIUM_PURCHASE_` and `NEXT_PUBLIC_PREMIUM_PURCHASE_` prefixes, including `PREMIUM_PURCHASE_STRIPE_SECRET_KEY`, `PREMIUM_PURCHASE_STRIPE_PRICE_ID`, `PREMIUM_PURCHASE_STRIPE_WEBHOOK_SECRET`, `NEXT_PUBLIC_PREMIUM_PURCHASE_STRIPE_PUBLISHABLE_KEY`, and `NEXT_PUBLIC_PREMIUM_PURCHASE_DISCORD_INVITE_LINK`. Any configured endpoint at `/api/webhooks/premium-purchase` must also be removed from Stripe.

This isolation is useful because it offers a documented cleanup path, but deletion alone is not a complete audit. The README says to search `app/[locale]/(site)/pricing.tsx` for a comment beginning with `// Premium template purchase`, then remove the import and button or substitute another handler. A project should also inspect references after deletion because the README does not list every database field, test, route reference, or type that might mention the feature.

ShipFree versus a minimal Next.js SaaS foundation

ShipFree is a broad, opinionated alternative to starting from a small Next.js project. Its approach is to place authentication, Postgres access, payment SDKs, email clients, localization, styling, Sentry integration, and deployment files in one repository. A minimal starter instead adds only the dependencies needed by the first product and postpones provider selection. That approach creates less immediate configuration work, while ShipFree gives more application infrastructure to review before the first deployment.

A concrete difference is locale-aware navigation. ShipFree wraps Next.js routing so links, redirects, paths, and programmatic navigation understand the active locale. A conventional Next.js project may use an ordinary `next/link` and construct locale segments directly in application code. ShipFree's wrapper removes repetitive prefix handling, but it also makes `i18n/navigation.ts` part of the convention that contributors must follow.

Another difference is the payment surface. ShipFree includes multiple provider dependencies and documentation for separate Premium-template checkout code. A minimal starter may begin with one payment library and one webhook route. ShipFree is the better starting point when the intended product is known to need this broad feature set and the team can prune it. It is the wrong foundation when adding many adapters increases security review and dependency maintenance without addressing a current requirement.

Maintenance, releases, and the MIT license

The repository is not archived, and its last push was on 2026-10-13. The repository has no GitHub releases. Consequently, there is no published release cadence in the repository record from which to infer upgrade stability. The package manifest identifies the application as private with version `0.1.0`, even though the project is described as open source and distributed under the MIT license.

The declared Bun version is `[email protected]`. Upgrading that runtime or moving across major versions of Next.js, Better-Auth, Drizzle ORM, Stripe, and the other SDKs can require source changes that cannot be quantified from the package manifest. The project also includes migration scripts for local and production environments, which gives it a database change path, but the README does not document migration rollback.

The MIT license permits use, modification, distribution, and sublicensing subject to its conditions, including retention of the copyright and license notice. It does not grant rights to third-party services, provider names, trademarks, or external assets. Provider accounts and SDK licenses remain separate matters, so the repository license should not be treated as covering every operational dependency.

Editorial conclusion

ShipFree is appropriate for a developer who wants to start a TypeScript SaaS with authentication, database tooling, billing providers, email delivery, and locale-aware routing already represented in the repository. It is less suitable for a small application that needs only a few dependencies, or for a team that does not want to review several payment integrations and remove unused template commerce code. Before adoption, verify the current ShipFree documentation, configure the required values in `.env`, and inspect the selected authentication and payment providers in `src/`.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. revokslab/ShipFree on GitHub