Eine HVAC-SaaS-Plattform als Solo-Maschinenbauingenieur aufbauen

Die Excel-Tabelle, mit der alles begann

Es war ein Dienstagnachmittag im Jahr 2023. Ich saß an meinem Schreibtisch bei der Sasez GmbH und arbeitete an einer Heizlastberechnung für ein 40-Einheiten-Wohngebäude in Berlin-Mitte. Mein Workflow sah so aus:

1. Die DIN EN 12831 Excel-Vorlage öffnen
2. Klimadaten für Berlin aus einer separaten PDF nachschlagen
3. U-Werte für jede Gebäudehüllkomponente manuell aus einer weiteren Tabelle eintragen
4. Raummaße aus dem Revit-Modell kopieren
5. Berechnung durchführen, Ergebnisse prüfen, anpassen
6. Alles in einen kundengerechten PDF-Bericht formatieren

Vier Stunden. Für ein Gebäude. Und ich hatte diesen exakt gleichen Workflow schon hunderte Male durchgeführt.

An diesem Abend öffnete ich meinen Code-Editor statt Netflix. Sechs Monate später hatte ich einen funktionierenden Prototyp. Heute ist dieser Prototyp Mepbau — eine cloudbasierte HKLS-Berechnungsplattform mit sieben integrierten Modulen, die die wichtigsten deutschen Gebäudetechnik-Normen abdecken.

Dies ist die Geschichte, wie es dazu kam, was ich gelernt habe und was ich anders machen würde.

Warum HLK-Berechnungen in den 90ern feststecken

Die deutsche TGA-Branche läuft mit einer Handvoll Desktop-Tools — Solar Computer, Hottgenroth, Trimble Nova — ergänzt durch Berge von Excel-Tabellen. Diese Tools funktionieren, aber sie teilen gemeinsame Probleme:

• Nur Desktop. Keine Zusammenarbeit, keine Cloud-Synchronisation, kein Arbeiten von der Baustelle aus.
• Teuer. Jährliche Lizenzen kosten 2.000–8.000+ €, was kleinere Büros und Freiberufler ausschließt.
• Isoliert. Jedes Tool beherrscht eine Norm. Heizlast in einer App, Kühllast in einer anderen, Lüftung in einer dritten. Kein Datenfluss dazwischen.
• Intransparent. Ergebnisse kommen als Zahlen ohne klare Nachvollziehbarkeit zurück zur Norm heraus.

Für einen Solo-SHK-Handwerker oder ein kleines Energieberatungsbüro sind die Optionen: Tausende für fragmentierte Desktop-Software zahlen oder alles in Excel machen. Die meisten wählen Excel.

Ich dachte, es muss einen besseren Weg geben.

Das MVP: Eine Norm, ein Modul

Der größte Fehler, den ich hätte machen können, wäre gewesen, alle sieben Module gleichzeitig zu bauen. Stattdessen begann ich mit der Berechnung, die ich am häufigsten durchführte: DIN EN 12831 — Heizlastberechnung.

Der MVP-Umfang war bewusst eng gefasst:

• Ein Gebäude mit Räumen, Wänden, Fenstern und Türen definieren
• U-Werte für jede Komponente eingeben oder nachschlagen
• Klimadaten nach Standort auswählen
• Transmissions- und Lüftungswärmeverluste nach DIN EN 12831 berechnen
• Einen PDF-Bericht generieren

Keine Benutzerkonten. Keine Zahlung. Keine anderen Normen. Nur eine Berechnung, korrekt durchgeführt, in einem Webbrowser.

Warum Python für den Berechnungskern?

HLK-Berechnungen sind rechenintensiv mit vielen Nachschlagetabellen, Interpolationen und Sonderfällen. Ich brauchte eine Sprache, die numerische Berechnungen gut beherrscht und ein reichhaltiges Ökosystem für Ingenieurarbeit bietet. Python war die klare Wahl — mit seinen wissenschaftlichen Bibliotheken und seiner übersichtlichen Syntax ideal, um DIN-Norm-Formeln in einen funktionierenden Berechnungskern zu übersetzen.

Die wichtigste Entwurfsentscheidung: das Berechnungsmodell genau so zu modellieren, wie es die Norm beschreibt. Ein Gebäude hat Zonen, Zonen haben Räume, Räume haben Hüllflächenkomponenten. Jede Komponente trägt einen U-Wert, eine Fläche und Korrekturfaktoren. Die Formeln verketten sich genau so, wie sie in der Norm erscheinen.

Die Architektur

Die Plattform hat drei Kernebenen:

• Frontend (Next.js + TypeScript) — Mehrstufige Formulare, die den Nutzer durch die Dateneingabe führen. Bereitgestellt auf Vercel.
• Backend (FastAPI + Python) — Die API-Schicht, die Gebäudedaten empfängt, Berechnungen durchführt und Ergebnisse mit vollständigen Nachweisen zurückgibt.
• Berechnungskern (reines Python) — Das Herzstück von Mepbau. DIN/VDI-Normformeln als Python-Code, vollständig entkoppelt von der Web-Schicht.

Unterstützende Dienste:

• Supabase für Authentifizierung, PostgreSQL-Datenbank und Row-Level-Security.
• Stripe für Abo-Abrechnungen mit modulweiser Preisgestaltung.
• Turborepo für Monorepo-Management.

Erweiterung auf sieben Module

Nachdem DIN EN 12831 funktionierte, erweiterte ich Modul für Modul:

Jedes Modul folgt dem gleichen Muster:

