FEWO Search
Full-Stack · Buchungsplattform
Express
SQLite
SQL
SSE
Rolle
Design, Front-End & Backend
Jahr
2026
Ein Ferienwohnungsportal auf Basis eines rohen Airbnb-Exports: 1.476 Unterkünfte, 504.795 Kalendernächte und 103.295 Bewertungen, hinter einer Suche, einem Buchungsablauf und einem Live-Verfügbarkeitsfeed. Express und SQLite auf dem Server, handgeschriebenes JS im Browser. Kein Front-End-Framework, kein Build-Schritt.
1476
Unterkünfte
504k
Kalendernächte
23
API-Endpoints
0
Front-End-Frameworks
01 — Etwas finden
Erst suchen, dann Formular
Der Datensatz umfasst 1.476 Unterkünfte in einer Stadt. Klein genug zum Stöbern, groß genug, dass Stöbern nichts bringt. Also besteht die Startseite aus einer Suchleiste und einem Karussell, und alles, was die Auswahl eingrenzt, liegt ein Popover entfernt: sichtbar, wenn du es willst, und weg, wenn nicht.
Startseite
Filter
Alle Unterkünfte
02 — Buchen
Der Kalender ist das Produkt
Eine halbe Million Kalenderzeilen existieren, um eine Frage ehrlich zu beantworten: Kann ich diese Nächte haben, und was kosten sie? Jede Regel unten wird im Browser geprüft, damit die Antwort sofort kommt, und noch einmal auf dem Server, damit sie stimmt.
Verfügbarkeit
Buchungsformular
Bestätigung
03 — Das Interface entscheiden
Was jeder Screen statt etwas anderem ist
Ein Buchungsinterface hat eine naheliegende Version, und der Datensatz hat sie immer wieder kaputtgemacht. Jede Entscheidung unten hat sich gegen eine konventionellere durchgesetzt, und die hat aus einem Grund verloren, der aus den Daten kam, nicht aus Geschmack. Sie stehen als Paare da, was es ist und statt was, denn eine Entscheidung ohne verworfene Alternative war nie wirklich eine.
04 — Darunter
Was der Server wirklich macht
Zehn Abhängigkeiten, acht Router, eine SQLite-Datei. Spannend war nie ein einzelner Endpoint. Spannend war zu entscheiden, welche Probleme eine Bibliothek verdienen und welche zwanzig Zeilen.
05 — Admin & Reste
Die schlichte Hälfte, und was noch nicht stimmt
Die Admin-Seite ist bewusst schlicht: ein Importformular, ein Dashboard, ein Dark-Mode-Schalter. Vier Dinge stimmen noch nicht, und ich schreibe sie lieber auf, als sie aus einem Screenshot herauszuschneiden. Das Login-Token liegt in localStorage, was CSP und Escaping weniger schlimm machen, aber nicht lösen. bookings.json wird nach jeder Änderung neu geschrieben und nie wieder gelesen, ist also ein Spiegel, der vorgibt, ein Speicher zu sein. Die 2-Minuten-Reservierungen liegen im Arbeitsspeicher und verschwinden beim Neustart. Und der Bezahlen-Button belastet niemanden.
Profil — Adminbereich
Jede Entscheidung dieses Projekts, aufgeschrieben, auch die, die sich als falsch herausgestellt haben. Zwanzig Seiten. Niemand muss sie lesen.