Proptech-Softwareentwicklung: Die Architekturentscheidungen, die Immobilien-SaaS prägen

Die meisten Proptech-Produkte scheitern nicht daran, dass der Markt zu klein wäre. Der europäische Markt für Immobiliensoftware wächst weiter, und Makler, Hausverwaltungen und Vermieter erledigen große Teile ihres Geschäfts noch immer mit Tabellen und E-Mails. Proptech-Produkte scheitern, weil eine Handvoll früher Architekturentscheidungen still und leise begrenzt, was aus dem Produkt werden kann. Proptech-Softwareentwicklung ist in dieser Hinsicht ungewöhnlich: Die Domäne wirkt von außen simpel, ein Inserat hat Fotos, einen Preis und eine Adresse, aber hinter jedem dieser Begriffe steckt eine Datenmodellierungsfalle, die erst bei Skalierung sichtbar wird.

Dieser Beitrag geht die Entscheidungen durch, die unserer Erfahrung nach die Entwicklung von Immobilien-SaaS bestimmen: das Listing-Datenmodell, die Geo-Suche, Medien-Pipelines, Portal-Integrationen, das Rollenmodell, den DSGVO-Umgang und das Dokumentenmanagement. Wenn du als Gründer oder CTO gerade einen Proptech-Build scopest, behandle diese Punkte als Fragen, die vor dem ersten Sprint zu klären sind, nicht nach dem ersten Enterprise-Deal.

Das Listing-Datenmodell ist keine Produkttabelle

Der erste Instinkt in der Proptech-Softwareentwicklung ist, ein Immobilieninserat wie ein E-Commerce-Produkt zu modellieren: eine Tabelle, ein paar Spalten, ein Kategoriefeld. Dieses Modell bricht schnell zusammen, aus drei Gründen.

Erstens: Eine Immobilie ist kein Inserat. Das physische Objekt (eine Wohnung in Berlin) ist stabil, während Inserate dazu kommen und gehen: dieses Jahr ein Mietinserat, nächstes Jahr ein Verkaufsinserat, manchmal beides gleichzeitig über verschiedene Makler. Wenn du beides vermischst, verlierst du Historie, duplizierst Adressdaten und kannst grundlegende Fragen wie "Wofür wurde diese Einheit zuletzt vermietet?" nicht beantworten. Modelliere Objekt und Inserat von Tag eins an als getrennte Entitäten, wobei das Inserat auf das Objekt referenziert.

Zweitens variieren Attribute stark nach Assetklasse und Land. Ein deutsches Wohninserat braucht Kaltmiete und Nebenkosten, eine Energieausweisklasse und das Stockwerk im Gebäude. Eine spanische Ferienvermietung braucht eine Touristenlizenznummer. Eine britische Gewerbeeinheit braucht den Rateable Value. Diese als nullable Spalten fest zu verdrahten produziert eine Tabelle mit 200 überwiegend leeren Feldern. Das Muster, das trägt, ist ein stabiler Kern (Adresse, Geo-Punkt, Assetklasse, Status, Preisfelder) plus eine validierte Attributstruktur mit Schema pro Assetklasse, in PostgreSQL typischerweise eine JSONB-Spalte mit Validierung auf Anwendungsebene pro Assetklasse und Land.

Drittens ist Verfügbarkeit ein First-Class-Konzept, kein Boolean. Mietobjekte haben Verfügbarkeitsdaten, Besichtigungen werden gegen Kalender-Slots gebucht, und Kurzzeitvermietung braucht volle Kalendersemantik mit Preisen pro Zeitraum. Wenn irgendetwas Kalenderförmiges auf deiner Roadmap steht, modelliere Verfügbarkeit früh als Zeiträume in einer eigenen Tabelle. Kalenderlogik nachträglich auf ein is_available-Flag aufzusetzen ist eine der teuersten Migrationen, die wir in Legacy-Modernisierungsprojekten sehen.

Geo-Suche: Entscheide, wo die Suche lebt, bevor du sie brauchst

Jedes Immobilienprodukt ist ein Suchprodukt. Käufer suchen nach Kartenausschnitt, Radius, Stadtteil und Pendelzeit und erwarten Filter obendrauf: Preisspanne, Zimmer, Assetklasse, Ausstattung. Die Architekturfrage ist, wo diese Suche läuft.

Für die meisten Teams ist die richtige erste Antwort PostgreSQL mit PostGIS. Ein GiST-Index auf einer Geography-Spalte trägt Viewport- und Radius-Abfragen bis in die Millionen von Inseraten, und die Suche in der Primärdatenbank zu halten bedeutet: keine Synchronisationspipeline, keine Eventual-Consistency-Bugs, bei denen eine verkaufte Wohnung noch auf der Karte auftaucht. Kombiniere PostGIS mit Standard-B-Tree-Indizes auf Preis und Zimmern, und du deckst die reale Query-Last eines Produkts in Portalgröße ab.

