What I learned building a Next.js SaaS boilerplate for AI coding agents

When I started building Codapult, I wasn't just trying to put authentication, billing, and a dashboard into a Next.js starter kit. I wanted a foundation that developers could extend with AI coding agents without gradually losing control of the architecture.

After building a production-oriented Next.js 16 SaaS boilerplate around that idea, a few lessons became clear.

1. Giving an agent access to the codebase isn't the same as giving it the right context.

An agent can read files and generate code, but it still needs to understand how the project is supposed to fit together. Where should business logic live? Which adapter handles payments? How does a module connect to the database? Which conventions must remain intact?

More instructions alone aren't always the answer. The context needs to be structured, discoverable, and close to the actual implementation.

That's why Codapult includes an MCP server and CLI that expose project-specific context and operations to compatible coding agents.

2. Modularity only matters if removing a feature actually removes it.

A lot of starter kits advertise a long list of features. But if you don't need a module, you shouldn't have to keep its routes, schema tables, imports, and dependencies around.

Codapult has more than 70 removable modules. Its setup wizard removes unused module files and their associated wiring rather than simply hiding features in the UI.

This matters even more when an agent is making changes: a smaller, coherent codebase gives it fewer irrelevant paths to navigate.

3. Vendor independence needs to be an architectural property.

Authentication, payments, storage, background jobs, and other infrastructure choices shouldn't dictate the shape of the entire application.

An adapter-first design makes those integrations replaceable. It also makes the architecture easier to reason about because application code can depend on stable interfaces instead of provider-specific details.

The goal isn't to support every provider imaginable. It's to avoid making a single provider an irreversible architectural decision.

4. AI-friendly doesn't mean letting the agent make every decision.

AI coding agents are useful at implementing well-defined changes. They shouldn't have to invent the architecture every time they add a feature.

The foundation should make conventions explicit, expose the right tools, and keep the boundaries understandable. The developer still decides what the system should do and reviews the important trade-offs.

That's the principle behind Codapult: use AI to accelerate implementation while keeping the underlying system understandable and under your control.

I'm still refining the balance between flexibility, useful defaults, and the amount of structure a new SaaS project actually needs.

For those building SaaS with Cursor, Claude Code, Codex, or other AI coding agents: what has caused more friction in your projects - missing project context, inconsistent architecture, or the maintenance cost of the generated code?

Codapult: https://codapult.dev