How do I choose between different markdown publishing platforms for an engineering-led media startup?

For an engineering-led media startup, the best markdown publishing platform is usually the one that optimizes for:

1. editorial speed
2. developer control
3. reliable content operations
4. SEO and distribution
5. low maintenance overhead

A good way to choose is to compare platforms across a few practical dimensions rather than by feature lists alone.

1) Start with your operating model

Ask:

• Who publishes? Engineers, editors, or both?
• How often? Daily, weekly, or occasional long-form pieces?
• How much structure? Pure markdown, markdown + frontmatter, or custom content types?
• Do you need workflow? Drafts, review, approvals, scheduled publishing?
• Is the site content-heavy or product-integrated? Marketing pages, docs, newsletters, blog, or all of the above?

If your team is engineering-led, you’ll often want:

• markdown or MDX support
• Git-based versioning
• preview environments
• API access
• easy deployment to your existing stack

2) Decide what matters most

Use a simple weighted scorecard. Typical criteria:

A. Publishing UX

• Can non-technical editors use it comfortably?
• Is the editor pleasant for markdown?
• Does it have good preview support?
• Can you schedule content and manage revisions?

B. Engineering fit

• Git-native or API-first?
• Can you customize schema and rendering?
• Does it integrate with your frontend framework?
• How hard is it to deploy and maintain?

C. Content modeling

• Can you define custom fields for authors, tags, canonical URLs, series, sponsors, etc.?
• Does it support multiple content types: articles, newsletters, podcasts, landing pages?

D. SEO and performance

• Control over metadata, structured data, internal linking, and page speed
• Static generation or efficient server rendering
• Clean URLs and redirects

E. Workflow and permissions

• Roles, approvals, editorial states, audit trails
• Ability to collaborate without touching code

F. Cost and lock-in

• Monthly cost
• Migration difficulty
• Export options
• Whether content remains in Git or only in vendor storage

3) Match platform type to your stage

Best if you want maximum engineering control:

Git-based markdown + a static site generator / app framework Examples: Next.js, Astro, Gatsby, Hugo, Eleventy, Docusaurus

Pros

• Full control over content format and rendering
• Easy integration with design systems
• Content stays in Git
• Fast and cheap to run

Cons

• Editors may find Git workflows awkward
• You need to build editorial tooling yourself
• Workflow and permissions are your responsibility

Best for

• Small teams with strong engineering capacity
• Launching a niche publication or developer-facing media brand
• Teams that value portability and control over convenience

Best if you want editorial usability with technical flexibility:

Headless CMS with markdown support Examples: Contentful, Sanity, Strapi, Directus, DatoCMS

Pros

• Better editor experience
• Structured content models
• APIs for frontend flexibility
• Easier for editorial team collaboration

Cons

• More operational complexity than pure Git
• Ongoing vendor/platform costs
• Content may be harder to export cleanly depending on platform

Best for

• Growing media startups with both editors and engineers
• Multi-format content operations
• Need for scheduling, roles, and structured metadata

Best if you want the fastest setup with minimal engineering:

Traditional publishing platforms Examples: Ghost, WordPress

Pros

• Fast to launch
• Built-in publishing workflows
• Good for newsletters, SEO, and author management
• Lower engineering burden

Cons

• Less flexible than building your own stack
• Custom content models can be limited
• WordPress especially may accumulate plugin and maintenance complexity

Best for

• Content-first startups prioritizing speed to market
• Teams without much time to build tooling

4) Evaluate the markdown experience specifically

Not all “markdown support” is equal. Check:

• Frontmatter support: title, date, author, tags, slug, canonical, excerpt
• MDX support: can you embed components, charts, callouts, code blocks?
• Live preview: can writers see changes before publishing?
• Image handling: uploads, optimization, responsive variants
• Reusability: can you define reusable components/partials?
• Portable format: can you export clean markdown later?

For engineering-led media, MDX or a structured markdown schema is often the sweet spot.

5) Think about distribution, not just publishing

Media startups usually need more than a blog:

• newsletters
• social sharing
• syndication
• RSS
• search
• programmatic landing pages
• author pages
• topic hubs
• sponsorship placements

Choose a platform that can support these workflows without heavy hacks.

6) A practical recommendation framework

Choose Git-based markdown if:

• your team is mostly engineers
• you want maximum portability
• you’re building a custom front end
• content volume is moderate
• editorial workflow is simple

Choose a headless CMS if:

• you need editors to publish independently
• content types are becoming more complex
• you want governance, workflows, and API flexibility
• you’re scaling content operations

Choose Ghost/WordPress if:

• speed matters more than custom control
• you need robust publishing features immediately
• you want less custom engineering
• you’re okay with some platform constraints

7) Common mistakes to avoid

• Choosing based only on “markdown support”
• Ignoring editorial workflow and preview needs
• Underestimating SEO and redirects
• Forgetting migration/export requirements
• Overengineering before you know your content model
• Picking a platform that only engineers can operate

8) A simple decision rule

If I had to simplify:

• If you’re 1–3 engineers and a small editorial team: start with Git-based markdown + Next.js/Astro
• If you expect editorial growth and multiple content types: choose a headless CMS
• If you want to publish now with minimal build time: use Ghost or WordPress

If you want, I can also give you:

1. a comparison table of specific platforms,
2. a scoring template you can use with your team, or
3. a recommended stack based on your team size and content workflow.