CMS Trials: A Field Journal from My Log

Nitin Pakhide

08/29/25

I kept a living log in a spreadsheet while trialing Content Management Systems (CMS). This blog turns that log into a narrative and emphasizes what I tried, what broke, what felt great, and where I finally landed.
Who this is for: Decision makers, Developers and content teams choosing between Git-based CMS, headless SaaS, or WordPress headless for fast sites with sensible previews and low maintenance.

Why upgrade to advance CMS?

Astro’s native markdown support worked well for our small team, but it won’t scale with our growing needs. Non-technical members may find Git workflows difficult, creating bottlenecks in content creation. As content increases, keeping a consistent structure will be harder, leading to disorganization. Directly editing files in the codebase also complicates collaboration, version control, and reviews. For smoother teamwork and to achieve a more sustainable approach to demand generation through website development, we decided to explore better alternatives.

My Trial Timeline

Note: The dates below are taken directly from my spreadsheet log. A couple entries have typos, but I kept the sequence intact to reflect the real journey.

2025-04-22: TinaCMS configuration is complex and adds to build time.
2025-04-22: Try Decap CMS.
2025-04-24: Decap CMS: folders and hierarchy are not well supported for images.
2025-04-26: Try Sanity. Feels slower; Markdown editor is very basic if you stick to Markdown. Sanity shines with structured content and Portable Text, not classic Markdown.
2024-04-26: Try PagesCMS. Interesting, lightweight, but I hit bugs. No visual editor.
2025-04-26: Try Strapi.
2025-05-19: Needs a lot of developer setup and maintenance.
2025-05-19: Try Caisy.
2025-08-06: Caisy is good, but management is not very active. Looking for a more robust alternative.
2025-08-06: Try Git-based CMS with Git LFS. TinaCMS is the best among Git-based, but costs are similar or higher than Caisy when you need users and roles.
2025-08-06: Try WordPress as CMS.
2025-08-13: WordPress in headless seems robust. Possible for high performance and upgrade up to enterprise level.

Deep-Dive Notes by CMS

TinaCMS

What went well: In-context editing feels great. For Markdown/MDX content collections, it is the most “fun” and developer-friendly. If you prefer content living in Git with version history, Tina fits.
Frictions I logged: Initial configuration is more involved than Decap. Adds some build-time overhead. For non-technical editors, you likely want Tina Cloud for auth and a content API, which adds cost.
When to choose: Dev-led sites that value Git-native content, inline edits, and MDX. Plan your image strategy early (Astro/Image or Cloudflare transforms) so the media does not slow you down.

Decap (Netlify CMS)

What went well: Easy to add an admin UI over a Markdown repo, low maintenance, free and open source. Editorial workflow via PRs is clear.
Frictions I logged: Image folders and nested hierarchies are limited out of the box. Not actively updated to support the latest frameworks.
When to choose: Small blogs/docs where cost and simplicity matter more than advanced modeling or inline preview.

Sanity

What went well: Real-time Studio, strong schema-as-code modeling. Great for structured and componentized content.
Frictions I logged: If you try to keep everything as plain Markdown, it feels basic; Sanity expects you to lean into Portable Text and structured fields. Cost rises per seat.
When to choose: Multi-editor teams, complex content, localization, and strong preview needs. Expect some learning curve and schema design time.

PagesCMS

What went well: Minimal setup, Git-based simplicity.
Frictions I logged: Hit bugs during trials; lacks a visual editor.
When to choose: Tiny projects where a simple admin over Markdown is enough. It has good potential.

Strapi

What went well: Strong modeling, roles, and plugins.
Frictions I logged: Needs a lot of developer setup and maintenance. You own hosting, updates, and reliability. Best for teams with devops capacity.
When to choose: Complex workflows, custom back-office logic, or on-prem control.

Caisy

What went well: Good editor UX, GraphQL API, quick modeling for component-like content. Fast image handling and delivery.
Frictions I logged: Management is not active. For long-term confidence, I wanted a more visibly active platform or community. Cost may rival Tina once you add roles/seats.
When to choose: Sites that want a hosted headless with a simpler learning curve than Sanity.

WordPress (Headless)

What went well: Editors are productive immediately. With WPGraphQL or REST and Astro SSG, you can ship fast pages. Many plugins and ways to update the system as per the requirements. It’s low cost and robust.
Frictions I logged: Out of box REST or GraphQL is slower compared to dedicated headless cms. It needs a bit of tweaking to make it fast but possible. Keep an eye on plugin sprawl and security. Remote images need a pipeline to play nicely with Astro.
When to choose: Teams entrenched in WordPress who want a modern, fast Astro front-end without retraining editors.

Recommendations By Scenario

Solo developer or small team

→ Use Markdown/MDX content directly.

Need inline editing with Git history

→ Choose TinaCMS.

Want a simpler admin, don’t need inline editing

→ Choose Decap CMS.

Marketing/content hub, modular sections, real‑time preview, multiple editors

→ Choose Sanity for its depth and image pipeline.

→ Or use Caisy if you prefer GraphQL‑first APIs and faster onboarding—but check ecosystem activity before committing.

Complex roles, self‑hosting, deep backend integration

→ Choose Strapi (budget for ongoing maintenance).

Editors already familiar with WordPress

→ Use WordPress (headless) with WPGraphQL. Customize as per requirements + a CDN‑backed image strategy.

Conclusion

There is no perfect CMS; choosing wisely based on specific requirements is essential. For a growing company that wants to start with WordPress or is already using WordPress, opting for a headless approach with Astro is a solid alternative. This combination offers enhanced frontend performance while maintaining the flexibility and scalability needed for the long-term.

Questions? Contact us!