Gebäude sind für einen großen Anteil der weltweiten Emissionen verantwortlich, und die meisten Eigentümer haben kaum Einblick, wo ihr Portfolio tatsächlich steht. Als freiberuflicher Entwickler habe ich mit Predium genau an diesem Problem gearbeitet: einer Plattform, die Immobilienunternehmen hilft, ihren ökologischen Fußabdruck zu verstehen, Sanierungen zu planen und dabei Kosten zu senken. Es ist eines der seltenen Projekte, in denen gutes Engineering und ein lohnendes Ergebnis in dieselbe Richtung zeigen.
Ein typisierter Pfad von der Datenbank bis zur UI
Das Rückgrat des Produkts ist eine GraphQL-API auf Basis von Hasura, Prisma und PostgreSQL, und diese Kombination hat viel Schwerstarbeit geleistet. Hasuras CLI und Echtzeitfähigkeiten erlaubten uns, schnell voranzukommen, ohne für jeden Lesezugriff Resolver von Hand zu schreiben. Prisma kümmerte sich um Migrationen und das aufwendigere SQL — und, ebenso wichtig, generierte TypeScript-Typen, denen wir durchgängig vertrauen konnten.
Typen, die vom Schema bis zur UI fließen, beseitigen still und leise eine ganze Klasse von Bugs, die du sonst in der Produktion findest.
Genau dieser eine typisierte Vertrag, von der Datenbank über die API bis zu einem React-Frontend, hielt eine schnell wachsende Codebasis davon ab, ins Raten abzudriften.
Struktur im Backend
Für die Service-Schicht wählten wir NestJS statt eines nackten Express-Servers. Der Reiz liegt in seiner architektonischen Meinungsstärke: Module, Dependency Injection und klare Grenzen, die auch bei wachsender Oberfläche tragen. Express ist für etwas Kleines in Ordnung, aber auf einer Plattform, die ständig Features ansetzt, zahlt sich die Struktur, die NestJS vorgibt, in Wartbarkeit aus.
Frontend und Infrastruktur
Die Oberfläche ist React 18 mit Material UI — Werkzeuge, die ich ausgiebig genutzt habe und die uns erlaubten, eine moderne, responsive Erfahrung zu liefern, ohne die Grundlagen neu zu erfinden. Alles läuft auf AWS, das sich durch Zuverlässigkeit und Breite weiterhin seinen Platz verdient und dem Team Raum gab, den Betrieb sicher zu skalieren.
Warum es funktioniert
Der eigentliche Multiplikator war das Team: klein, agil und der Mission wirklich verpflichtet. Eine projektorientierte Haltung und ein gemeinsames Zielbewusstsein sorgten dafür, dass technische Entscheidungen nah an der realen Wirkung blieben. Nachhaltigkeit und solides Engineering stehen nicht im Widerspruch — hier verstärkten sie einander, ein Gebäude nach dem anderen.