How Dotphoton built a fully traceable QA system for the European Space Agency, without hiring a documentation team
This case study was contributed by Dotphoton, a Swiss deep-tech company building image compression for machine vision.
Key takeaway
Dotphoton developed a full quality assurance and requirements traceability system in Grist for the European Space Agency (ESA). The system runs on-prem, meets ESA’s engineering standards, and produces delivery-ready PDFs on demand. Watch a replay of Sanguinetti’s webinar for a live walkthrough of the system described below.
Dotphoton needed a system to track production requirements that met the engineering standards of the European Space Agency, ran on their own infrastructure, and produced audit-ready deliverables on demand. IBM Doors would have required hiring two additional people to manage. Notion’s export failed for regulated PDF work. Word and Excel produced non-reproducible documents that broke cross-references between installations. Bruno Sanguinetti, Dotphoton’s co-founder and CTO, built the system on Grist in two days. It’s now in its third generation, delivering high-quality PDFs in about ten milliseconds through a custom Typst integration, and has extended to become the operational backbone of the company.
The challenge: regulated requirements traceability without a documentation team
Dotphoton builds image compression technology adapted for machine vision. Their work has been integrated into systems used by Samsung, SK Hynix, and the Ariane rocket program.
In 2021, they began a satellite project that required them to build a state-of-the-art image compressor – engineering work held to space-sector standards: every requirement had to trace through a test, through an implementer, through an audit number, and end as a delivery-ready PDF. The project would run for two years, span 40 to 50 separate documents, and produce documentation that had to match the code at every release.
They needed requirements traceability software that could handle this. They did not have one, and the standard options were eliminated one by one.
Word and Excel failed first. The team ran into the pagination problem familiar to any engineering team that has tried this approach: the same 300-page specification opened on two different installations of Microsoft Word came out with different page counts. A page break had shifted between the French installation and the English one. Every cross-reference to “the requirement on page 247” was pointing somewhere else, and there was no clean way to know which version was right. Reconciling them took most of a day.
Notion was the next attempt. The relational database model was closer to what traceability needed, and the editor was pleasant to use. The big issue was exporting. What the team saw in the Notion editor was not what came out in the PDF. For a regulated engineering workflow where the exported PDF is a legal deliverable, this was disqualifying.
IBM Doors was the industry standard for requirements management, and Dotphoton was ready to pay for it. But the license would have required hiring two additional people to manage the tool, and the workflow Doors imposed was not the workflow the team wanted to run. Sanguinetti could not justify the operational overhead on a project where the team was already lean.
Airtable, Monday, and other cloud-based tools were ruled out on data sovereignty. Space-sector engineering work has residency requirements that cloud-only tools cannot meet.
The team was left looking for something that did not exist as a category: a self-hosted, extensible, engineer-friendly application that could handle structured requirements at scale and integrate with a custom document generation pipeline.
Why Grist worked when nothing else did
The team evaluated several spreadsheet-database tools. Grist was the only one that met every criterion:
Self-hosting by default. Dotphoton could deploy Grist on their own infrastructure without negotiating with a vendor, waiting for approval, or paying more for the deployment mode they needed. This alone ruled out most competing tools whose “self-hosted” tier is available only to high-paying enterprise customers.
Stable and robust API. The whole system depended on the ability to read requirements out of the database, feed them into a document generation pipeline, and push the resulting PDFs back into the database. Grist’s REST API supported this out of the box.
Custom widgets. Sanguinetti’s team built a Typst service and wired it to Grist through a custom widget. An engineer clicks a toggle button on a requirement row, a webhook fires, the Typst service pulls the data and template, renders the PDF, and uploads it back to the row as an attachment. The whole cycle takes approximately ten milliseconds. The same operation in their previous quote-generation setup (using HubSpot) took thirty minutes.
Python formulas. Dotphoton’s engineering team runs on Python. Grist’s Python-native formula engine meant that complex logic could live in the database without a separate service layer.
Row-level access rules. Different requirements documents belonged to different projects with different auditors. Grist let the team scope who could see what at the row level, not just the table level.
The interface looked like a spreadsheet. Sanguinetti could hand the system to a non-technical team member and expect them to add requirements, update test results, and trigger PDF generation without training. Structural changes needed more familiarity, but those changes became rare after the application stabilized.
Grist was the only tool that cleared every bar.
The build: three generations, each simpler than the last
The system Dotphoton built on Grist has evolved through three generations.
First generation (2021). Built for the satellite project itself. Deliberately simple,, with tables for requirements, tests, implementers, and audit records with explicit relationships between them. A Python script hit the Grist API, pulled the data as CSV and JSON, and injected it into a LaTeX template. The final PDF, the LaTeX source, the data export, and the code release all went into the same Git repository as a versioned bundle. Every release of the documentation matched a specific commit of the code. Build time: two days for the database. A few days more for the document generation pipeline.
Second generation (post-2023). Used on terrestrial projects after the satellite work closed. Added deeper GitHub integrations. The Grist database could trigger automated tests on GitHub, with results flowing back into Grist to update the requirements’ verification status in real time. The number of tables and features grew.
In retrospect, Sanguinetti admitted that this version was over-built. “We started fairly small. We evolved it a lot. There were maybe too many features.”
Third generation (current). Simpler again. Sanguinetti compares the simplification arc to Picasso’s bison series, where the artist progressively reduced the drawing until only the necessary lines remained. The team removed the integrations that had not proven their value and kept what was working.
Grist remains the database and the interface. GitHub holds the versioned templates and code. A new component, built on the open source typesetting system Typst, handles PDF generation.
What changed for the team
For the satellite project specifically, Dotphoton moved from the five-to-one ratio of documentation-and-planning time to execution time that Sanguinetti had seen on previous space-sector projects, down to a two-to-one or three-to-one ratio. The reduction came from the system doing the cross-referencing, traceability checking, and document generation that engineering teams normally execute manually.
The deliverable PDFs are reproducible. Anyone with access to the Grist file, the GitHub repository, and the Typst service can regenerate the same documentation from the same inputs. This matters for audit work, where the question “can you prove this document matches the code you delivered” now has a clean answer.
The system has extended beyond requirements. The same architectural pattern now runs Dotphoton’s internal CRM, quoting, and financial planning workflows, all on Grist alongside a local LLM that handles tasks like parsing contact information from emails. The system that started as a requirements traceability tool for a satellite project has become the core of how Dotphoton runs the business.
What Dotphoton proves for regulated engineering teams
For engineering teams in regulated industries weighing a legacy requirements management tool against a custom-built alternative, Dotphoton’s experience is one of the clearest demonstrations that the custom-built path works well when it’s built on Grist.
The build was quick to get started. It expanded with some engineering effort, architectural decisions, and three generations of iteration to arrive at the current system. But the total investment over four years is smaller than the licensing cost of the alternative tool over the same period. The system Dotphoton owns is auditable, self-hosted, extensible, and maintained by their own engineering team. It meets the standards of the European Space Agency. It generates delivery-ready PDFs in ten milliseconds. And it has extended, as good infrastructure does, to work the team never originally imagined putting it to.
For Swiss, European, or international engineering teams working to space-sector standards, medical device standards, or defense standards, the open source path is a real option. Dotphoton is proof.
Frequently asked questions
Does Grist meet the compliance requirements of space, defense, or medical device work?
Dotphoton’s setup is in production, complying with the engineering standards of the European Space Agency. The factors that matter to auditors are traceability (the relational structure of the requirements database), reproducibility of deliverables (the Typst integration), auditability of the system itself (Grist is open source and self-hosted), and version control of both data and templates (Git). Grist supports all four directly. Combined with row-level access rules, the setup meets the compliance bar for most regulated engineering work.
How much engineering effort does it take to build this system?
Dotphoton’s first working version took two days for the database and a few days more for the document generation pipeline. That is not the total investment across three generations, which is larger. But the initial usable version was available in days, not months. For teams considering IBM Doors, the effort comparison is not “build vs buy.” It is “build a system you own vs hire two people to run someone else’s tool for years.”
Can non-technical team members maintain the system once built?
For day-to-day work like adding requirements, updating test results, and triggering PDF generation, yes. Grist’s interface looks like a spreadsheet, and adding a requirement is like adding a row to Excel. Structural changes like adding new tables or modifying relationships need someone with more familiarity, but those changes are rare once the application stabilizes.
How does this compare to the cost of a legacy tool like IBM Doors?
Dotphoton avoided the IBM Doors license, which alone runs into the tens of thousands of euros per year, and the additional headcount that would have been required to manage it. They invested labor in building the system, but the labor was their own engineering time, applied incrementally, and the resulting system is one they own, can extend, and can modify as their needs change. Over four years, the total investment is smaller than the licensing cost of the alternative over the same period.
Does this pattern extend beyond requirements traceability?
Dotphoton has extended the same architectural pattern (Grist as the source of truth, Git for versioning, custom services for the domain-specific processing) to their CRM, quote generation, and financial planning workflows. The pattern is not specific to requirements or to the space sector. Any workflow that needs structured data, reproducible outputs, and auditability across time is a candidate.
Ready to build with Grist?
Grist’s custom widget framework, full API access, and self-hosting options give engineering teams the infrastructure to build requirements traceability systems on their own terms.
- Read the full pattern write-up on how regulated engineering teams put together their own setup
- Watch Sanguinetti’s webinar for the full live walkthrough
- Book a 15-minute call to talk through your team’s situation
- Try Grist free or request a demo
