HomeHunter

Eine Desktop-Anwendung für die Wohnungssuche in Berlin.

A desktop application for finding a flat in Berlin.

Das Produkt

HomeHunter sammelt Mietangebote aus neunzehn öffentlich abrufbaren Quellen und führt dieselbe Wohnung, die auf mehreren Portalen steht, zu einer Karte zusammen. Jedes Angebot wird gegen die schriftlich festgelegten Kriterien des Nutzers geprüft — von einem festen Regelwerk, das zu jedem Ergebnis die Gründe nennt. Passt eine Wohnung, entwirft ein Klick das Anschreiben und führt den Nutzer auf das Original beim Anbieter; dort liest er weiter und bewirbt sich selbst. Die Anwendung ist in Entwicklung; eine öffentliche Version gibt es noch nicht. Geplant sind Ausgaben für macOS, Windows, Linux, iOS und Android.

Für Datenpartner

Was wir mit Ihren Daten tun

Wir zeigen Ihre Angebote in der Anwendung des Nutzers an. Jede Karte nennt die Quelle, aus der sie stammt. Ein Klick öffnet Ihr Exposé im Browser des Nutzers — gelesen, beworben und abgeschlossen wird auf Ihrer eigenen Seite. HomeHunter ist die Stelle, an der der Nutzer entscheidet, welches Angebot er ansieht; Ihre Seite bleibt die Stelle, an der er handelt.

Was wir nicht tun

  • Wir veröffentlichen Ihre Daten nicht und geben sie nicht weiter.
  • Wir bauen keine eigene öffentliche Ergebnisliste.
  • Wir legen keine wiederverwendbare Datenbank Ihres Bestands an.
  • Wir umgehen keine Schutzmechanismen.
  • Wir füllen und versenden keine fremden Formulare.
  • Wir nehmen nicht selbsttätig Kontakt zu Vermietern auf.

Was Sie davon haben

Der Nutzer erreicht Ihr Angebot vorgefiltert: Stadt, Miete, Zimmerzahl, Fläche und die übrigen Bedingungen sind bereits abgeglichen, und er weiß, warum dieses Angebot zu ihm passt. Statt vieler Anfragen auf gut Glück erhalten Sie wenige, die zum Objekt passen. Wir stehen vor Ihrem Angebot, nicht an seiner Stelle.

Integrationsbereitschaft

Die Anwendung ist auf einer Abstraktion namens ListingSource gebaut (src/homehunter/sources/base.py). Der Grundsatz ist in ADR-007 festgehalten: der übrige Teil des Systems erfährt nie, auf welchem Weg ein Angebot beschafft wurde — nur, dass es dem kanonischen Modell Listing entspricht.

Unter dieser Abstraktion arbeiten heute neunzehn Adapter und zwei verschiedene Beschaffungswege:

  • HTTP und HTML;
  • JSON-Schnittstelle — ApiRecordListingSource, über den Vonovia, STADT UND LAND und Covivio gelesen werden.

Der Anschluss einer offiziellen Schnittstelle ist deshalb ein weiterer Adapter gegen eine bereits bestehende Schnittstelle und kein Umbau des Systems. Zu erwarten sind Tage, nicht Monate.

Stand bei ImmoScout24, ohne Beschönigung: reserviert ist der Platz, geschrieben ist der Code nicht. Die Kennung ListingSourceId.IMMOSCOUT24 und der Katalogeintrag in src/homehunter/sources/catalog.py bestehen — mit den Domänen immobilienscout24.de und immoscout24.de und dem Status ACCESS_RESTRICTED. Die Registrierung in src/homehunter/discovery/registry.py gibt diesen Status offen zurück, statt Ergebnisse vorzutäuschen. Abruf und Abbildung der Antwort werden geschrieben, sobald Spezifikation und Zugang vorliegen. Für die übrigen auf dieser Seite genannten Häuser besteht bisher kein Schnittstellen-Adapter.

Aus der Anwendung

