Set up Codapult locally, choose the right modules, connect auth, billing, database, email, analytics, and prepare your SaaS for launch.
Codapult is not meant to be a blank Next.js starter with a pricing page attached. It is a modular SaaS foundation: auth, billing, teams, admin workflows, AI, email, docs, analytics, feature flags, infrastructure, and test coverage are already wired together.
This guide walks through the first practical setup path: get the app running, decide what to keep, configure the core providers, and verify the product surfaces that matter before you start building custom features.
Screenshot placeholder: local dashboard home with quick actions and populated sidebar.
Install dependencies and copy the environment file:
pnpm install
cp .env.example .env.local
For local development, the simplest database path is LibSQL/Turso with a file URL:
TURSO_DATABASE_URL=file:local.db
DB_PROVIDER=turso
Then push the schema and seed data:
pnpm db:push
pnpm db:seed
Start the app:
pnpm dev
Open http://localhost:3000.
Codapult ships broad because real SaaS products tend to need more than a landing page and a checkout link. That does not mean every module belongs in every MVP.
Keep the default modules when you expect:
Remove or disable modules when they are outside the first customer workflow. The goal is not minimalism for its own sake. The goal is a codebase that starts lean without painting the product into a corner.
Most product flows depend on a reliable user identity. Configure auth before billing, analytics, teams, or admin workflows.
Codapult supports Better Auth and Kinde adapters. For a typical self-hosted setup, Better Auth is the direct path:
AUTH_PROVIDER=better-auth
BETTER_AUTH_SECRET=replace-with-a-long-random-secret
BETTER_AUTH_URL=http://localhost:3000
Then verify:
Screenshot placeholder: sign-in screen and authenticated dashboard after first login.
Do not configure billing as a technical checkbox. Decide your actual packaging first:
Codapult includes billing adapters and subscription tables so the app can support common SaaS billing flows without rewriting database and webhook logic later.
For local testing, set provider credentials only after you have created products and prices in the provider dashboard. Then test these paths:
If your SaaS is B2B, teams and organizations are not optional architecture. They affect authorization, billing, reporting, webhooks, analytics, and support.
Codapult stores:
Even if your first version only has one workspace per customer, model it as an organization now. Retrofitting multi-tenancy after launch is usually more expensive than starting with it.
Before building product-specific features, make sure the operational layer works:
/admin for platform metrics./admin/users for support workflows./admin/subscriptions for billing support./admin/feature-flags for rollout control./admin/activity for audit trails./dashboard/settings for customer self-service./dashboard/billing for plan and seat management.This is the difference between a demo and a product you can operate.
Screenshot placeholder: admin overview with users, active subscriptions, MRR, and sessions.
At minimum, configure:
The best time to add observability is before the first production incident. Codapult includes the plumbing so you can start with useful signals instead of console-only debugging.
Use the project scripts rather than ad hoc commands:
pnpm type-check
pnpm test
pnpm test:e2e
pnpm lint
For a narrow change, run the relevant unit test first, then the broader suite before release. For UI-heavy changes, run Playwright and take screenshots at desktop and mobile widths.
A production-ready launch needs more than vercel --prod:
Codapult includes Vercel, Docker, Terraform, Pulumi, and Helm paths so you can choose the deployment model that matches your team.
After setup, do not start by redesigning the whole template. Build the one workflow your product sells:
Codapult gives you the foundation. Your first custom work should prove the product, not rebuild auth, billing, admin, and deployment from scratch.