Cut 20 hours off every building documentation project

What it is

Bauwerksbuch Wien (bauwerksbuch-erstellen.wien) is a live SaaS platform for building documentation under § 128a of the Vienna Building Code. Austrian law obliges owners of certain buildings to keep a Bauwerksbuch — a statutory building logbook recording the building's condition, inspections, and maintenance in a form that has to hold up under scrutiny. Until now people did this in Word files, loose PDFs, and archive boxes.

I'm not an architect and I don't know building law. My aunt does — she's a licensed Ziviltechnikerin (chartered architect and civil engineer, a regulated profession in Austria) and a court-certified expert witness. She knew exactly what the product had to do. I built it.

Achievements

- It's live and in real use. Five buildings documented and delivered as compliant Bauwerksbücher — not demos.

- I cut 20 hours off every building. For a typical Gründerzeit building (a late 19th-century Viennese apartment block) with well over a hundred documented components and photographs, putting the document together — the tables, placing and formatting the images, writing up the condition of each component, generating the final PDF — used to take around 30 hours. It now takes around 10.

- I deliberately left the rest alone. The site inspection, the professional assessment, and the expert's final review are untouched. Those need a licensed professional, and automating them would have made the product worthless.

- Five practising architects and Baumeister (licensed master builders) tested it on their own projects.

- Two property management firms are in active discussions with us covering roughly 120 buildings.

- I built and run the whole thing myself: Express/Node.js, PostgreSQL, and self-hosted MinIO object storage, all on Northflank in a Frankfurt data centre.

Tools

- Claude Cowork for the regulatory groundwork. I put the Vienna Building Code into a project and worked through it there to get at the documentation structure, the component catalogue, and the assessment checklists the software had to implement.

- Claude Code for everything I built. The entire platform was written in it — application code, database layer, PDF generation, automation jobs, deployment.

- Custom Skills to hold the domain knowledge: a bauwerksbuch skill for product and regulatory context, a northflank skill so Claude stops inventing API calls against my own infrastructure, and an anti-hallucination skill that makes me verify any claimed capability before I use it.

- Stack: Express/Node.js, PostgreSQL, self-hosted MinIO — hosted in Frankfurt, Germany. PDFs are generated locally with Puppeteer and pdf-lib. No model is involved at any point.

Methodology

I'm not an architect and I don't know building law. That was the whole problem to solve.

What I had was a domain expert in the family and no idea how to turn twenty years of her knowledge into software without losing half of it in translation.

So we split it in two. First we put the Vienna Building Code into a Claude Cowork project and worked through it together. I'd ask what § 128a actually requires — which components, what evidence, what structure — and she'd check every reading against the statute before we wrote it down. That gave me a specification I could build from: in her language, verified by her.

Then I built it in Claude Code. The whole platform. Nothing shipped with a legal statement in it that she hadn't read.

Two things I'd do again:

I checked what Claude proposed before using it. Every API call, every config option, every reference to the law. Not after something broke — before. I ended up writing two custom Skills purely to force myself into that habit, because the failure mode here isn't code that crashes. It's code that runs and is quietly wrong.

I wrote the domain knowledge down as Skills instead of re-explaining it every session. That's what let me keep pace with someone who's been doing this for two decades. I wasn't learning her field. I was making it available to the model, once, properly.

Data protection

We're a processor under Art. 4(8) GDPR — the property owners and managers stay in control of their own building records. This was the part I got right early, and it's turned out to be our strongest argument in sales.

- The AI is in my toolchain, not in the product. I built the platform with Claude. The running product makes no calls to any AI model. Documents are generated locally with Puppeteer and pdf-lib. No customer data is ever sent to a model provider — our privacy policy states this explicitly, and it holds at the code level.

- Everything sits in Europe. Application, database, and object storage all run in a Frankfurt data centre. Object storage is self-hosted MinIO rather than a third-party service, so there's one fewer processor in the chain. No data leaves the EU.

- There's very little personal data to begin with. Components, condition assessments, structural documentation — none of that is personal data. What we hold is user accounts and inspection photography, and the photography is pointed at building fabric, not people.

- Legal basis: the statutory documentation obligation under § 128a (Art. 6(1)(c) GDPR) and performance of the service contract (Art. 6(1)(b) GDPR).

- Processing agreements under Art. 28 GDPR with both processors: the hosting provider and an EU-based transactional email service. That's the entire list.

- Defined retention periods, published in our privacy policy: account data three years after contract end, tax-relevant records seven years under § 132 BAO, building documentation for as long as building law requires it.

- Security. Passwords are stored only as bcrypt hashes and all traffic runs over TLS. Documents and photographs aren't publicly reachable — they're served through an authenticated proxy that checks permissions on every request, so a leaked URL gets you nothing. Storage volumes and backups are encrypted at rest by our hosting provider. Sessions use tokens only: no tracking cookies, no analytics, and fonts served from our own server rather than Google.

- A human signs everything that matters. No professional or legal assessment is produced automatically. Every finding that carries liability is made and signed by the licensed expert.

Learnings

- Writing her professional judgement down as Skills was the single highest-leverage thing I did. Generic assistance gives generic output. A Skill that knows how an Austrian expert witness phrases a finding produces something she'll actually put her name on.

- Knowing what not to automate mattered as much as knowing what to automate. I took 20 hours out of document production and left the assessment completely alone. In a field where someone signs under professional liability, that line is the product.

- We lost a contract to a competitor and learned more from it than from anything we won. The lesson: ask early whether a prospect wants a building logbook or a complete property-management system. Those are different products, and we'd been pitching the wrong one.

Relevant URLs

- https://bauwerksbuch-erstellen.wien

Attachments

- Screen recording: a full run, from capturing a component on site through to the finished statutory building logbook. Client details removed.