Die Angebotsliste: Karten mit Urteil, Quelle und den Kriterien, an denen das Angebot hängt.
Die Liste. Alle gefundenen Wohnungen, Treffer zuerst. Jede Karte nennt die Quelle, das Urteil und die Kriterien dahinter. „2 Quellen“ heißt: dieselbe Wohnung stand auf zwei Portalen und ist zu einer Karte zusammengeführt. „Bewerben“ legt ein Anschreiben für dieses eine Angebot in die Zwischenablage und öffnet das Original beim Anbieter; abgeschickt wird es dort vom Nutzer. „Als gesendet“ ist ein Vermerk, den er für sich selbst setzt.
Das Urteil zu einer abgelehnten Wohnung: die verletzte Bedingung in Rot, darunter die erfüllten und die vom Inserat nicht beantworteten.
Das Urteil mit seinen Gründen. Hier eine Wohnung, die ausscheidet: die Miete liegt über der Grenze. Jede geprüfte Bedingung steht einzeln da — verletzt, erfüllt oder vom Inserat nicht beantwortet.
Der Abschnitt Quellen auf einem Objekt: der Name der Quelle, die Adresse des ursprünglichen Exposés und eine Schaltfläche zum Öffnen.
Herkunft. Auf jedem Objekt steht die Quelle, aus der es stammt, mit der Adresse des ursprünglichen Exposés. Ein Klick öffnet es im Browser des Nutzers.
Die Liste der Quellen mit Erreichbarkeit, Prüfintervall und Ausbeute je Quelle.
Die Quellen und ihr Zustand. Jede Quelle mit Erreichbarkeit, Prüfintervall und Ausbeute. Was nicht gelesen werden kann, steht mit dem Grund dabei, statt einfach zu fehlen.
Die Seite mit den Suchkriterien: Stadt, Budgetgrenzen, Zimmerzahl, Wohnfläche und WBS-Regel.
Die Suchkriterien. Die Regeln, gegen die geprüft wird — harte Grenzen und bloße Präferenzen getrennt. Andere gibt es nicht: was hier nicht steht, beeinflusst kein Urteil.

Wie es arbeitet

  1. LINKDie Suche holt bei jeder registrierten Quelle die Links der neuesten Angebote.
  2. OPENJeder Link wird einmal geöffnet — über HTTP oder über die JSON-Schnittstelle der Quelle.
  3. READMiete, Zimmer, Fläche, Adresse und Bedingungen werden gelesen und in ein einheitliches Modell überführt.
  4. DEDUPEDieselbe Wohnung auf mehreren Portalen wird zu einer Karte zusammengeführt; jeder Link bleibt erhalten.
  5. PRÜFENEin Regelwerk vergleicht das Angebot mit den Kriterien des Nutzers. Ergebnis: passt, muss angesehen werden, oder scheidet aus — jeweils mit den Gründen.
  6. NUTZERHier endet die Anwendung. Sie entwirft das Anschreiben, legt es in die Zwischenablage und öffnet das Original beim Anbieter. Gelesen, geändert und abgeschickt wird die Bewerbung dort vom Nutzer — das Programm tut das nie für ihn.

Selbst ausprobieren

Sechs Beispielangebote, geprüft gegen die Kriterien unten. Entscheiden Sie zuerst selbst — ziehen Sie die Karte nach rechts, wenn Sie sich bewerben würden, nach links, wenn nicht. Danach zeigt die Karte, wie das Regelwerk entscheidet und aus welchen Gründen.

Kriterien
  • Berlin
  • 1–3 Zimmer
  • 30–90 m²
  • max. 950 € kalt
  • max. 1.250 € warm
  • kein WBS vorhanden

Ziehen, Pfeiltasten ← → oder die Schaltflächen.

Beispieldaten, keine echten Anzeigen. Die Art der Quelle steht auf jeder Karte, damit erkennbar bleibt, aus welcher Ecke des Marktes ein Angebot kommt. Das Urteil rechnet Ihr Browser aus, nach denselben Regeln, die die Anwendung anwendet — es wird nichts übertragen und nichts gespeichert.

Quellen

Die gelesenen Quellen
QuelleArtWegTreffer je Durchlauf
GewobagstädtischHTTP/HTML~42
degewostädtischHTTP/HTML~10
HOWOGEstädtischHTTP/HTML~28
GESOBAUstädtischHTTP/HTML~6
WBMstädtischHTTP/HTML~8
BerlinovostädtischHTTP/HTML~30
STADT UND LANDstädtischJSON-Schnittstelle~15
VonoviaprivatJSON-Schnittstelle~15 von 72 Datensätzen
CovivioprivatJSON-Schnittstellenicht einzeln erfasst
Ohne-MaklerprivatHTTP/HTML~24
DPF eGGenossenschaftHTTP/HTML0–3
ImmoweltPortalHTTP/HTML, Trefferkarten~23–25
WG-GesuchtPortalHTTP/HTML~79
immobilien.dePortalHTTP/HTML20
Immobilie1PortalHTTP/HTML~15
markt.deKleinanzeigenHTTP/HTML~13
WunderflatsmöbliertHTTP/HTML~59
HousingAnywheremöbliertHTTP/HTML~46
SpotahomemöbliertHTTP/HTML~96

