Why I Stopped Using Strapi for New Projects (and What I Use Instead)

Strapi was my go-to headless CMS for years. Today, I no longer use it for new projects. Here is what changed.

I started using Strapi when the market was looking for a robust alternative to WordPress, and Strapi worked like a charm: ready-to-use REST and GraphQL APIs, a clear admin panel, self-hosted, and open source. I used it across several projects and recommended it without hesitation.

Over time, however, a few key factors made me rethink this choice:

1. The real cost isn't the license—it's the maintenance.

The only truly free option I found to host Strapi was Render.com. It handles the requirements well and runs without crashing for small-to-medium projects, but it's slow. Strapi Cloud is a good, affordable alternative, but its limits leave very little room before you need to upgrade to a paid plan. Self-hosting on DigitalOcean offers great performance, but it demands ongoing time for updates and server maintenance. For smaller projects, that hidden cost weighs heavier than any initial savings.

2. Model rigidity.

When a client asks for something outside the box (conditional fields, custom approval workflows, granular permissions), you either pay for Enterprise or build your own plugins. At that point, you're no longer saving time. While the plugin ecosystem has grown, many plugins contain bugs or don't do exactly what you need.

3. Component development.

Building custom components in Strapi is versatile, but keeping them aligned with your frontend repository (in my case, Next.js) can get messy. A simple change forces you to modify two separate repositories—doubling your work.

4. The market shifted.

In 2026, for 80% of the content projects I build, Markdown files with build-time validation or custom APIs built on Supabase solve problems faster and with significantly less maintenance. Supabase’s free tier is exceptionally generous for small projects. You simply no longer need to manage a full Strapi server just to handle content.

What hasn't changed:

I don't think Strapi is bad. It was the right answer for 2020–2024. My own site, enriquemontes.com, still runs on Strapi, and for large-scale enterprise builds like GmVykon.com, maintaining a Strapi server remains fully justified.

The Turista.com.mx case study:

When I first planned the migration for this platform—active since 1999—Strapi seemed like the natural fit. In early experiments with Gatsby before moving to Next.js, Strapi made sense because of its seamless GraphQL integration.

However, my routines weren't strictly "content." They involved dense business logic: complex rules, approval flows, calculations, and integrations with third-party APIs. Migrating all of that into Strapi would have required rewriting everything from scratch, resulting in a slower and more fragile system than what was already in place.

So I made a decision that might not look "pretty" on paper:

I migrated the frontend from PHP using Zend Framework to Next.js, while keeping the backend on Apigility (now Laminas). Thanks to the underlying robustness of PHP/MySQL, the server required to handle the massive operation volumes of Turista.com.mx remains lean, especially when paired with SSR.

On paper, developers always want "everything modern." But the right technical decision isn't the most trendy one—it's the one that respects what already works and avoids breaking battle-tested systems.

If it ain't broke, don't fix it.

Key takeaways:

Strapi isn't a silver bullet. It's excellent for editorial content, portfolios, blogs, and simple e-commerce. Forced into complex business logic, it struggles.
Migrating doesn't mean rewriting everything. Sometimes the best migration strategy is hybrid: modernize where it adds real value, and preserve what is already working.
27 years of code isn't technical debt—it's proven value. Not everything old needs to be thrown away. You just need to know what stays and why.

#Nextjs #Strapi #HeadlessCMS #WebDevelopment #TypeScript