I used to write up blog posts after every meaningful session with Copilot or Augment — not just to share what I built, but to lock in my own understanding of what happened. This is one of those posts. What started as a coworker pinging me about some broken navigation in our docs site turned into a full investigation workflow, a shareable report, and eventually a reusable AI skill. Here’s how it went.
There’s a moment in every developer’s journey when you finally realize: “I should have documented this the first time.”
Mine came after spending two hours debugging why my Sanity Studio components weren’t showing up in production—even though they worked perfectly on localhost. The problem? I had forgotten that my blog actually consists of two separate applications that need independent deployments.
This is the story of how writing documentation for “future me” accidentally made my development process 3x faster.
When building a professional documentation site like DevPortals.tech, maintaining content quality while enabling rapid development requires a strategic approach to version control. Here’s the branching strategy I’ve implemented for managing documentation content lifecycle.
Building a portfolio-quality documentation site presents unique challenges:
While building DevPortals.tech, I ran into a common documentation site challenge: how do you organize sidebar navigation when you want some content to appear in a specific order (like overview pages) while still automatically including new files as you create them?
This is the kind of practical problem that comes up constantly when building documentation sites, and the solution isn’t always obvious from the docs.
Documentation frameworks are not just technical choices — they reflect cultural shifts in how we think about developer experience.
For years, reStructuredText (reST) powered serious technical documentation, especially in the Python and scientific communities.
Today, Markdown and MDX dominate modern developer portals. Why? Let’s explore this shift.
