A docs-as-code lighthouse project in defence
At a Tier-1 defence supplier, a software team of 40 showed that docs-as-code works and makes the work more efficient – with Sphinx-Needs, ubCode, CI and the company's own branding.
- Industry
- Defence, Tier-1 supplier, software development
- Team
- Software development team of 40 people
- Period
- 2026
- My role
- Consulting, implementation and training
Problem
A Tier-1 defence supplier wanted to know whether docs-as-code fits its software development. A lighthouse project was to answer two questions: Is it feasible, and does it make the work noticeably more efficient?
The proof had to be solid, because it was meant to be the base for further decisions.
What we did
Together with a software team of 40, I implemented docs-as-code with Sphinx-Needs and ubCode from useblocks. A CI system builds and checks the documentation on every change.
HTML and PDF output carry the company's branding, so the documents fit right into the company's usual look. We adjusted the existing workflows only slightly, so the team could switch without a big upheaval. Trainings helped everyone get started.
Result
The lighthouse project showed that docs-as-code is feasible in a defence setting and makes the work more efficient – backed by evidence, not just claimed.
Tools used: Sphinx-Needs
Feature planning with Sphinx-Needs
At useblocks, demand planning for product features runs in Sphinx-Needs – from customer wish to problem to feature, roadmap and the tasks of the development teams.
- Industry
- Software tools, useblocks (internal)
- Period
- 2025–2026
- My role
- CPO and product owner of a software solution
Problem
Customer wishes come in many ways: from projects, conversations, support requests. It's easy to lose track of where a wish came from, which problem is behind it and what finally came of it.
Product planning at useblocks needed one place where wishes, problems and features are connected – traceable from the first customer conversation into development.
What we did
I built the demand planning with Sphinx-Needs. Customer wishes, problems and features are objects of their own, linked to each other. A workflow defines how a wish is reviewed, assigned to a problem and turned into a feature. A CI system builds and checks everything on every change.
Features are described from the user's point of view: Who needs what, and why? From there, they are broken down and derived into tasks for the development teams. The feature roadmaps come from the same data.
Result
Every customer wish is traceable: which problem it belongs to, which feature solves it and when it ships. The development teams see why they build something, and the roadmap stays connected to the wishes behind it.
Tools used: Sphinx-Needs
Moving legacy data to docs-as-code
A proof of concept at a Tier-1 supplier: requirements, specifications, code and tests of an ECU project in a docs-as-code toolchain – the model was later rolled out across the whole company.
- Industry
- Automotive, Tier-1 supplier, ECU development
- Team
- Project with about 500 people; proof of concept with 3 people and about 40 users
- Period
- 2025
- My role
- Consulting and implementation
Problem
An ECU project with about 500 people had collected data in classic tools for years: software requirements, specifications, code and tests – maintained separately and hard to connect.
Docs-as-code sounded promising. But nobody knew whether it would work with real legacy data and the demands of an automotive project. Before switching, the company needed proof.
What we did
In a proof of concept, a team of 3 moved the legacy data into a docs-as-code toolchain from useblocks: software requirements, specifications, code and tests, linked and traceable in one documentation.
About 40 users worked with it in their daily project work. For the hardware requirements, we created a concept for fitting them into the same structure.
Result
The proof worked: legacy data and new content live in one shared, linked documentation, and the teams work in the tools they already know.
Based on this, the company later rolled out docs-as-code company-wide.
Tools used: Sphinx-Needs, Sphinx-Test-Reports
Docs-as-code for an ADAS project
In the central team of a Tier-1 supplier, I introduced docs-as-code in an ADAS project for an OEM – from data migration, tooling and CI to processes, monitoring and training.
- Industry
- Automotive, Tier-1 supplier and OEM, advanced driver assistance systems (ADAS)
- Team
- ADAS project with up to 1,500 people at the Tier-1 and OEM; central docs-as-code team
- Period
- 2021–2024
- My role
- Consulting, tool development, CI, training and support
Problem
An ADAS project for an OEM, with up to 1,500 people at the Tier-1 and OEM combined. Requirements and tickets lived in classic requirements and ticket tools, and those were not going away overnight.
Docs-as-code was to become the base for requirements, specifications and evidence. That took more than a tool: legacy data, interfaces to the existing tools, a CI that stays fast at this size, and teams willing to come along.
What we did
I was part of the central team that introduced docs-as-code in the project. We moved the legacy data from the requirements and ticket tools into Sphinx-Needs, and I built importers and exporters to keep those tools in sync.
Then came a CI system that builds and checks the documentation. With this much data, performance quickly mattered: I analyzed where Sphinx and Sphinx-Needs lose time and built features and optimizations right into Sphinx, Sphinx-Needs and Sphinx-Test-Reports. To make work in the editor easier, an IDE plugin for Sphinx-Needs came out of it.
Beyond tooling, it was about how people work: I advised on, defined and implemented processes and workflows with the teams. Metrics from CI and the project come together in Grafana dashboards. Trainings and first-level support helped the teams make the switch.
Result
Requirements and evidence live as docs-as-code in the repository, linked and built automatically. The existing tools stay connected through importers and exporters.
The improvements to Sphinx, Sphinx-Needs and Sphinx-Test-Reports went into the open-source projects, so they help others too.
Tools used: Sphinx-Needs, Sphinx-Test-Reports
