Document Hub

The business problem

Every dCloud demo ships with documentation — the step-by-step guides that tell sales engineers and customers how to run it. On my team, that documentation was a quiet bottleneck. Every guide was authored in markdown and pushed to GitHub by technical writers, and each one also had to be produced as a separately formatted Word document.

Three things were wrong with that. The publishing pipeline assumed Git fluency that non-technical writers didn't have. Maintaining a markdown file and a Word doc by hand meant duplicated effort on every single guide. And writers had no way to see their output before it went live — guides rendered through mkdocs, which they couldn't preview while writing, so they were effectively working blind.

No one briefed me to fix this. I surfaced it in conversation with the tech writers on my team, recognised it as a recurring drag on people I work alongside, 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 it had to feel like part of the dCloud platform, not a bolt-on, or adoption would stall on unfamiliarity.

What I designed — and built

This is what makes Document Hub different from the rest of my portfolio: 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. It runs on internal infrastructure with a database behind it.

Four decisions did the heavy lifting:

1. 1.

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

2. 2.

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

3. 3.

   No Git required — create, edit and publish guides without ever touching GitHub, the barrier that had made the old pipeline writer-hostile.

4. 4.

   Assets that live with the guide — image uploads are handled on the platform, so a guide's content and its images stay together instead of being managed separately in a repo.

Shipping it inside Cisco

A self-initiated build still has to earn its place on the platform. I worked with the engineering team to deploy Document Hub on internal infrastructure, and presented it to senior Sales Org leadership — up to C-level — to launch it to the tech-writing team. Building it solo meant I owned the design and the code together, so I could move from "here's the problem" to "here's the working product" without a full project needing to be spun up first.

Impact

• Shipped in 3 months from the first conversation with the writers to a deployed product on internal infrastructure, without a formal project or dedicated engineering team

• 50% faster guide creation writers produce guides in roughly half the time of the old markdown-in-GitHub workflow

• 10 technical writers onboarded as the primary users, replacing the old pipeline entirely

• Eliminated parallel maintenance: one source document, three export formats — the separate Word-document work is gone

• Removed the GitHub barrier so non-technical writers create, edit and publish guides without ever touching Git

• Designed and coded end-to-end in Cursor with Claude, shipped on the Cisco Design Language — from identified problem to working product, no handoff required

Looking back

What I'd do differently: I'd instrument usage from day one. The qualitative win was obvious to the writers immediately, but lightweight analytics — guides created, time per guide, formats exported — would have turned "this is clearly better" into a number I could put in front of leadership.

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 on our team can move from problem to working product directly, and it fed my wider push for AI-driven design and prototyping across the Sales Org.