Services
voix moves product documentation off locked proprietary platforms onto an open-source stack your company owns. Four services do that work, and most engagements use all four. Each one can also be scoped on its own.
A one-time project fee, scoped by documentation volume, complexity and implementation requirements.
Standard delivery within two business weeks of the deposit and the required materials.
On full payment the final deliverables are yours, in your own Git account.
No subscription, no per-seat fee and no recurring platform licence.
Service 01
Collect scattered documentation and data into one searchable, maintainable structure.
Most documentation does not live in one place. It lives in a help centre, a wiki, a shared drive, a support macro library, a handful of README files and a folder of PDFs somebody exported two years ago. Each of those surfaces has its own search, its own owner and its own idea of what is current. Readers stop guessing which one is right and open a ticket instead.
Consolidation starts with an audit. voix inventories every source and records what each page is for, who last touched it, and whether anything still links to it. That inventory becomes a migration map: pages to move as they are, pages to merge, pages to rewrite, and pages to retire outright. Retiring is part of the work. A smaller set of pages your team trusts is cheaper to maintain than a large set nobody believes.
The information architecture is then designed around the questions readers actually arrive with, rather than around your internal org chart. Sections are named in the reader’s words. Depth is capped so nothing important sits four clicks down. Every page gets a place in the tree and a named owner, and the tree is shaped to absorb the next two years of product changes without a second reorganisation.
You see the map before anything moves. The process page shows where the audit sits in an engagement: nothing is merged, moved or deleted on a guess, and the structure is approved in writing before the build starts.
Service 02
Implement a documentation platform your company owns, with reusable templates, navigation standards and a quality baseline.
The platform is Docusaurus: content in Markdown, configuration in code, all of it in a Git repository your company controls. There is no seat licence to renew, no editor to log into, and no export request to negotiate if you change your mind later. The stack is the same one this site runs on.
Implementation covers the parts that decide whether a documentation site stays usable after launch: sidebar and navigation structure, search configuration, versioning if your product ships versions, and the templates authors start from. Templates matter more than they sound. A concept page, a how-to, a reference entry and a troubleshooting page each have a fixed shape, so a writer begins with a structure instead of a blank file and a reviewer knows what “finished” means.
The quality baseline is written down and enforced by the build rather than by memory: heading order, required front matter, link targets, code block languages, image alt text. Anything a machine can check, the build checks, which keeps review conversations about content instead of formatting.
The look is yours. Typography, colour and layout follow your brand, while the underlying stack stays completely standard, so any developer who has worked on a React project can maintain it. The case studies show what the before-and-after of an implementation looks like.
Service 03
Train the people who will write, review and publish, so documentation keeps moving after handoff.
A migration only one person understands is a new dependency, not a fix. Enablement is the part of the engagement that takes voix out of the critical path and puts your team in it.
Training runs against your real repository, not a demo. Authors learn the branch-and-pull-request loop, how to preview a change before it ships, which template to start from, and what the review checklist asks for. Reviewers learn what to accept, what to send back, and how to decline a page that duplicates one that already exists. Whoever owns the repository learns how the build works, where publishing is configured, and how to add a section without breaking navigation.
Sessions are recorded, and the material stays in the repository as a contributor guide that is versioned alongside the content. The fifth writer who joins reads the same instructions as the first, and new joiners onboard from the documentation about the documentation instead of from somebody’s memory.
Enablement also settles governance: who reviews what, how often each area is checked for drift, and what happens when a page loses its owner. Most documentation decay is an ownership problem long before it is a writing problem, so the ownership model is written down and handed over with everything else.
Service 04
Reviewed, tested and consistently published updates, so a documentation change carries the same low risk as a code change.
Once documentation lives in Git, it can be delivered like the rest of the product. Every change arrives as a pull request. Every pull request builds a preview a reviewer can read in a browser. Nothing reaches production without a green build behind it.
The pipeline checks the things people skip when they are in a hurry: broken internal links, dead external links, missing front matter, files that are not reachable from the sidebar, images without alt text, and code blocks that do not declare a language. Redirects are validated too, so the URLs you gave to search engines and support agents keep resolving after a restructure.
Publishing happens automatically on merge. There is no release ritual, no copy-paste into a vendor editor, and no single person who is the only route to production. A site publishes in minutes once the pipeline is wired up, and that changes what a team is willing to fix: a typo stops being a ticket and becomes a two-minute pull request.
The pipeline is plain configuration committed to your repository and running on your CI provider. You can read it, change it and take it with you. Rolling back is a revert, because every published state of the site is a commit.
Delivery scope
Twelve pieces of work, grouped by the phase they land in. A proposal assembles a scope from these; it does not always include all twelve.
Scope, timeline and fees are fixed in a written proposal or statement of work before anything starts. Pricing explains what a quote is based on, and process sets out the order these phases run in and who does what in each one.
Boundaries
A short list, published here so nobody discovers a boundary halfway through a project.
None of this is refused on principle. Out-of-scope requests are possible; under the terms and conditions they need written approval and a revised scope before they enter the plan, so the delivery date you were given stays honest.
Additional service
A separate, smaller service that sits outside the migration practice: a one-time portfolio build for 500 EUR.
This is not a cut-down migration and it is not a way to buy one cheaply. It exists because people ask for it. voix builds a personal or studio portfolio on the same open-source stack the rest of this page describes: content in Markdown, the site in a repository you own, no licence to renew.
If you came here about product documentation, this is not the thing to read. Start with the four services above, then pricing.
Timing
Standard delivery is within two business weeks of receiving the deposit and the required materials.
The clock starts on the deposit and the materials, not on the first conversation. How long a documentation migration takes gives the full answer: what the two weeks cover, what is scoped separately, and what moves the date.
Send the platform you are on, roughly how many pages you have, and where they live now. You get back a scoped proposal with a fixed fee and a delivery date.