Building in the open: VersionDocs
Why our documentation product is a collaborative Markdown editor, and the decisions we've made so far.
A few weeks ago we introduced Masconics with a promise to build in the open. This is the first of those updates: where VersionDocs stands, and why we're building it the way we are.
The problem worth solving
Technical documentation lives in too many places at once. A spec starts in a wiki, gets reviewed in a Google Doc, and eventually lands in a git repo — with three different versions of the truth along the way. Teams that write docs in Markdown already have the right idea; the tooling around collaboration just hasn't caught up.
Decisions so far
A few principles are shaping the build:
- Markdown is the source of truth. No proprietary document format. What you write is what ships, and it exports cleanly to PDF and HTML.
- Review is a first-class workflow. Versioned diffs and structured approvals, not a comment thread bolted onto the side.
- Real-time where it matters. Live cursors and presence for co-writing sessions, without turning the editor into a chat app.
What's next
The repository is public and the foundation is being laid. Next up is the editor core and diff view, then the review workflow — request, approve, merge — and then we start onboarding the first early-access batch.
If this sounds like something your team needs, join the waitlist on the product page. We read every reply.