<h2>Path routing over subdomains</h2><p>We intentionally kept the blog under `/blog` instead of creating a separate hostname for user-generated content. That preserves brand continuity and avoids making the editorial surface feel detached from the product.</p><p>The route architecture was already in place, so the real work became replacing the weak content layer and leveling up the reading experience.</p><h2>Operational notes</h2><ul><li>Use a single visual system so the transition from product to blog feels native.</li><li>Keep cache strategy simple while the editorial workflow is still evolving.</li><li>Design storage seams early so you can swap file-backed content for a managed backend later.</li></ul>

## Path routing over subdomains

We intentionally kept the blog under `/blog` instead of creating a separate hostname for user-generated content. That preserves brand continuity and avoids making the editorial surface feel detached from the product.

The route architecture was already in place, so the real work became replacing the weak content layer and leveling up the reading experience.

## Operational notes

- Use a single visual system so the transition from product to blog feels native.
- Keep cache strategy simple while the editorial workflow is still evolving.
- Design storage seams early so you can swap file-backed content for a managed backend later.

I appreciate the honesty around storage seams. So many examples skip the part where content actually needs to live somewhere durable.

What we learned shipping Next.js on Cloudflare without splitting the product apart

<h2>The problem was never only the CMS</h2><p>A blog that is hard to publish into eventually becomes a marketing liability. The friction is rarely just the editor. It is usually the whole loop: workflow, publishing confidence, discoverability, and whether the team feels ownership over the surface.</p><p>We wanted a system that feels like a product, not a hidden content panel. That means the blog should live on the main domain, share the same trust signals, and make the path from draft to live story obvious for non-technical writers.</p><h2>What changed in the rebuild</h2><ul><li>Posts are modeled in code with explicit structure and community metadata.</li><li>Writers can create drafts, publish, and update content from an in-app editor route.</li><li>The public surface is discovery-first, with featured stories, trend rails, and discussion affordances.</li></ul><h2>The payoff</h2><blockquote><p>The best editorial system is the one your team actually wants to return to next week.</p></blockquote>

## The problem was never only the CMS

A blog that is hard to publish into eventually becomes a marketing liability. The friction is rarely just the editor. It is usually the whole loop: workflow, publishing confidence, discoverability, and whether the team feels ownership over the surface.

We wanted a system that feels like a product, not a hidden content panel. That means the blog should live on the main domain, share the same trust signals, and make the path from draft to live story obvious for non-technical writers.

## What changed in the rebuild

- Posts are modeled in code with explicit structure and community metadata.
- Writers can create drafts, publish, and update content from an in-app editor route.
- The public surface is discovery-first, with featured stories, trend rails, and discussion affordances.

## The payoff

> The best editorial system is the one your team actually wants to return to next week.

Keeping the blog on the same path instead of moving it to a separate host is the right call for trust and SEO continuity.

The point about a blog becoming a product surface really landed. We made the same mistake by treating content ops like an afterthought.

Shipping the platform

Shipping the platform

What we learned shipping Next.js on Cloudflare without splitting the product apart

Building a writer-first blog system without losing product velocity