Neunzehn Quellen, live geprüft am 24. und 28. August 2026. „Treffer je Durchlauf“ ist der Umfang eines begrenzten Durchlaufs, nicht der Bestand der Quelle.

Was ein offizieller Zugang verbessern würde

QuelleHeutiger StandWas ein offizieller Zugang bewirkt
ImmoScout24 Wird nicht gelesen. Die Suche antwortet ohne Partner-Schnittstelle mit HTTP 401, und die Nutzungsbedingungen untersagen automatische Abfragen. Die größte Einzelquelle des Berliner Marktes, die derzeit vollständig fehlt.
meinestadt.de Registriert, aber nicht lesbar: Suche, Sitemap und robots.txt antworten gleichermaßen mit HTTP 403. Aus einer toten Zeile im Quellenverzeichnis wird eine lebende Quelle.
Immowelt (AVIV Group) Lesbar sind allein die Trefferkarten der Suche; die Exposé-Seiten stehen hinter DataDome. Immonet leitet in denselben Bestand. Vollständige Exposés statt verkürzter Karten — und Immonet über denselben Zugang. Der größte Zugewinn an Datenqualität je Zugang.
WG-Gesucht Funktioniert, doch je Durchlauf werden nur drei Seiten über einfaches HTTP gelesen, und der Veröffentlichungszeitpunkt eines Inserats ist nicht zugänglich. Höhere Abrufgrenzen und der Veröffentlichungszeitpunkt, also eine messbare Reaktionsgeschwindigkeit.
Wunderflats, HousingAnywhere, Spotahome Funktionieren über das Auswerten von HTML, das bei jeder Umgestaltung der Seite bricht. Verlässlichkeit und ein stabiler Vertrag anstelle einer Auswertung fremder Seitenstruktur.

Grenzen

Kein Umgehen von Schutzmechanismen

Quellen mit Bot-Schutz oder rein clientseitiger Darstellung werden als nicht verfügbar geführt und nicht umgangen. Der Fehlertyp ComplianceBlockedError ist im Quelltext ein regulärer Ausgang und kein Sonderfall; in sources/base.py ist festgehalten, dass eine Quelle niemals stillschweigend auf das Auswerten fremder Seiten ausweicht, wenn kein zulässiger Weg besteht. Die Entscheidung zu ImmoScout24 ist in pocs/a_immoscout/RESULT.md dokumentiert.

Keine fremden Formulare

HomeHunter füllt kein Formular auf Ihrer Seite aus und versendet nichts. Die Anwendung entwirft ein Anschreiben aus den Angaben, die der Nutzer selbst hinterlegt hat, und legt es in die Zwischenablage; gelesen, geändert und abgeschickt wird es vom Nutzer, bei Ihnen, auf Ihrem Weg. Auch der Entwurf folgt festen Regeln: geschrieben wird allein, was im Profil tatsächlich steht — kein Platzhalter, keine plausible Erfindung, und wo offenbleibt, wie die Miete getragen wird, sagt die Anwendung es dem Nutzer, statt zu raten. Was umkehrbar ist, ist automatisiert. Was nicht umkehrbar ist, bleibt beim Menschen.

Deterministisch

Das Urteil fällt ein Regelwerk, das jeden geprüften Punkt einzeln benennt. Neuronale Netze kommen in der Anwendung nicht vor.

Datenschutz

Die Daten des Nutzers bleiben auf seinem Gerät: eine lokale SQLite-Datenbank im Datenverzeichnis des Betriebssystems. Einen Server von HomeHunter, auf dem Angebots- oder Nutzerdaten zusammenliefen, gibt es nicht. Die Verarbeitung findet in der EU statt und richtet sich nach der DSGVO.

Technik

Python 3.13, PySide6 mit QML, SQLite, Playwright, Alembic; Version 1.0.0. Der Bestand umfasst 1120 Tests, dazu durchgängige Typprüfung mit mypy und Stilprüfung mit ruff.

