DocHub: Versioned Documentation & Contributor Wiki for Open-Source Projects

A hosted documentation platform where open-source maintainers publish versioned docs and API references while community contributors submit wiki edits through a review queue.

SaaS WorkflowDeveloper & IT OperationsTiered SaaS subscription billed monthly, with paid plans unlocking private projects, custom domains, and higher contribution review throughput.
MVP time2-4 weeks
DifficultyEasy
Infra cost$17-$62
RevenueSubscription
Review the decision summary
11,334 views
Updated August 2, 2026

Decision snapshot

Is this worth validating?

Build this if

You maintain an open-source project with frequent releases and want community contributors to improve docs without granting repo write access.

Avoid this if

Your project ships infrequently or your team already has a mature docs-as-code pipeline with CI-based contribution review.

Validate first

Recruit 5 open-source maintainers with active GitHub projects; ask them to import one release's docs and invite 2 contributors to submit wiki edits. Measure whether at least 3 complete the full publish-and-review cycle within one week.

Problem and target customer

Why this exists

Customer problem

Open-source maintainers split documentation across static-site generators, GitHub wikis, and spreadsheets, making it hard to keep versioned docs in sync with releases or let contributors improve guidelines without write access to the repo.

Who pays

Indie open-source maintainers and small dev-tool teams who need a production-ready public docs site with a structured contributor workflow but cannot justify building custom documentation infrastructure.

Business model

Monthly subscription with a free tier for public projects and a paid workspace tier for private documentation and custom domains.

Editorial note

Open-source maintainers routinely ship releases faster than they ship documentation. The gap between a new version landing in GitHub and the public docs reflecting it erodes contributor trust and increases support burden.

DocHub narrows the problem to two workflows: maintainers publishing versioned docs tied to semantic releases, and community contributors improving wiki content through a structured review queue. The LLM layer is intentionally thin, generating API reference stubs from OpenAPI specs so maintainers spend time editing, not writing boilerplate.

The MVP excludes real-time collaboration, multi-language translation, and custom theming. These are post-validation features that add infrastructure complexity without testing the core hypothesis: that maintainers will pay for a hosted docs hub that treats community contributions as first-class.

Choose your next step

What do you need next?

Evaluate the operating tradeoffs quickly, or inspect how to build the MVP.

Evaluation preview

What would it take to run?

Directional infrastructure estimates for the current 250 content jobs assumption. Open the full calculator when you are ready to change it.

Open full cost and deployment
ManagedSelected
$30-$90/ month

Managed app hosting, database, backups, and basic observability for the content workflow.

Lowest operating effort
Lean self-hosted
$13-$53/ month

One small VPS running the app, database, media volume, and backup job.

Lowest baseline cost
More control
$50-$150/ month

Separate app, data, storage, and worker capacity for cleaner operations.

Most separation and control

Build blueprint

Build the first paid use case

Product goal

Who it serves and what it must change

Target user
Open-source project maintainers who publish versioned documentation and want community contributors to improve wiki content through a review workflow.
Problem
Documentation is scattered across static-site generators and GitHub wikis with no structured versioning or contributor review process.
Measurable outcome
A maintainer can import docs, publish a versioned docs site, and approve at least one community wiki contribution within 30 minutes of project setup.

MVP scope

What ships now and what waits

Included

  • Project creation with repository URL
  • Markdown doc editor with live preview
  • Semantic version tagging and version switcher
  • OpenAPI spec upload with LLM-generated API reference stubs
  • Community wiki contribution submission and maintainer review queue
  • Public read-only docs site
  • Email notifications for new versions and merged wiki edits

Excluded

  • Real-time collaborative editing
  • Multi-language translation
  • Custom theme editor
  • Full-text search across projects
  • SSO and enterprise auth

UX and user flow

Screens, actions, and states

Project Dashboard

Overview of doc versions, pending wiki contributions, and subscriber count.

Create new doc versionView pending contributionsPublish version
Doc Editor

Write and edit markdown doc pages with live preview and API reference rendering.

Edit markdownPreview rendered pageTag page to a versionSave draft
Contribution Review Queue

List pending wiki contributions with diffs for maintainer approval or rejection.

View contribution diffApprove with commentReject with reason
Public Docs Site

Rendered read-only documentation with version switcher and wiki pages.

Switch versionBrowse wikiSubscribe to updates

