NextStarter

Boilerplates are easy to start and hard to justify. There are dozens of Next.js starters, most of them a package.json and a README, and the two things that separate a useful one from a dead repo are both unglamorous: it has to still build a year later, and it has to be honest about what it gives you.

So I set two constraints before writing any code. Accessibility would be verified by tests rather than claimed in a feature list, and every third-party integration would be optional. The app had to build, run and pass its full test suite without any API keys at all. Both constraints are the kind you cannot retrofit, which is why they came first.

Almost every starter in this category lists accessibility as a bullet point. Practically none of them test it, which means the claim decays the moment someone adds a component.

NextStarter scans every page with Axe-core inside the Playwright suite, in light and dark mode, on every run. A contrast regression or a missing label fails CI the same way a broken import would. The project targets WCAG 2.1 AA, and the tests are what keep that true rather than aspirational.

The same suite runs across Chromium, Firefox and WebKit. Rendering differences between engines are exactly where accessible markup quietly stops being accessible, so testing one browser would have undercut the point.

The usual failure mode of a batteries-included starter is that it only works once you have signed up for six services. Delete the parts you do not want and you unravel the rest of the app; leave them in without keys and the build breaks.

Every integration in NextStarter is gated behind an environment variable. With no keys configured the app builds, runs and passes CI; the features you have not set up render a tidy "not configured" notice instead of a stack trace. Adding a key is what turns each one on.

That single decision is what makes the codebase pleasant to inherit. Each integration is self-contained enough to leave switched off forever or to delete outright, and nothing else notices.

• Authentication — Clerk, with protected routes and user sync
• Database — Prisma and PostgreSQL, with a real user-owned CRUD example
• Payments — Stripe subscriptions, Checkout and the customer portal
• Email — Resend and React Email with transactional templates
• Analytics and error tracking — PostHog (cookieless) and Sentry
• Security — CSP and hardening headers, rate limiting, input sanitization

Lite and Pro live in separate repositories, and Pro is built from Lite. Everything in the free tier is in the paid one, unchanged. Framework, theming, accessibility, testing and tooling all come from Lite, and Pro layers the SaaS plumbing on top without altering anything underneath.

Splitting them this way is what lets the foundation stay open source while the paid layer stays behind a purchase. It also keeps the free tier honest. Lite is not a stripped demo built to sell an upgrade, it is the base every Pro project actually stands on, so it has to hold up on its own.

Being a private repository is also how Pro is delivered. Buyers are added to it on purchase, clone it, and take updates with git pull, which lets them keep the starter as a remote across several of their own projects.

Internationalization is where most starters stop at "we included a library." NextStarter ships English, Spanish and Arabic, and the Arabic locale is the point: right-to-left layout is where a component library's assumptions actually surface.

Getting RTL right meant auditing every hard-coded direction in the UI — margins, icon placement, drawer transitions, the sidebar — and replacing them with logical properties. It is the kind of work that is invisible when it is done and glaring when it is not.

A starter kit is also a product, and the marketing site had the same problem the codebase did not: it was technically clean and effectively invisible. Its title tag was a single word, its sitemap held one URL, and the Pro pitch lived at an anchor — which cannot rank, cannot carry its own metadata and cannot be returned for a search.

I ran a full audit, then rebuilt the metadata layer: per-page titles and descriptions, a JSON-LD entity graph, Open Graph images generated at build time, and a dedicated /pro route with its own keyword target so the two pages complement rather than compete with each other.