Building a HVAC SaaS Platform as a Solo Mechanical Engineer

The Spreadsheet That Started It All

It was a Tuesday afternoon in 2023. I was sitting at my desk at Sasez GmbH, deep into a heating load calculation for a 40-unit residential building in Berlin-Mitte. My workflow looked like this:

1. Open the DIN EN 12831 Excel template
2. Look up climate data for Berlin from a separate PDF
3. Manually enter U-values for each building envelope component from yet another table
4. Copy room dimensions from the Revit model
5. Run the calculation, check the results, adjust
6. Format everything into a client-ready PDF report

Four hours. For one building. And I'd done this exact same workflow hundreds of times.

That evening, I opened my code editor instead of Netflix. Six months later, I had a working prototype. Today, that prototype is Mepbau — a cloud-based HVAC/HKLS calculation platform with seven integrated modules covering the core German building services standards.

This is the story of how it happened, what I learned, and what I'd do differently.

Why HVAC Calculations Are Stuck in the 90s

The German MEP industry runs on a handful of desktop tools — Solar Computer, Hottgenroth, Trimble Nova — supplemented by mountains of Excel spreadsheets. These tools work, but they share common problems:

• Desktop-only. No collaboration, no cloud sync, no working from the job site.
• Expensive. Annual licenses run €2,000–€8,000+, pricing out smaller firms and freelancers.
• Siloed. Each tool handles one standard. Heating load in one app, cooling in another, ventilation in a third. No data flows between them.
• Opaque. Results come out as numbers with no clear audit trail back to the standard.

For a solo SHK contractor or a small energy consulting firm, the options are: pay thousands for fragmented desktop software, or do everything in Excel. Most choose Excel.

I thought there had to be a better way.

The MVP: One Standard, One Module

The biggest mistake I could have made was trying to build all seven modules at once. Instead, I started with the one calculation I did most often: DIN EN 12831 — Heating Load Calculation.

The MVP scope was deliberately narrow:

• Define a building with rooms, walls, windows, and doors
• Input or look up U-values for each component
• Select climate data by location
• Calculate transmission and ventilation heat losses per DIN EN 12831
• Generate a PDF report

No user accounts. No payment. No other standards. Just one calculation, done correctly, in a web browser.

Why Python for the Calculation Engine?

HVAC calculations are math-heavy with lots of lookup tables, interpolation, and edge cases. I needed a language that handled numerical computation well and had a rich ecosystem for engineering work. Python was the clear choice — its scientific computing libraries and straightforward syntax made it ideal for translating DIN standard formulas into a working calculation engine.

The key design decision: model the calculation domain exactly as the standard describes it. A building has zones, zones have rooms, rooms have envelope components (walls, windows, roofs, floors). Each component carries a U-value, an area, and correction factors. The formulas chain together just as they appear in the standard — transmission heat losses, ventilation heat losses, and reheat capacity sum to the total heating load.

The Architecture

The platform has three core layers:

• Frontend (Next.js + TypeScript) — Multi-step forms that guide users through data input. Deployed on Vercel.
• Backend (FastAPI + Python) — The API layer that receives building data, runs calculations, and returns results with full audit trails.
• Calculation Engine (Pure Python) — The heart of Mepbau. DIN/VDI standard formulas encoded as Python, completely decoupled from the web layer.

Supporting services:

• Supabase for authentication, PostgreSQL database, and row-level security to keep projects isolated per user.
• Stripe for subscription billing with per-module pricing.
• Turborepo for monorepo management.

Why Not a Single App?

I considered building everything as one Next.js application. The dealbreaker: Python's numerical computing ecosystem. Libraries for interpolation, curve fitting, and the ability to directly encode DIN lookup tables made the calculation engine dramatically simpler in Python than it would have been in JavaScript. The tradeoff is operational complexity — two services to deploy instead of one. Worth it.

Expanding to Seven Modules