Status und Kontakt

HomeHunter ist in Entwicklung. Eine öffentliche Fassung gibt es noch nicht, der Quelltext ist nicht offen. Hinter dem Projekt steht kein Unternehmen, sondern eine Person.

Anfragen zu Daten- oder Schnittstellenzugang gern unmittelbar an:
Damian Lapiha · demilapkill@gmail.com

The product

HomeHunter collects rental adverts from nineteen publicly reachable sources and merges the same flat, listed on several portals, into a single card. Every advert is checked against the criteria the user has written down — by a fixed set of rules that names the reason for each outcome. Where a flat fits, one click drafts the letter and takes the user to the original on the provider's own site, where they read on and apply themselves. The application is under development; there is no public release yet. Builds for macOS, Windows, Linux, iOS and Android are planned.

For data partners

What we do with your data

We display your adverts inside the user's application. Every card names the source it came from. One click opens your own exposé in the user's browser — reading, applying and closing all happen on your site. HomeHunter is where the user decides which advert to look at; your site remains where they act.

What we do not do

  • We do not publish your data and do not pass it on.
  • We do not build a public result list of our own.
  • We do not create a reusable database of your inventory.
  • We do not circumvent protection mechanisms.
  • We do not fill in or submit anyone else's forms.
  • We do not contact landlords automatically.

What you get from it

The user reaches your advert pre-filtered: city, rent, rooms, area and the rest of the conditions are already checked, and they know why this advert fits them. Instead of many enquiries sent on the off-chance you receive a few that match the object. We stand in front of your offer, not in place of it.

Integration readiness

The application is built on an abstraction called ListingSource (src/homehunter/sources/base.py). The principle is recorded in ADR-007: the rest of the system never learns by which route an advert was obtained — only that it conforms to the canonical Listing model.

Nineteen adapters and two different acquisition routes already work beneath that abstraction:

  • HTTP and HTML;
  • a JSON interface — ApiRecordListingSource, through which Vonovia, STADT UND LAND and Covivio are read.

Connecting an official interface is therefore one more adapter against an interface that already exists, not a rebuild of the system. Expect days, not months.

The state of ImmoScout24, without embellishment: the slot is reserved, the code is not written. The identifier ListingSourceId.IMMOSCOUT24 and the catalogue entry in src/homehunter/sources/catalog.py exist — with the domains immobilienscout24.de and immoscout24.de and the status ACCESS_RESTRICTED. The registration in src/homehunter/discovery/registry.py returns that status openly instead of feigning results. The request and the mapping of the response will be written once a specification and access are available. For the other companies named on this page no interface adapter exists yet.

From the application

The listing feed: cards with verdict, source and the criteria the advert turns on.
The list. Every flat found, matches first. Each card names the source, the verdict and the criteria behind it. "2 Quellen" means the same flat appeared on two portals and has been merged into one card. "Bewerben" puts a draft letter for this one advert on the clipboard and opens the original at the provider; the user sends it there themselves. "Als gesendet" is a note they make for their own record.
The verdict on a rejected flat: the broken condition in red, below it the ones met and the ones the advert left unanswered.
The verdict and its reasons. A flat that is ruled out: the rent is over the limit. Every checked condition stands on its own — broken, met, or left unanswered by the advert.
The sources section on one object: the name of the source, the address of the original exposé and a button to open it.
Provenance. Every object carries the source it came from and the address of the original exposé. One click opens it in the user's browser.
The list of sources with reachability, check interval and yield per source.
The sources and their state. Each source with its reachability, check interval and yield. What cannot be read is listed with the reason rather than simply missing.
The search criteria page: city, budget limits, number of rooms, floor area and the WBS rule.
The search criteria. The rules everything is checked against — hard limits kept apart from mere preferences. There are no others: what is not here influences no verdict.

How it works

  1. LINKThe search collects links to the newest adverts from every registered source.
  2. OPENEach link is opened once — over HTTP or through the source's JSON interface.
  3. READRent, rooms, area, address and conditions are read and converted into one common model.
  4. DEDUPEThe same flat on several portals is merged into one card; every link is kept.
  5. PRÜFENA set of rules compares the advert with the user's criteria. The outcome: it fits, it needs a look, or it is out — with the reasons in each case.
  6. NUTZERThis is where the application stops. It drafts the letter, puts it on the clipboard and opens the original on the provider's own site. Reading, editing and sending happen there and are done by the user — the program never does it for them.