Primary flow

  1. Maintainer creates project and imports docs or OpenAPI spec
  2. System structures content into versioned sections
  3. Maintainer reviews and publishes the version
  4. Contributor submits wiki edit via public form
  5. Maintainer approves or rejects contribution in review queue
  6. System notifies subscribers of new version or merged wiki edit

Loading, empty, and error states

  • Draft
  • Published
  • Archived
  • Proposed
  • Approved
  • Rejected

Core entity outline

Entities and business rules

Project

Represents an open-source project with documentation.

Fields
id, name, repo_url, owner_id, visibility
Relations
has many DocVersions, has many WikiPages, has many Subscribers
DocVersion

A versioned set of documentation pages tied to a semantic release tag.

Fields
id, project_id, semver_tag, status, published_at
Relations
belongs to Project, has many DocPages
WikiPage

Community-editable wiki content for contributor guidelines and notes.

Fields
id, project_id, title, content, current_version
Relations
belongs to Project, has many Contributions
Contribution

A proposed wiki edit submitted by a community contributor.

Fields
id, wiki_page_id, author_name, proposed_content, status, reviewer_comment
Relations
belongs to WikiPage
Subscriber

A user who opted in to receive notifications about doc updates.

Fields
id, project_id, email, notify_on_version, notify_on_wiki_merge
Relations
belongs to Project

Business rules

  • A DocVersion cannot be published without at least one DocPage assigned to it.
  • Only the project owner can approve or reject Contributions.
  • Approved Contributions automatically merge into the WikiPage current_version and increment the version counter.
  • Rejected Contributions remain visible to the contributor with the reviewer comment but cannot be resubmitted; a new Contribution must be created.
  • Public Docs Site shows only DocVersions with status Published and WikiPages with at least one approved Contribution.

Architecture and data flow

Components, integrations, and controls

Docs API

CRUD for projects, doc versions, wiki pages, and contributions; serves public docs site content.

Review Queue Worker

Processes contribution approvals and rejections, merges approved content, and triggers notification dispatch.

OpenAPI Parser

Parses uploaded OpenAPI spec files and sends endpoint metadata to the LLM for reference stub generation.

Notification Dispatcher

Sends email notifications to subscribers when versions are published or wiki edits are merged.

Integrations

  • GitHub release webhooks via Make for doc version creation
  • OpenAI API for API reference stub generation from OpenAPI fields
  • Cloudflare R2 for OpenAPI spec file and doc asset storage
  • Email service for subscriber notifications

Data flow

  1. GitHub release webhook triggers Make scenario
  2. Make calls Docs API to create a DocVersion record
  3. Maintainer edits and publishes the version in the Doc Editor
  4. Docs API updates DocVersion status to Published
  5. Notification Dispatcher emails subscribers
  6. Contributor submits wiki edit via Public Docs Site form
  7. Docs API creates a Contribution with status Proposed
  8. Maintainer approves in Review Queue
  9. Review Queue Worker merges content and updates WikiPage
  10. Notification Dispatcher emails subscribers about the wiki merge

Failure handling

  • If the LLM API is unavailable, API reference stubs fall back to raw OpenAPI field descriptions without generated prose
  • If a GitHub webhook is missed, the maintainer can manually create a DocVersion from the dashboard
  • If email dispatch fails, the notification is retried three times with exponential backoff and logged for manual resend
  • If an OpenAPI spec fails validation, the system returns a field-level error list to the maintainer

Security

  • Only project owners can publish versions or review contributions
  • Public docs site is read-only with no write endpoints exposed
  • Contributor submissions require email validation before entering the review queue
  • OpenAPI spec uploads are validated against schema before parsing

Rate limits

  • LLM API calls capped at 50 endpoint descriptions per project per hour
  • Contributor submissions capped at 10 per hour per email to prevent spam
  • Subscriber notification emails capped at 1000 per hour per project

Deliverables and acceptance

Definition of done for the MVP

Deliverables

  • Project dashboard with version and contribution overview
  • Markdown doc editor with live preview and version tagging
  • OpenAPI spec upload with LLM-generated API reference stubs
  • Contribution review queue with diff view and approve or reject actions
  • Public docs site with version switcher and wiki pages
  • Email notifications for version publishes and wiki merges

