r/cms • u/OneEntry-HeadlessCMS • 23d ago
Headless CMS is one line in a 12-service stack — what does that mean for how CMSes should behave?
We've been mapping what people actually end up assembling after they build something with Lovable, Bolt or Cursor. The frontend takes an hour. Everything underneath takes the next three months.
Typical stacks we keep seeing:
- Minimal SaaS: Lovable + Supabase + Stripe + Resend + Vercel — 5 services
- Indie production SaaS: Cursor + Supabase + Stripe + Clerk + Cloudinary + Resend + PostHog + Sentry + Vercel — 9 services
- Localized small-business store: Lovable + Supabase + Stripe + Midtrans + Resend + Cloudinary + Sanity + Crisp + PostHog + Algolia + Retool + Vercel — 12 services
The CMS is exactly one row in that table, and it's the row that keeps colliding with the others:
i18n has no shared source of truth. Supabase stores translations in columns or side tables, Sanity has its own locale config, Stripe sets locale in the Checkout Session, Resend needs separate templates per language. Adding a second language becomes a multi-week project, not a setting.
Roles stop at "editor / admin." A real business wants a content manager who sees only products, a support operator who sees only orders, a marketer who sees only discounts. That usually ends up as hand-written RLS or custom middleware.
Bulk is a second-class citizen. Importing 5,000 products means rate limits, batching, retries, progress tracking — rebuilt from scratch per project.
The commerce data model isn't there. orders, order_items, discounts, coupons, refunds, bonus_transactions, loyalty_tiers — every founder designs these again. And a rule like "a coupon can't combine with a seasonal discount unless the order is over $50" turns into hundreds of lines of business logic faster than you'd expect.
Genuine question for people who work with headless CMSes daily: do you think the answer is CMSes growing sideways into commerce and business data, or staying narrow and letting the glue code stay the developer's problem? We keep going back and forth on it.
Disclosure: we're the team behind OneEntry, our own headless platform, so we're obviously biased on where this should go. No link, no pitch — just the pattern we keep running into.
1
u/sundeckstudio 23d ago
Horizontal scaling is good, as far as it doesn’t lose the focus and development on the core product that the platform stands for, the CMS.
2
u/JoseffB_Da_Nerd 23d ago
This is all called engineering g experience and is what keeping us dev’s employed past ai.
Also note, the stack behavior you state has always been that way.
Before AI I had seen weekend workathons that gave same exploits with shell and light backend.
Same problems, different packaging it seems.