Use single-sourcing to deliver project-specific documentation
Every customer project has a documentation line item, but delivering docs as a mix of product documentation and project-specific components is messy and quickly goes out of sync. Single-sourcing lets you write once and deliver many tailored versions.
If you deliver software into customer projects — implementations, integrations, managed deployments — you already know the pattern. Each project needs documentation that reflects its own product names, versions, URLs, and configuration.
The easy way to get there is to copy the last project's docs and edit them. The hard part is living with it afterwards.
The problem with copy-per-project docs
Copying works for the first two or three projects. By the tenth, you have ten versions of the same installation guide, each a little different, and no reliable way to tell which differences are intentional.
- Fixes don't propagate: correcting a step in one copy leaves the same mistake in every other copy.
- Reviews multiply: every change has to be checked across every project that inherited the page.
- Drift is invisible: nobody can say with confidence which project's docs are current.
- Onboarding slows down: new writers have to learn which copy is the "real" one.
What single-sourcing means
Single-sourcing means keeping one canonical version of each piece of content and generating the project-specific output from it. The parts that are the same everywhere are written once. The parts that differ — names, versions, endpoints, optional modules — are expressed as values that change per project, not as edits to a copy. The parts of the solution that don't exist in your product modules are the only genuinely new content you need to write.
Building blocks
Variables
Variables are the simplest and most valuable tool. Define the product name, version, support URL, or environment hostname once, reference it everywhere, and swap the value when you publish for a specific project. A rename becomes a one-line change instead of a search-and-replace across hundreds of pages.
Linked content
You can assemble your final project documentation by linking existing docs into a single project site. When you link content, it isn't a copy — it's a reference to the original source. So when the original sources get fixes and updates, the project documentation can be refreshed as well.
A practical way forward
- Decide which of your existing modules your solution deployment needs.
- Create a new project-specific site.
- Link the existing modules in as top-level items.
- Identify any content in your core modules that could be project-specific and turn it into variables. You can use the "Make re-usable" AI feature to find relevant places within your documents and do this automatically.
- Add a new top-level item for the project-specific documentation.
- Fill in the variable values specific to your project. All linked modules inherit them.
- Add project-specific branding — your customer's logo and name — to assure them the documentation is tailored to their deployment.
- Optionally, convert the top-level items into tabs and create a portal page that acts as a landing page for all of the documentation.
- Optionally, export to PDF or EPUB to give your customer a tangible deliverable.
How ElasticDocs helps
ElasticDocs supports variables and content linking today: set product names, versions, and URLs once and swap them at publish. Because the whole team edits the same pages in real time, there is one source to maintain rather than a set of branches to reconcile.
Cross-site single-sourcing is built in: link content from one docs site into another, and every project site stays in step with the original. Portal pages give your documentation a clean top-level landing page.
— ElasticDocs team