Acceptance criteria

  • A maintainer can create a project, import a markdown file, tag it to a semantic version, and publish it to the public docs site within 15 minutes
  • Uploading a valid OpenAPI spec generates API reference stubs with descriptions for at least 80% of endpoints within 60 seconds
  • A contributor can submit a wiki edit from the public docs site and the maintainer sees it in the review queue within 5 seconds
  • Approving a contribution merges the content into the live wiki page and sends a notification email to subscribers within 2 minutes
  • Switching versions on the public docs site loads the correct versioned content within 2 seconds

Recommended stack

Enough technology for the first version

Frontend and docs editor

Lovable

Rapidly build the markdown editor, review queue UI, and public docs rendering with version switching without custom frontend infrastructure.

Backend and database

Railway

Host a Node or Python API and Postgres for durable storage of projects, doc versions, wiki contributions, and subscriber records.

Automation glue

Make

Sync webhook events from GitHub releases to trigger doc version creation and dispatch subscriber notification emails without writing custom cron jobs.

Object storage

Cloudflare R2

Store uploaded OpenAPI spec files and doc assets like images and diagrams with low-cost egress for public docs.

LLM for API reference stubs

OpenAI API

Generate human-readable API reference descriptions from OpenAPI spec fields to reduce manual writing for maintainers.

Why this is sufficient

Lovable handles the editor-heavy frontend and public site rendering. Railway provides the durable backend for versioned content and the contribution review pipeline. Make bridges GitHub release webhooks to doc-version creation and notification dispatch. R2 stores spec files and doc assets. The LLM is scoped narrowly to auto-generating API reference descriptions from OpenAPI fields, not generating full documentation.

Not required for the MVP

Maps API integrationReal-time presence indicatorsCustom analytics dashboardSSO and enterprise identity providers
Next stepTurn the blueprint into an execution plan

Copy the build prompt, model the operating cost, and choose where to deploy.

Build and ship

Execution

Build, price, and deploy the MVP

Once the blueprint is clear, use the prompt, cost model, and deployment options to start building.

Build prompt

Copy this into a builder

Lovable

Build prompt

Your build prompt is ready

Open the prompt pack whenever you are ready to take this blueprint into your builder.

Based on the blueprintReady for your builderFollow-up steps included

Cost calculator

Model the MVP operating cost

A technical run-cost estimate for the first production version. Team, acquisition, payment fees, and business COGS are excluded.

Estimated monthly total$30-$90

$15-$45 per 125 content jobs

Content jobs / month250 content jobs
Selected pathEasiest
Pricing checkedAug 2, 2026

Usage assumptions

Use beta workload metrics when available.

Infrastructure approach
Managed app hosting, database, backups, and basic observability for the content workflow.
Cost breakdown

$30-$90 per month

Low and high values allow for usage variance and plan headroom.

Managed infrastructure

Managed app hosting, database, backups, and basic observability for the content workflow.

50K content jobs included, then $8-$20 per 100K content jobs
$25-$65
Object storage

Object storage is implied by the source workflow or feature list.

Monthly allowance from this idea's operating profile
$5-$25

Included

  • Application hosting
  • Relational database
  • Basic backups
  • source assets and publishable variants state
  • Object storage

Not included

  • Paid acquisition
  • Founder or team time
  • Tax or legal review
  • Custom enterprise procurement

Pricing basis

The estimate combines the selected infrastructure path, required operating modules, selected optional modules, and usage above included monthly allowances. Taxes and regional uplifts are excluded.

Deployment options

Pick the operational tradeoff

Choose based on operating preference, not only the headline price.

EasiestRecommended

Railway

Fast Docker deployment for the app, database, worker, and preview workflow without managing a VPS.

$15-90/month before usage-heavy add-ons

Good fit

  • Fast setup
  • Low starting cost
  • Good preview workflow

Limitation

Usage billing needs active monitoring as traffic and jobs grow.

Cheapest

Vultr

Run the app, worker, and database on one small Vultr VPS with Docker Compose and explicit backups.

$8-60/month before managed add-ons

Good fit

  • Predictable baseline
  • Portable setup
  • Room for workers

Limitation

You own patching, backups, monitoring, and incident response.

More control

DigitalOcean

Separate application, worker, data, storage, and backup responsibilities as the workload grows.

$10-120/month before managed add-ons

Good fit

  • Cloud VPS control
  • Global regions
  • Room for workers

Limitation

You own server setup, patching, backups, and operational monitoring.