Ideas I'd like to discuss

Conversation starters, not prescriptions

A few directions that look promising from the outside — some may already exist, some may be wrong for reasons I can't see yet. Before proposing any of them seriously, I'd want to understand your strategy: the questions at the end are where I'd start.

The first 30 minutes of a dotCMS developer

The metric I care about most: how fast a developer goes from “this looks interesting” to content rendering from a real repository in their own stack. dotCMS already has strong raw material: the API playgrounds, the framework guides, UVE. I’d start by walking that funnel end to end as a skeptical evaluator, instrumenting where people stall, and shaving the path: one canonical quickstart per framework, each ending in a working page, each honestly timed.

Documentation that AI agents can work with

A growing share of developers now meet a platform through Claude, Cursor, or Copilot rather than through Google. That changes what documentation needs to be: structured, example-dense, and consumable by coding agents: llms.txt, an MCP server exposing docs and content APIs, examples that agents can lift wholesale. “The CMS your AI assistant actually knows how to use” is a wedge no enterprise competitor firmly owns yet.

Every claim ships with something runnable

My rule at DonWeb was that nothing ships in content (no command, no config, no environment) that I hadn’t built and run myself. Applied here: every integration guide backed by a maintained example repo per SDK (Next.js, Astro, Angular, .NET…), CI-tested against current releases, so the docs can’t silently rot. Developers forgive missing features; they don’t forgive copy-pasted examples that fail.

Making UVE the demo centerpiece

The Universal Visual Editor is the differentiator against pure-headless competitors: marketers edit visually while developers keep their stack. That story is best shown — short split-screen videos where a content editor and a developer work on the same page without stepping on each other, one per framework. It’s also the demo that lands with both technical and non-technical buyers in the same room.

A live workshop cadence

At DonWeb I ran live programming and DevOps workshops twice a month and they compounded: recordings became evergreen content, questions became the content backlog, attendees became community. The same motion fits dotCMS at two stages: evaluation (“build a site on dotCMS in 45 minutes”) and customer onboarding (deeper, feature-specific sessions). These are also excellent for community building and brand awareness.

Content from signals, not keyword lists

Some of the most useful developer content doesn’t come from a keyword tool or a roadmap item. It comes from support tickets, recurring community questions, sales-call objections, and what the engineering team keeps explaining. I’d want a lightweight pipeline that turns those signals into a prioritized backlog, and measures content by developer outcomes (activation, time-to-first-success, deflected tickets) rather than page views alone.

Spanish as a growth surface

LATAM and Spain have large, underserved developer communities, and very few enterprise CMS vendors speak to them natively. I produce technical content at native level in both languages. The marginal cost of a Spanish track (docs-adjacent tutorials, workshops, short-form) is low, and the space is much less crowded than the English one.

A few questions of my own

Ultimately, ideas are cheap without context. These are the things I'd want to understand first.

  1. What does a successful first session with dotCMS look like from the product team's perspective, and how close does reality get today?
  2. Where do evaluating developers actually stall? Is it a docs problem, a demo problem, or an architecture-mental-model problem?
  3. How do docs, developer relations, and product marketing currently divide the developer-facing surface, and where do things fall between chairs?
  4. When your customers' developers bring AI assistants into their integration work, what are they asking dotCMS for that doesn't exist yet?
  5. Which piece of existing dotCMS content are you proudest of, and which one quietly embarrasses you?

I have more questions, specifically about your current strategy and the direction you intend to take for the Developer Relations Engineer role, but I think they are better asked in an interview than published on the open internet next to your competitors' reading list.

If any of these overlap with what you're already doing — even better; I'd love to hear how it's going. Tell me where I'm wrong.