Starting a new Next.js project often means repeating the same setup: package management, application structure, database integration, authentication, testing, linting, and CI.
I wanted a reusable foundation that I could maintain centrally while generating independent projects from known versions.
That led me to build create-clubedge-app.
Why I built it
The goal was to make starting a project repeatable without turning every generated application into a permanently coupled copy of the starter repository.
What the CLI generates
The generated application uses a Next.js App Router monorepo with TypeScript, pnpm, Turborepo, PostgreSQL, Drizzle ORM, Supabase Auth, and automated quality checks.
The exact features and configuration are documented in the starter repository.
Why versioning matters
A generator should make it possible to understand where a project came from.
The CLI records its version and the selected starter reference and commit in the generated project's metadata. This gives developers a concrete starting point when investigating how a project was created.
It does not automatically synchronize future starter changes into an existing application, and it does not guarantee that every generated application is production-ready without further configuration.
Testing the generated project
I tested the published package by generating a project and running its type checks, tests, and production build. Those checks are useful, but they are only one part of validating a developer tool; database integration, authentication configuration, deployment, and browser-level behavior require separate verification.
What I'd like to improve
I'm interested in feedback on the CLI's first-run experience, starter architecture, and the balance between sensible defaults and replaceable providers.
You can explore the project here:
CLI: https://github.com/Clubedge/create-clubedge-app
Starter: https://github.com/Clubedge/clubedge-starter
Website: https://starter.clubedge.live
Top comments (0)