Docs-as-code · AI · SW tools
SW tools, helpful as hell – and a crew of monsters.
I'm Daniel. I build SW tools that help large teams keep their knowledge, their quality and their decisions under control.
Tools
What I'm working on – some tools already in code, some still an idea.
Alpha
deciwa
Feedback and approvals right on your docs, websites and code – so it's clear what is confirmed and what the AI still has to do.
Learn more →Prototype
monsterbrain
A brain for people and AI agents: knowledge, concepts and results in one clear folder structure.
Learn more →Idea
quawa
Checks whether the tests of AI-written code really test.
Learn more →Idea
faktwerk
Maintain knowledge once and show it the right way for every role – always consistent.
Learn more →
Views
Good views make complex relations clear in seconds; bad ones hide them. I care about how to show information, data structures and workflows from large projects so that people sense problems instead of having to read them.
See the views →
Toolchain comparison
A free toolchain comparison spreadsheet with more than 160 user requirements from automotive docs-as-code projects – for tool decisions based on facts instead of gut feeling.
Read more →
Documentation as code in automotive system/software engineering
The best overview I know of docs-as-code in a professional automotive project: Dr. Momcilo Krunic's paper on an ASPICE-compliant setup with 150 engineers – republished with his permission.
Read more →
Manager POV: What's the benefit of docs-as-code?
A fictitious conversation with a project manager of a 500-person automotive software project: why documentation quality suffers in expert tools and how docs-as-code helps.
Read more →
Ideas
Things I'd like to build – not started yet, but thought through. They're about problems I keep running into: docs that don't match the code, metrics nobody sees, architecture and requirements that know nothing about each other. If any of it catches your eye, let's talk.
Browse the ideas →
About me
I'm a software developer, and what I like building most are tools that make other people's work easier. That's why I founded useblocks, where I helped build Sphinx-Needs and many other docs-as-code tools as team lead – they run in large engineering projects today. These days I support useblocks as an advisor.
What drives me is how large, distributed teams keep track – of requirements, tests, decisions and the knowledge in between. My tools are small and focused: each one solves exactly one problem.
More about me →