1. Die Norm kodieren — Tabellen, Formeln und Entscheidungsbäume in strukturierte Logik übersetzen
2. Die API bauen — Ein Endpunkt mit strikter Eingabevalidierung
3. Die UI bauen — Ein mehrstufiges Formular, das Eingaben sammelt, die API aufruft und Ergebnisse darstellt
4. Den Bericht generieren — PDF-Ausgabe im von Ingenieuren erwarteten Format

Der schwierigste Teil ist nicht die Software — es ist das Lesen und Interpretieren der Normen. Allein DIN EN 12831 umfasst 120+ Seiten dichten technischen Texts. VDI 2078 erfordert stündliche Solarstrahlungsdaten. Jeder Sonderfall in der Norm ist ein potenzieller Fehler in der Software.

Die härtesten Lektionen

1. Genauigkeit ist keine Option

Wenn ein Ingenieur eine Berechnung stempelt, haftet er persönlich. Wenn meine Software eine falsche Heizlast berechnet und das Gebäude friert, ist das kein UX-Problem — es ist ein rechtliches Problem.

Ich validiere jedes Modul gegen Handberechnungen und Referenz-Software-Ergebnisse. Die Test-Suite allein für das Heizlastmodul hat 200+ Testfälle, die verschiedene Gebäudegeometrien, Konstruktionstypen und Klimazonen abdecken.

2. Deutsche Bauvorschriften sind ein Labyrinth

Die Normen verweisen ständig aufeinander. DIN EN 12831 sagt, man solle die Lüftungsraten „nach DIN 1946-6" berechnen. DIN 1946-6 sagt, man solle Gebäudehüllen-Luftdichtheitswerte „nach DIN 4108-7" verwenden. DIN 4108-7 verweist auf Messverfahren in DIN EN 13829.

Man kann keine Norm isoliert implementieren. Der Abhängigkeitsgraph ist tief, und eine einzige Zahl zu ermitteln — wie den Infiltrations-Luftvolumenstrom eines Raumes — kann das Durchqueren von drei oder vier Normen erfordern.

3. Vertrauen ist schwer zu gewinnen

Ingenieure wechseln nicht leicht ihre Tools. Sie nutzen Solar Computer oder Hottgenroth seit 10+ Jahren. Ihre Workflows sind um diese Tools herum aufgebaut. Zu einer Web-App von einem unbekannten Solo-Entwickler zu wechseln, erfordert einen Vertrauensvorschuss.

Was hilft: Transparenz. Mepbau zeigt jeden Zwischenwert der Berechnung, mit Verweisen auf die spezifische Klausel in der DIN-Norm. Ingenieure können die Mathematik Schritt für Schritt nachvollziehen.

4. Erst Nutzerinterviews, dann Code

Das ist mein größtes Bedauern. Ich baute das MVP basierend auf meinen eigenen Schmerzpunkten als BIM-Ingenieur. Aber ich bin nicht der typische Kunde — ich bin technischer als der durchschnittliche SHK-Handwerker oder Energieberater.

Als ich endlich anfing, mit potenziellen Nutzern zu sprechen, erfuhr ich, dass ihr größter Schmerzpunkt nicht die Berechnungsgenauigkeit war — es war die Berichtsformatierung. Sie brauchten Ausgaben, die dem entsprechen, was Baubehörden erwarten. Der Berechnungskern war Grundvoraussetzung; der Bericht war das Produkt.

Das Geschäftsmodell

Mepbau verwendet ein Freemium-Modell mit modulweiser Preisgestaltung:

• Kostenlose Stufe — Grundlegende Heizlastberechnung für ein einzelnes Gebäude
• Pro-Module — Monatsabo pro Modul (Heizung, Kühlung, Lüftung etc.)
• Paket — Alle 7 Module zum reduzierten Preis

Die Zielkunden sind kleine bis mittelgroße SHK-Betriebe, Energieberater und Architekturbüros in Deutschland, Österreich und der Schweiz.

Was ich anders machen würde

1. Nutzerinterviews zuerst. Zwei Wochen Gespräche hätten zwei Monate Entwicklung der falschen Features gespart.
2. Mit dem Bericht beginnen, nicht mit der Berechnung. Der Bericht ist das, was Kunden tatsächlich an ihre Auftraggeber liefern.
3. Ein Kundensegment wählen. „SHK-Handwerker, Energieberater und Eigenheimbesitzer" sind drei verschiedene Produkte.
4. Schneller ausliefern, schneller validieren. Mein Ingenieur-Instinkt war, die Berechnung perfekt zu machen, bevor ich sie jemandem zeige. In Startup-Begriffen ist das ein Fehler.

Wo es heute steht

Mepbau ist live auf mepbau.com mit allen sieben funktionierenden Modulen. Ich iteriere basierend auf frühem Nutzerfeedback, während ich meinen Vollzeitjob als Fachplaner bei UNDKRAUSS behalte.

Ein SaaS zu bauen, während man Vollzeit in der gleichen Branche arbeitet, hat einen unerwarteten Vorteil: Jeden Tag bei der Arbeit begegne ich den Problemen, die meine Software lösen soll. Die Feedback-Schleife ist unmittelbar.

Die HLK-Branche bewegt sich langsam in die Cloud. Die Frage ist nicht, ob es passieren wird — sondern wer die Tools baut, denen Ingenieure tatsächlich vertrauen.

Wenn Sie Software für die TGA-Branche bauen oder darüber nachdenken — ich freue mich über den Austausch. Schreiben Sie mir an hello@laborsam.com.