What Payload CMS 3.0 taught me about choosing frameworks that grow with you
Payload CMS 3.0 shipped with native Next.js App Router integration, validating a framework evaluation approach that prioritizes embeddability over feature count.
When Payload CMS 3.0 dropped in November 2024 with native Next.js App Router integration, I had one of those rare moments where a technology bet I made months earlier paid off exactly as hoped. We had chosen Payload over Strapi and Contentful back when it was still in beta for version 3, and the reasoning behind that choice taught me more about framework evaluation than any conference talk or blog post ever has.
This phase is where the title finally started to feel expensive. It also builds on what I learned earlier in “Claude 3.5 Sonnet v2 and the week I mass-refactored our codebase with an AI pair programmer.” Hiring, planning, founder conversations, and bad weeks in production all piled into the same calendar. A lot of the systems thinking I kept in lifeos and flowscape showed up here too: clarity is not paperwork, it is how you stop uncertainty from leaking into people.
The Framework Evaluation Trap
Most framework comparisons focus on the wrong things. Feature checklists, GitHub stars, benchmark numbers, plugin counts. These metrics tell you what a framework can do today. They tell you almost nothing about how the framework will behave when your requirements change in six months.
The question that actually matters is: does this framework embed into my stack, or does my stack have to bend around it? This distinction sounds academic until you are eighteen months into a project and the CMS you chose requires its own server process, its own database, its own deployment pipeline, and its own authentication system that does not talk to yours.
We evaluated three content management options in early 2024. Contentful was the safe enterprise choice with a managed API. Strapi was the open-source incumbent with a mature plugin ecosystem. Payload was the newcomer betting on a deep Next.js integration that was still in beta. On a feature checklist, Contentful won. On community size, Strapi won. On architectural fit, Payload was the only option that did not require running a separate service.
Why Embeddability Matters More Than Features
Payload 3.0 runs inside your Next.js application. Not beside it. Not in a sidecar container. Inside. Your CMS admin panel is a route in your Next.js app. Your content API is a set of server functions in the same process. Your database is the same PostgreSQL instance your application already uses. Authentication flows through the same system.
- One deployment pipeline instead of two
- One database instead of two
- One authentication system instead of maintaining a sync layer
- TypeScript types generated from your content schema that your frontend can import directly
- No API network hop between content and rendering since they share the same process
Every integration point you eliminate is a category of bugs you never have to debug. When your CMS and your frontend share a database, you do not have webhook reliability issues. When they share authentication, you do not have token synchronization bugs. When they share a deployment, you do not have version skew between your content API and your rendering layer.
A Framework Evaluation Rubric
After the Payload decision worked out, I formalized the criteria I had been applying intuitively into a rubric I now use for every significant framework choice.
- Embedding depth: Does it run inside my existing architecture or require its own infrastructure?
- Type boundary: Does it share types with my application or require a translation layer?
- Escape hatch cost: If I need to replace it in two years, how much of my codebase is coupled to it?
- Operational overhead: How many additional processes, databases, or services does it add to my deployment?
- Community trajectory: Is the contributor base growing and is the maintainer financially sustainable?
The first four criteria all point in the same direction: minimize integration surface area. Every framework adds complexity. The ones that age well are the ones that add the least complexity outside their core responsibility.
What I Got Wrong
Payload was not a risk-free choice. We adopted version 3 while it was still in beta, which meant dealing with breaking changes across three minor releases. The documentation lagged behind the implementation. Some features that worked in Payload 2 were temporarily missing in 3. There were weeks where I questioned the decision.
The bet was that architectural alignment would matter more than short-term stability, and that turned out to be correct for our situation. But I would not make the same choice for a team that needed a CMS to work perfectly on day one with minimal engineering involvement. Contentful would have been the right answer for a marketing team that does not have a dedicated engineer maintaining the integration.
Operator mode means you inherit every downstream consequence. The code path is only half the story; the other half is how the decision warps planning, trust, and execution speed. I kept relearning that lesson while building portfolio, pipeline-sdk, and dotfiles.
The best framework for your team is not the one with the most features. It is the one whose assumptions match your architecture and whose trade-offs align with the problems you actually have.
Framework evaluation is not about finding the objectively best tool. It is about finding the tool whose grain runs in the same direction as your project. When you fight a framework grain, every feature becomes a workaround. When you go with it, even the rough edges feel manageable because the fundamental model makes sense for your use case. Payload 3.0 made sense because we were already a Next.js and PostgreSQL shop. The framework disappeared into our stack instead of sitting on top of it.