Greif erst dann zu einer dedizierten Suchmaschine, wenn du eine konkrete Anforderung hast, die PostGIS nicht erfüllt: intensive Volltextsuche über Beschreibungen in mehreren Sprachen, facettierte Zählungen für jede Filterkombination oder Search-as-you-type über zig Millionen Dokumente. Und wenn du es tust, behandle den Suchindex als wegwerfbare Projektion der Datenbank, jederzeit von Grund auf neu aufbaubar, niemals als zweite Quelle der Wahrheit.

Ein strukturelles Detail zählt mehr als die Engine-Wahl: Geocode beim Schreiben, nicht beim Lesen. Adressen werden einmal geocodiert, wenn ein Inserat angelegt oder bearbeitet wird, die Ergebnisse werden gespeichert, und Fehler werden dem Makler zur manuellen Pin-Platzierung angezeigt. Produkte, die lazy beim Anzeigen geocodieren, enden mit Rate-Limit-Vorfällen und Karten voller Pins in der falschen Stadt.

Medien-Pipelines: Fotos sind deine schwerste Workload

Ein ernsthaftes Inserat trägt 20 bis 50 Fotos, Grundrisse und zunehmend Video und 3D-Touren. Medien sind meist der größte Infrastrukturkostenblock und die häufigste Quelle von Produktionsvorfällen in Immobilien-SaaS.

Die Pipeline, die funktioniert: Direktuploads vom Browser in den Objektspeicher per Presigned URLs, sodass Bildbytes nie über deine Anwendungsserver laufen, gefolgt von asynchroner Verarbeitung in einer Queue, die die Größenvarianten erzeugt, EXIF-Daten entfernt (Standortmetadaten in Fotos von jemandes Zuhause sind ein Datenschutzproblem, kein Nice-to-have) und Validierung ausführt. Liefere alles über ein CDN aus, mit vorab statt on the fly erzeugten Varianten, denn portal-syndizierte Inserate bekommen Traffic-Spitzen, die du nicht kontrollierst.

Die Reihenfolge zählt kommerziell: Makler sind besessen von der Fotoreihenfolge, weil das erste Bild das Inserat verkauft. Modelliere eine explizite Sortierreihenfolge und mach Umsortieren billig. Es klingt trivial, und es ist genau die Art von Feature, die schmerzhaft wird, wenn die Medientabelle als Nachgedanke entworfen wurde.

Portal-Integrationen prägen mehr von deiner Architektur, als du erwartest

Kaum ein europäisches Proptech-Produkt lebt allein. Inserate syndizieren zu Portalen wie ImmobilienScout24 in Deutschland, Rightmove und Zoopla in Großbritannien und Idealista in Spanien, und Daten fließen aus Feeds und CRM-Importen herein. Wer die Integrationsschicht besitzt, besitzt ein dauerhaftes Engineering-Commitment, und drei Entscheidungen bestimmen, ob es beherrschbar bleibt.

Baue ein kanonisches internes Modell und übersetze an den Rändern. Jedes Portal hat seine eigenen Formatmacken und Feldvokabulare. In dem Moment, in dem portalspezifische Konzepte in dein Kern-Datenmodell durchsickern, multipliziert jede neue Integration die Komplexität. Halte eine interne Repräsentation und schreibe pro Portal einen Adapter, der in beide Richtungen mappt.

Mach den Synchronisationsstatus explizit. Ein Inserat ist nicht als Boolean "auf ImmobilienScout24", es hat einen Sync-Status pro Portal: pending, published, rejected mit Begründung, delisted. Makler werden jeden einzelnen Tag fragen "Warum erscheint mein Inserat nicht auf dem Portal?", und die Supportkosten explodieren, wenn das System diese Frage nicht beantworten kann. Speichere das zuletzt gesendete Payload, die erhaltene Antwort und Zeitstempel pro Portal.

Geh davon aus, dass Feeds feindselig sind. Eingehende Daten kommen mit Encoding-Problemen, fehlenden Pflichtfeldern und Duplikaten an. Jeder Import läuft durch Validierung und landet in einer Staging-Struktur, bevor er Produktionstabellen berührt, mit Fehlerberichten pro Datensatz, auf die ein Operator reagieren kann. Das ist normale Custom-Software-Development-Disziplin, aber Immobilien-Feeds testen sie härter als die meisten Domänen.

Das Rollenmodell entscheidet deine Multi-Tenancy-Architektur

Immobilien-SaaS hat eine ungewöhnlich verflochtene Besetzung: Maklerbüros mit Filialen und Maklern, private Vermieter, Hausverwaltungen, die für mehrere Eigentümer handeln, Mieter und Käufer. Der Fehler ist, diese als globale Nutzertypen zu modellieren. In der Praxis sind es Rollen innerhalb eines Kontexts: Dieselbe Person kann in einem Gebäude Vermieter und in einem anderen Mieter sein, und ein Makler kann für zwei Büros arbeiten.

