Roadmaps
Weekly stages, delivery focus, and cross-direction progress gathered into one publishing layer for company teams.
Internal publishing system
One front end for roadmaps, project context, and internal documentation.
Docs-Molchanovs is the publishing layer for turning repository-managed documentation into a cleaner experience for company teams: easier to browse, easier to share, and more aligned with the Molchanovs design system.
Projects
Project context pages that connect product intent, active initiatives, and implementation direction across repositories.
Reference Docs
Curated internal documentation with a clearer front end, stronger visual hierarchy, and easier browsing than raw repository markdown.
Docs-Molchanovs plan
The first release should feel like a documentation product, not a markdown dump.
The MVP starts with a curated source set from molchanovs-docs,
reuses the reference landing-page structure from molchanovs-move,
and ships through a separate static Astro service on Fly.io.
1
Start From The Source
Use the approved document set from molchanovs-docs as the canonical source for what gets published first.
2
Shape For Browsing
Turn operational markdown into readable, structured pages with clearer narrative, hierarchy, and page-level framing.
3
Publish Through Docs-Molchanovs
Deliver the front end from this repository through a dedicated Astro workspace and separate Fly.io app under docs.molchanovs.com.
4
Support Team Alignment
Give company teams a cleaner place to understand roadmaps, project direction, and selected strategic documentation.
5
Reuse The Design System
Recreate the existing Molchanovs visual system: brand blue, square institutional edges, editorial layout, and shared component logic.
6
Expand Carefully
Start with a controlled publishing scope, then add richer documentation patterns and more pages without losing clarity.
7
Keep Operations Safe
Dedicated Astro workspace, separate Fly app, app-scoped tokens, and no crossover with the main platform deployment path.
8
Build A Lasting Docs Surface
Turn documentation into an actual product surface instead of a file tree, while keeping the source material maintainable.
Why this matters
Documentation should support alignment, not create friction.
This work is not just about a static page. It is about giving teams a place where roadmaps, project direction, and internal documentation feel coherent, branded, and intentionally presented, while the source of truth stays maintainable in the documentation repository.