Document Hub

The business problem

Every dCloud demo ships with documentation — step-by-step guides authored in markdown, pushed to GitHub, and also produced as a separately formatted Word document by hand. On my team, that was a quiet bottleneck.

Three things were wrong with that: the pipeline assumed Git fluency that non-technical writers didn't have; maintaining a markdown file and a Word doc separately meant duplicated effort on every guide; and writers had no way to preview their output before it went live.

No one briefed me to fix this. I surfaced it in conversation with the tech writers, recognised it as a recurring drag, and decided to solve it end-to-end myself.

What I learned from the writers

Talking through the actual workflow, the friction resolved to three root problems:

• The GitHub barrier.

  A publishing pipeline built for engineers was being operated by writers, who found Git and pull requests genuinely difficult.

• Duplicated output.

  A markdown file and a formatted Word document, maintained separately, for the same content.

• No preview.

  Writing against an mkdocs renderer they couldn't see until after publishing.

The product had to remove all three — and feel like part of the dCloud platform, not a bolt-on, or adoption would stall on unfamiliarity.

What I designed — and built

What makes Document Hub different: I didn't hand it off. I designed it and wrote the production code, building it in Cursor with Claude, on the Cisco Sales Org Design Language so it was visually native to the platform from day one.

Four decisions did the heavy lifting:

1. 1.

   One source, three formats — write once, export to markdown, HTML or Word, eliminating the parallel Word-document work entirely.

2. 2.

   A built-in preview — writers see the exact published mkdocs output as they write, instead of discovering it after it goes live.

3. 3.

   No Git required — create, edit and publish without ever touching GitHub.

4. 4.

   Assets that live with the guide — image uploads handled on the platform, so content and images stay together.

Shipping it inside Cisco

No engineering team assigned. Chris Kosowan (the Sales Org's Product Manager) handled the Kubernetes infrastructure and DevOps; I designed and built the application. No formal project, no dedicated resourcing — two people solving a real problem and shipping it.

Once live, I presented it to senior Sales Org leadership — up to C-level — to launch it to the tech-writing team.

Impact

• Shipped in 3 months

  from the first conversation with the writers to a deployed product on internal infrastructure, no formal project or dedicated engineering team.

• 50% faster guide creation

  and 10 technical writers onboarded — one source, three export formats (markdown, HTML, Word), no GitHub required.

• Designed and coded end-to-end

  in Cursor with Claude — from identified problem to working product, no handoff required.

Looking back

What I'd do differently: Host the published guides directly on the platform rather than routing through MkDocs. The constraint is real — it means more engineering work, authentication, security — and the right call was to ship something valuable quickly. The right next step is to close that gap properly.

Where it led: Document Hub is the clearest example of how I now work — AI-assisted, shipping beyond handoff, owning the outcome rather than the deliverable. It made the case internally that design can move from problem to working product directly.