Das hat eine direkte architektonische Konsequenz: Deine Tenant-Grenze ist die Organisation (das Maklerbüro oder die Hausverwaltung), und Personen verbinden sich mit Organisationen über Rollenzuweisungen, die auf ein Portfolio, ein Gebäude oder eine Einheit gescoped sind. Ob du das früh richtig machst, entscheidet, ob Enterprise-Features wie Berechtigungen auf Filialebene, Eigentümer-Reporting-Portale und Makler-Übergaben Wochen oder Monate Arbeit sind. Es entscheidet auch, ob Tenant-Isolation auf Zeilenebene überhaupt möglich ist, denn mandantenübergreifende Akteure (ein Mieter, der auf deiner Plattform von zwei verschiedenen Vermietern mietet) sprengen naive Tenant-ID-auf-jeder-Zeile-Schemata und müssen designt werden, nicht nachgepatcht.

DSGVO ist in der Immobilienbranche ein Datenmodell-Problem

Proptech berührt mehr sensible personenbezogene Daten, als Gründer erwarten. Besichtigungsanfragen verraten, wo eine Person wohnen möchte. Mieterbewerbungen enthalten Einkommensnachweise, Arbeitgeberdaten und Ausweisdokumente. Mietakten sammeln jahrelange Korrespondenz. Unter der DSGVO hat das konkrete Engineering-Konsequenzen.

Aufbewahrung muss pro Datenkategorie durchsetzbar sein. Abgelehnte Bewerberdossiers dürfen nicht ewig in deiner Datenbank liegen, während Mietverträge gesetzlichen Aufbewahrungspflichten unterliegen, die ihre Aufbewahrung verlangen. Das heißt, dein Schema muss diese Kategorien sauber genug unterscheiden, dass automatisierte Löschung auf die eine wirken kann, ohne die andere zu berühren.

Löschanfragen müssen ausführbar sein. Wenn ein Bewerber sein Recht auf Löschung geltend macht, musst du seine Daten über Bewerbungsdatensätze, Nachrichtenverläufe, hochgeladene Dokumente und Backups hinweg finden und entfernen, ohne die legitimen Unterlagen des Vermieters zu zerstören. Wenn personenbezogene Daten über Freitextfelder und unstrukturierte Dokumentenhalden verstreut sind, wird das zu einer manuellen forensischen Übung. Designe die Grenzen zuerst: Wer ist die betroffene Person jeder Tabelle, und was ist die Rechtsgrundlage für die Aufbewahrung jeder Kategorie?

Zugriffskontrolle ist zugleich Compliance. Ein Mieter darf auf seine eigenen Mietdokumente zugreifen, der Vermieter dieser Einheit auch, ein unbeteiligter Makler im selben Büro nicht. Das rollen-gescopte Modell aus dem vorherigen Abschnitt ist das, was diese Garantien in einem Audit beweisbar macht.

Dokumente und Signaturen: Die Workflow-Schicht, die Enterprise-Deals gewinnt

Mietverträge, Übergabeprotokolle, Eigentümerberichte: Die Immobilienbranche läuft auf Dokumenten, und die Produkte, die Makler- und Hausverwaltungs-Deals gewinnen, behandeln Dokumenten-Workflows als Kernarchitektur. Das bedeutet versionierte Dokumente mit einem Audit-Trail, wer was geändert und eingesehen hat, Template-basierte Generierung, sodass ein Mietvertrag aus strukturierten Daten erzeugt statt von Hand editiert wird, und E-Signatur-Integration mit Unterstützung qualifizierter elektronischer Signaturen, wo nationales Recht sie verlangt. Baue die Signaturschicht hinter deiner eigenen Abstraktion: Anbieter unterscheiden sich pro Land, und Enterprise-Kunden nennen ihren bevorzugten im Einkauf.

Ein pragmatischer europäischer Proptech-Stack

Der Stack, den wir für europäisches Immobilien-SaaS empfehlen, ist bewusst langweilig: PostgreSQL mit PostGIS und JSONB für das Domänenmodell und die Geo-Suche, ein Symfony- oder vergleichbares Backend für die Integrations- und Workflow-Schicht, wo langlaufende Prozesse, Queues und strikte Validierung leben, Next.js für das suchlastige, SEO-relevante Frontend, Objektspeicher plus CDN für Medien und Hosting in einer EU-Region, das deutsche und französische Enterprise-Käufer im Einkauf zunehmend verlangen. Nichts Exotisches, denn die Schwierigkeit in Proptech ist die Domänenmodellierung, nicht technologische Neuheit.

Wo du anfängst

Wenn du ein Proptech-Produkt scopest, stresste zuerst das Listing-Modell, das Rollenmodell und das Portal-Sync-Design, denn diese drei sind die teuren, wenn du sie später ändern musst. Wenn du bereits ein laufendes Produkt hast und sich einer der Abschnitte oben unangenehm vertraut angefühlt hat, ist ein fokussiertes Architektur- und Code-Review der günstigste Weg herauszufinden, wie tief das Problem geht, bevor der nächste Enterprise-Deal davon abhängt.

Wir bauen und auditieren Immobilien-SaaS für europäische Gründer und Maklerbüros bei Wolf-Tech. Wenn du ein zweites Paar Augen auf deine Architektur oder einen Partner für den Build willst, schreib an hello@wolf-tech.io oder besuche wolf-tech.io.