Once DIN EN 12831 was working, I expanded module by module:

Each module follows the same pattern:

1. Encode the standard — Tables, formulas, and decision trees translated into structured logic
2. Build the API — An endpoint with strict input validation to catch errors early
3. Build the UI — A multi-step form that collects inputs, calls the API, and displays results
4. Generate the report — PDF output matching the format engineers expect

The hardest part isn't the software — it's reading and interpreting the standards. DIN EN 12831 alone is 120+ pages of dense technical German. VDI 2078 requires hour-by-hour solar radiation data. Every edge case in the standard is a potential error in the software.

The Hardest Lessons

1. Precision Is Not Optional

When an engineer puts their stamp on a calculation, they're personally liable. If my software produces a wrong heating load and the building freezes, that's not a UX issue — it's a legal problem.

I validate every module against hand calculations and reference software output. The test suite for the heating load module alone has 200+ test cases covering different building geometries, construction types, and climate zones. Every test references a specific example or table in the DIN standard so I can trace any discrepancy back to its source.

2. German Building Codes Are a Maze

The standards reference each other constantly. DIN EN 12831 tells you to calculate ventilation rates "per DIN 1946-6." DIN 1946-6 says to use building envelope airtightness values "per DIN 4108-7." DIN 4108-7 references measurement procedures in DIN EN 13829.

You can't implement one standard in isolation. The dependency graph is deep, and getting a single number — like the infiltration air volume flow for a room — might require traversing three or four standards.

3. Trust Is Hard to Earn

Engineers don't switch tools easily. They've been using Solar Computer or Hottgenroth for 10+ years. Their workflows are built around these tools. Switching to a web app from an unknown solo developer requires a leap of faith.

What helps: transparency. Mepbau shows every intermediate value in the calculation, with references back to the specific clause in the DIN standard. Engineers can follow the math step by step and verify it against their own understanding.

4. Start With User Interviews, Not Code

This is my biggest regret. I built the MVP based on my own pain points as a BIM engineer. But I'm not the typical customer — I'm more technical than the average SHK contractor or energy consultant.

When I finally started talking to potential users, I learned that their biggest pain point wasn't the calculation accuracy — it was the report formatting. They needed outputs that matched what building authorities expect to see. The calculation engine was table stakes; the report was the product.

If I could go back, I'd spend two weeks interviewing 20 potential users before writing a single line of code.

The Business Model

Mepbau uses a freemium model with per-module pricing:

• Free tier — Basic heating load calculation for a single building (limited rooms)
• Pro modules — Monthly subscription per module (heating, cooling, ventilation, etc.)
• Bundle — All 7 modules at a discounted rate

The target customers are small to mid-size SHK contractors (Sanitär-Heizung-Klima), energy consultants, and architectural firms in Germany, Austria, and Switzerland — the DACH region where DIN/VDI standards apply.

What I'd Do Differently

1. User interviews first. Two weeks of conversations would have saved two months of building the wrong features.
2. Start with the report, not the calculation. The report is what customers actually deliver to their clients. Build backwards from there.
3. Pick one customer segment. "SHK contractors, energy consultants, and homeowners" is three different products. I should have picked one and gone deep.
4. Ship faster, validate faster. My engineering instinct was to make the calculation perfect before showing it to anyone. In startup terms, that's a mistake.

Where It Stands Today

Mepbau is live at mepbau.com with all seven modules functional. I'm iterating based on early user feedback while holding down my day job as a Fachplaner at UNDKRAUSS.

Building a SaaS while working full-time in the same industry has an unexpected advantage: every day at work, I encounter the problems my software is trying to solve. The feedback loop is immediate and visceral.

The HVAC industry is slowly moving to the cloud. The question isn't whether it will happen — it's who builds the tools that engineers actually trust. I'm betting that it'll be engineers themselves.

If you're building software for the AEC/MEP industry or thinking about it, I'd love to compare notes. Reach out at hello@laborsam.com.