{"slug": "ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit", "title": "AI Can Write the SaaS. It Still Doesn't Decide How the Pieces Should Fit.", "summary": "Codapult is a Next.js 16 SaaS foundation built around 70+ removable modules and adapter-based boundaries for authentication, payments, storage, background jobs, notifications, embeddings, and vector storage, according to its creator. The project uses MCP context and explicit architectural seams so AI coding agents can add features like Stripe, authentication, or AI chat endpoints without scattering provider-specific code through business logic. Payments can be swapped between Stripe, LemonSqueezy, or Polar, and job processing between in-memory and Redis-backed implementations, via configuration.", "body_md": "Why Codapult was built around modules, adapters, explicit boundaries, and MCP context instead of another pile of starter files.\n\n*Why I built Codapult around modules, adapters, and explicit boundaries instead of another pile of starter files.*\n\nAI has changed what it means to start a SaaS project.\n\nA few years ago, getting authentication, billing, a dashboard, email, background jobs, AI features, and deployment working together could take a large part of the early development cycle.\n\nNow an AI coding agent can generate surprisingly large parts of that work.\n\nThat is useful.\n\nIt also changed the problem.\n\nThe difficult part is becoming less about writing the individual pieces and more about deciding how those pieces should fit together before the codebase becomes expensive to change.\n\nAn agent can add Stripe.\n\nIt can add authentication.\n\nIt can add an AI chat endpoint.\n\nIt can add a background worker.\n\nIt can add another database table.\n\nEach change can be perfectly reasonable on its own.\n\nThe trouble starts at the seams.\n\nWhere does business logic live?\n\nWhich layer is allowed to talk to the database?\n\nWhere does provider-specific code belong?\n\nHow does billing stay independent from the rest of the application?\n\nWhat happens when you decide to replace Stripe?\n\nWhat happens when the application needs a real job queue instead of an in-memory one?\n\nWhat does the coding agent need to know before it starts making those changes?\n\nThose questions are architectural questions, not code-generation questions.\n\nThat is the problem I wanted Codapult to solve.\n\nThere are plenty of ways to scaffold a Next.js application.\n\nI wasn't interested in creating another repository where you delete a few demo pages, change the logo, and start building.\n\nI wanted the starting point to contain the infrastructure SaaS projects repeatedly end up building, while keeping the boundaries visible enough that an AI agent can work inside them.\n\nCodapult is a Next.js 16 SaaS foundation built around that idea.\n\nThe current project includes 70+ removable modules covering things such as authentication, billing, teams, AI, admin, uploads, jobs, notifications, analytics, content, and more. Optional capabilities are structured as modules rather than being spread throughout the application.\n\nBut the number of modules isn't really the interesting part.\n\nThe interesting part is what happens to them once you start building your actual product.\n\nOne thing I deliberately didn't want was a giant abstraction layer where everything is hidden behind framework-specific magic.\n\nThe project structure is deliberately ordinary.\n\nIt's a Next.js App Router application.\n\nThere is `src/app` for routes, `src/components` for UI, `src/lib` for application logic, `src/config` for configuration, `content` for MDX, and `infra` for deployment infrastructure.\n\nThe useful part is what those directories are allowed to mean.\n\nAPI routes follow a consistent flow:\n\n```\nauth check → rate limit → validation → business logic → response\n```\n\nServer actions validate input and enforce permissions.\n\nAdapter modules expose common interfaces while keeping provider implementations behind them.\n\nThat gives an agent something much more useful than a folder naming convention: it gives it a map.\n\nThis became one of the main design principles behind Codapult.\n\nYour product shouldn't need to know whether authentication happens through Better Auth or Kinde.\n\nYour business logic shouldn't have Stripe calls scattered through it.\n\nYour file handling shouldn't depend on a specific storage vendor.\n\nYour job processing shouldn't force the rest of the application to know whether the implementation is in-memory or Redis-backed.\n\nCodapult uses adapters for these boundaries.\n\nAuthentication, payments, storage, background jobs, notification transports, embeddings, and vector storage all have replaceable implementations selected through configuration. For example, payments can use Stripe, LemonSqueezy, or Polar, while storage can use local storage, S3, or Cloudflare R2.\n\nThe important thing isn't that switching a provider can sometimes be one environment variable.\n\nThe important thing is that the provider decision has a place to live.\n\nThat sounds small.\n\nIt isn't.\n\nOnce provider-specific APIs leak into product code, changing infrastructure becomes a product rewrite surprisingly quickly.\n\nI would rather keep the seam from day one.\n\nThere is another distinction I cared about.\n\nTurning a feature off with an environment variable is useful.\n\nBut it isn't the same as removing it.\n\nCodapult has both mechanisms.\n\nThe setup wizard can remove optional modules before development begins. Removed modules can be stripped from the codebase along with their files, routes, database schema pieces, and imports. Modules that remain can still be enabled or disabled through configuration where appropriate.\n\nThat matters because a SaaS foundation should not force every future product to carry every feature forever.\n\nA project might need teams and billing but not a blog.\n\nAnother might need AI and file uploads but no multi-tenancy.\n\nAnother might only need the public marketing surface initially.\n\nThe goal isn't maximum functionality in the final application.\n\nThe goal is a useful starting point that can become smaller as you make product decisions.\n\nThere is an obvious irony in building a SaaS foundation for AI-assisted development while treating AI as an isolated feature.\n\nI didn't want that.\n\nCodapult has a shared AI application layer rather than having every AI feature talk directly to a model provider in its own way.\n\nThe AI layer covers model routing, embeddings, vector storage, RAG, conversations, tools, agents, guardrails, metering, and batch processing.\n\nThe same principle applies here as it does with payments and storage.\n\nThe application should depend on a stable internal contract.\n\nThe provider should remain at the edge.\n\nThat makes it easier to change models or infrastructure later without teaching every product feature about every provider.\n\nThis is probably the part I care about most now.\n\nAn AI coding agent doesn't work in the same way a human developer does when they join a new repository.\n\nA human can spend a few days learning the structure.\n\nAn agent generally starts by reading whatever context you give it and then making decisions from that context.\n\nSo I wanted the repository to expose its architecture explicitly.\n\nCodapult includes `AGENTS.md`, `CLAUDE.md`, `GEMINI.md`, Cursor rules, and an MCP server so compatible agents can inspect structured project information instead of guessing from a handful of files.\n\nThe MCP server currently exposes 29 tools, 8 resources, and 2 prompt templates for things such as project context, configuration, schema access, checks, plugin management, code generation, and deployment readiness.\n\nI don't see that as a replacement for good code.\n\nI see it as making the codebase easier for an agent to understand before it starts changing it.\n\nThat distinction becomes increasingly important as coding agents take on larger tasks.\n\nAnother thing I didn't want to postpone was deployment architecture.\n\nA starter that works only on one developer laptop is useful for getting started.\n\nIt isn't enough for a SaaS foundation.\n\nCodapult can run on Vercel, but the project also includes Docker, AWS Terraform/Pulumi infrastructure, Kubernetes/Helm templates, external database support, background workers, storage adapters, and observability configuration.\n\nThat doesn't mean every project needs Kubernetes.\n\nIt means choosing not to use Kubernetes is a product decision, not a limitation imposed by the starter.\n\nThe same applies to databases.\n\nThe default setup can be developed locally with a SQLite file and can use Turso/libSQL or PostgreSQL for hosted environments.\n\nAgain, the point isn't supporting every possible infrastructure combination.\n\nThe point is keeping important decisions at explicit boundaries.\n\nNone of this removes the need for tests.\n\nCodapult ships with Vitest for unit and integration tests and Playwright for end-to-end browser tests, with the testing setup already configured.\n\nTests answer an important question:\n\n\"Does this behavior work?\"\n\nArchitecture answers another:\n\n\"Does this change still fit the system?\"\n\nI care about both.\n\nA good SaaS foundation shouldn't try to replace either one.\n\nAfter building all of this, I think of Codapult less as a boilerplate and more as a pre-built set of architectural decisions.\n\nIt gives you a working Next.js 16 application.\n\nIt gives you SaaS primitives that normally have to be assembled one by one.\n\nIt gives those primitives explicit boundaries.\n\nIt keeps infrastructure replaceable.\n\nIt lets you remove what you don't need.\n\nIt gives AI coding agents structured context about the project.\n\nAnd it gives you deployment and testing infrastructure instead of leaving those decisions for some future \"after MVP\" phase.\n\nThe code is still yours.\n\nYou can modify it.\n\nYou can self-host it.\n\nYou can replace the providers.\n\nYou can change the architecture when your product actually requires it.\n\nThe foundation is there to make those changes controlled rather than accidental.\n\nI don't think AI makes SaaS foundations irrelevant.\n\nI think it makes the quality of the foundation more visible.\n\nWhen writing code becomes faster, the cost of making the wrong architectural decision doesn't disappear.\n\nIt can actually become easier to accumulate.\n\nYou can generate ten thousand lines of code very quickly.\n\nYou can also generate ten thousand lines of code that all technically work but don't form a system you want to maintain.\n\nThat's why I built Codapult around the parts that are expensive to reconsider later:\n\nboundaries, adapters, modules, infrastructure, tests, and structured context for the agents writing the code.\n\nAI can generate the implementation.\n\nThe foundation still decides where the implementation belongs.\n\nThat's the part I wanted to make easier.\n\n**Ready to build your next SaaS with AI without drowning in architectural debt?**\n\nExplore [Codapult](https://codapult.dev) to see how an AI-native Next.js 16 foundation keeps your modules decoupled, your adapters flexible, and your AI agents aligned with your architecture. Read the [Codapult Docs](https://codapult.dev/docs) or learn more about our [MCP Server integration](https://codapult.dev/docs/developer-tools/mcp-server).", "url": "https://wpnews.pro/news/ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit", "canonical_source": "https://codapult.dev/blog/ai-can-write-the-saas", "published_at": "2026-10-05 00:00:00+00:00", "updated_at": "2026-10-07 06:17:38.027150+00:00", "lang": "en", "topics": ["ai-agents", "agent-protocols", "developer-tools", "ai-tools"], "entities": ["Codapult", "Next.js 16", "Stripe", "LemonSqueezy", "Polar", "Better Auth", "Kinde", "Redis"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit", "markdown": "https://wpnews.pro/news/ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit.md", "text": "https://wpnews.pro/news/ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit.txt", "jsonld": "https://wpnews.pro/news/ai-can-write-the-saas-it-still-doesn-t-decide-how-the-pieces-should-fit.jsonld"}}