When is a custom CMS worth it over Payload or Sanity?

When your content types carry domain-specific metadata that off-the-shelf schemas cannot express without fighting the tool. Here, 12 sport content types each needed custom fields. Forcing them into Payload or Sanity would have cost ~4 hours of schema work per type -- 48 hours total. Custom took 5 days and required no workarounds.

How do you ship a live-preview editor in 5 days without cutting corners?

Keep the block-renderer stateless and driven entirely by a JSON schema. The preview panel re-renders on every change by passing the same schema the public page uses. No separate preview codebase, no iframe hacks. Five days is tight but achievable when the renderer is the same function everywhere.

What breaks first when you compress a 10-week build into 3 weeks?

Documentation and test coverage. Both were minimal. What did not break was the core architecture because the custom CMS decision removed a whole category of integration risk. Tight timelines reward decisions that reduce surface area, not ones that add flexibility you do not need yet.

Is Supabase production-ready for a live-streaming and ticketing workload?

Yes, for this scale. Supabase Postgres handled auth, event metadata, and purchase records without issue. Row-level security policies kept the data model clean. The $50/mo run cost includes Supabase's free tier with room to grow before hitting the first paid tier.

What do you hand off to the founder at the end?

Documented repo, environment variables in Vercel, CMS editor walkthrough video, and a Stripe dashboard they already own. No vendor lock-in. The founder can hire any Next.js developer to extend it. That is the goal -- full ownership from day one.

How a Sports Streaming Startup Shipped Its CMS, Payments, and Live Streaming in 3 Weeks

12 CMS block types, live preview, ticketed streaming, and a cinematic public site shipped before the spring signing window.

Before	After
4 months burned with prior vendor	3 weeks from start to shipped, 3 weeks ahead of deadline
Broken CMS and no payment flow	12 CMS block types with live preview
$1,800/mo ongoing vendor contract that was not shipping	40+ ticketed events processed through Stripe in month one
Every week of delay equaled revenue walking away	Monthly run cost $50 (Vercel + Supabase + Stripe fees)
	The replacement of the $1,800/mo vendor contract alone covered the implementation investment within the first quarter

What happens when a vendor burns 4 months on a deadline that can't move

The founder had one constraint that could not change: the spring signing window. Every week of delay was a week where athletes, scouts, and team operators had nowhere to go. The prior vendor had 4 months to deliver a CMS and a payment flow. They shipped neither.

When we started talking, the deadline was 6 weeks out. The platform had no working CMS, no Stripe integration, and no public site. The vendor's contract was still running at $1,800 per month for nothing shipped.

The math was simple: ship in 6 weeks or miss the window entirely.

We shipped in 3.

Why the build-vs-buy CMS decision is where most sports platforms lose

Most developers default to Payload CMS or Sanity because the setup is fast and the docs are good. For generic content -- blog posts, team pages, simple product listings -- that default is correct.

Sports content is not generic.

This platform needed 12 distinct content types: event pages, athlete profiles, team rosters, stream schedules, highlight reels, recruiting spotlights, and more. Each type carried sport-specific metadata that did not map cleanly to a generic CMS schema. Payload and Sanity both require you to define schemas in code or config, and both have opinions about how fields nest and relate. For standard content those opinions save time. For niche metadata they become obstacles.

The estimate for forcing all 12 types into Payload was about 4 hours of schema work per type. 48 hours total, just to wrangle the CMS into shape. That does not include the time lost to Payload's access control model, which needed to be rebuilt to match the platform's auth logic.

Sanity has a different schema format but the same fundamental problem: it is designed around documents, not around domain-specific records with structured sport metadata.

The question was not "which CMS is better." It was "what is the fastest path to 12 working content types with a live-preview editor?"

The custom block-based CMS decision, explained

A custom block-based CMS sounds expensive until you break it down.

The architecture is simple: a JSON schema defines each block type -- fields, validation rules, and rendering hints. The editor reads that schema and generates the form. The preview panel reads the same schema and renders the result using the same React components the public site uses.

There is no magic. There is no framework to fight. The schema is yours, the renderer is yours, and adding a new block type is one file.

Five days to build the full CMS, including the live-preview editor. Compare that to the 4-week estimate for bending an off-the-shelf CMS to fit.

The Next.js 15 App Router made this straightforward. Server components handled the CMS data layer. Client components handled the editor state and live preview. Supabase Postgres stored the content records with row-level security so the editor UI could write directly without an intermediate API layer.

The decision compressed 4 weeks of integration work into 5 days and made every downstream feature faster because there was no CMS abstraction layer to route around.

The 3-week shipping sequence

Week one was the CMS and auth layer. The 12 block types were defined, the editor was wired to Supabase, and the live-preview panel was functional by end of week. Supabase auth handled team logins with row-level security policies scoped to organization ID.

Week two was the public site and Stripe. The marketing site used GSAP for scroll animations and cinematic transitions -- the kind of motion that makes a pre-seed startup look like a funded product. Stripe Checkout handled ticketed events and stream passes. Checkout sessions were created server-side, Stripe webhooks updated Supabase on payment confirmation, and access was gated at the Supabase row-level security layer.

Week three was hardening and launch. Stripe webhook reliability, edge cases in the CMS editor, Vercel deployment configuration, and end-to-end testing of the full purchase flow. The platform was live before the third week ended.

The founder's deadline had 3 weeks of buffer remaining.

What the month-one numbers looked like

Month one was not a soft launch. The spring signing window opened and the platform was ready for it.

Forty-plus ticketed events processed through Stripe. A four-figure ARR baseline from stream passes and event tickets combined. A public site that looks like a $50,000-per-month SaaS product -- cinematic animations, fast load times on Vercel's edge network, and a mobile experience that does not feel like an afterthought.

The CMS editor was in active use by the founder and their team within the first week. No training period. No support tickets about the interface. The live-preview editor meant they could see exactly what each content block looked like before publishing.

The cost math

Monthly run cost: $50. That covers Vercel hosting, Supabase database and auth, and Stripe transaction fees on the volume they were processing in month one.

What it replaced: an ongoing $1,800 per month vendor contract that had burned 4 months and delivered nothing usable.

The replacement of the $1,800/mo vendor contract alone covered the implementation investment within the first quarter. The revenue from ticketed events is on top of that.

The off-the-shelf CMS route would have cost the same developer time plus ongoing Payload or Sanity licensing, plus the time lost fighting the schema. Custom was not the expensive option. It was the faster and cheaper option with no recurring licensing dependency.

Who this applies to

This approach works for founders with a hard deadline, a niche vertical, and content types that do not fit generic CMS schemas. It works for anyone who has already lost time to a vendor and needs owned code they can hire any developer to extend. It does not work for teams that want a no-code CMS they can hand to a non-technical marketing team -- the custom editor is powerful but it requires a developer to extend.

If your content is generic -- blog posts, landing pages, standard e-commerce -- use Payload or Sanity. They are good tools. If your content carries domain-specific metadata and you have a deadline, do the math first.

For related context on shipping under deadline with owned infrastructure, see the recruiting sourcing engine case study.

What I'd revisit

The live-preview editor and the public site shared rendering logic but not a formal component library. That meant some components existed in two slightly different versions. A shared package would have cut that duplication by roughly 30% and made it easier for the founder's future developers to extend the public site without touching the CMS.

I would also start Stripe webhook handling in week one, not week three. The webhook layer is where the most edge cases live -- failed payments, duplicate events, refunds -- and leaving it to the final week added pressure that could have been avoided.

Need to ship against a hard deadline? Run the AI Operations X-Ray.