Try it yourself

Six sample adverts, checked against the criteria below. Decide for yourself first — drag the card to the right if you would apply, to the left if you would not. The card then shows how the rules decide, and on what grounds.

Criteria
  • Berlin
  • 1–3 rooms
  • 30–90 m²
  • max. €950 base rent
  • max. €1,250 total
  • no WBS held

Drag, arrow keys ← →, or the buttons.

Sample data, not real adverts. The kind of source is named on each card so it stays clear which corner of the market an advert comes from. The verdict is computed by your browser, by the same rules the application applies — nothing is transmitted and nothing is stored.

Sources

The sources that are read
SourceTypeRouteHits per run
GewobagmunicipalHTTP/HTML~42
degewomunicipalHTTP/HTML~10
HOWOGEmunicipalHTTP/HTML~28
GESOBAUmunicipalHTTP/HTML~6
WBMmunicipalHTTP/HTML~8
BerlinovomunicipalHTTP/HTML~30
STADT UND LANDmunicipalJSON interface~15
VonoviaprivateJSON interface~15 of 72 records
CovivioprivateJSON interfacenot recorded separately
Ohne-MaklerprivateHTTP/HTML~24
DPF eGcooperativeHTTP/HTML0–3
ImmoweltportalHTTP/HTML, result cards~23–25
WG-GesuchtportalHTTP/HTML~79
immobilien.deportalHTTP/HTML20
Immobilie1portalHTTP/HTML~15
markt.declassifiedsHTTP/HTML~13
WunderflatsfurnishedHTTP/HTML~59
HousingAnywherefurnishedHTTP/HTML~46
SpotahomefurnishedHTTP/HTML~96

Nineteen sources, verified live on 24 and 28 August 2026. "Hits per run" is the size of one bounded run, not the size of the source's inventory.

What official access would improve

SourceState todayWhat official access achieves
ImmoScout24 Not read at all. Without a partner interface the search answers HTTP 401, and the terms of use prohibit automated queries. The single largest source on the Berlin market, currently missing entirely.
meinestadt.de Registered but not readable: search, sitemap and robots.txt all answer HTTP 403. A dead row in the source list becomes a living source.
Immowelt (AVIV Group) Only the search result cards can be read; the exposé pages sit behind DataDome. Immonet redirects into the same inventory. Full exposés instead of truncated cards — and Immonet through the same access. The largest gain in data quality per single key.
WG-Gesucht Works, but only three pages per run are read over plain HTTP, and an advert's publication time is not available. Higher limits and the publication time, meaning a measurable speed of response.
Wunderflats, HousingAnywhere, Spotahome Work by parsing HTML, which breaks with every redesign of the page. Reliability and a stable contract instead of parsing someone else's page structure.

Limits

No circumvention of protection mechanisms

Sources with bot protection or purely client-side rendering are recorded as unavailable and are not worked around. The error type ComplianceBlockedError is a regular outcome in the source code and not an exceptional case; sources/base.py records that a source never silently falls back to scraping when no permitted route exists. The decision on ImmoScout24 is documented in pocs/a_immoscout/RESULT.md.

No third-party forms

HomeHunter fills in no form on your site and submits nothing. The application drafts a letter from what the user has entered about themselves and puts it on the clipboard; reading, editing and sending are done by the user, with you, by your own route. The draft follows fixed rules too: only what the profile actually states gets written — no placeholder, no plausible invention, and where it remains open how the rent will be covered the application says so to the user rather than guessing. What is reversible is automated. What is not reversible stays with the person.

Deterministic

The verdict comes from a set of rules that names every point it checked. There are no neural networks in the application.

Data protection

The user's data stays on their device: a local SQLite database in the operating system's data directory. There is no HomeHunter server on which advert or user data would be collected. Processing takes place in the EU and follows the GDPR.

Technology

Python 3.13, PySide6 with QML, SQLite, Playwright, Alembic; version 1.0.0. The suite holds 1120 tests, alongside type checking with mypy and linting with ruff.

Status and contact

HomeHunter is under development. There is no public release yet and the source code is not open. There is no company behind the project — one person.

Enquiries about data or interface access are welcome directly:
Damian Lapiha · demilapkill@gmail.com