Referenzprojekt
bald-in.de – unsere eigene Plattform
bald-in.de ist unser eigenes Produkt: eine öffentliche Plattform für Läden, die demnächst in einer Stadt eröffnen. Unternehmerinnen und Unternehmer stellen ihr Geschäft schon vor dem ersten Öffnungstag vor, Besucher sehen, was in ihrer Nähe entsteht.
Wir führen das Projekt hier auf, weil es zeigt, was wir jenseits einer Website bauen: Nutzerkonten, eine Datenbank mit eingebauter Rechteprüfung, Karten, automatische E-Mails und aus derselben Grundlage erzeugte Apps für iOS und Android. Wer etwas Ähnliches plant, sieht hier den tatsächlichen Umfang statt einer Aufzählung von Schlagworten.
- Kunde
- bald-in.de
- Branche
- Eigene Plattform
- Umfang
- Plattform mit Nutzerkonten, Karte und mobilen Apps
- Zeitraum
- 2025–2026
Eingesetzte Technik
- Next.js 16 (App Router)
- React 19
- Supabase / PostgreSQL
- Row-Level-Security
- Leaflet & OpenStreetMap
- Resend
- Capacitor (iOS & Android)
- Vercel
Ausgangslage
Ein neuer Laden ist online praktisch unsichtbar, solange er noch nicht geöffnet hat. In Kartendiensten taucht er meist erst auf, wenn die Tür bereits offen steht. Soziale Netzwerke erreichen die Menschen, die dem Geschäft schon folgen – also fast niemanden, wenn es das Geschäft noch gar nicht gibt. Genau in den Wochen, in denen ein Inhaber Aufmerksamkeit am dringendsten braucht, fehlt ihm der Ort dafür.
Auf der anderen Seite steht die Nachbarschaft: Wer wissen will, was in der eigenen Stadt gerade entsteht, findet dazu keine zusammenhängende Quelle. Die Information verteilt sich auf Lokalzeitungen, Bauzäune und Zufall.
Für uns kam ein zweiter Grund dazu. Wir wollten ein eigenes Produkt betreiben, nicht nur im Kundenauftrag entwickeln. Eine Plattform, in der fremde Menschen Konten anlegen und eigene Inhalte einstellen, stellt andere Fragen als eine Firmenwebsite: Wer darf welche Zeile in der Datenbank lesen, wer darf sie ändern, und was passiert, wenn jemand die Oberfläche umgeht und direkt mit der Datenbank spricht? Diese Fragen mussten vor der ersten gestalteten Seite beantwortet sein.
Unsere Lösung
Die Grundlage ist Next.js 16 im App Router zusammen mit React 19. Next.js ist ein Rahmenwerk, das Seiten bereits auf dem Server fertig zusammenbaut und ausliefert. Das hat zwei praktische Folgen: Die Seite ist sichtbar, bevor der Browser irgendein Programm ausgeführt hat, und Suchmaschinen lesen fertigen Text statt eines leeren Gerüsts. Für ein Verzeichnis, das gefunden werden soll, ist das kein Detail, sondern die Voraussetzung.
Die Daten liegen in Supabase – einer verwalteten PostgreSQL-Datenbank in der Region Frankfurt, also innerhalb der EU. Supabase bringt die Anmeldung gleich mit: E-Mail und Passwort, Sitzungen über Cookies statt über im Browser gespeicherte Schlüssel, dazu eine Sperre gegen das automatisierte Durchprobieren von Passwörtern. Wer zu oft falsch anmeldet, wird ausgebremst.
Die Karten zeichnet Leaflet mit Kartenmaterial von OpenStreetMap. Das ist eine bewusste Entscheidung gegen Google Maps: Eine eingebettete Google-Karte lädt Daten der Besucher zu einem Dritten, noch bevor jemand zugestimmt hat. E-Mails – Bestätigungen, Benachrichtigungen – verschickt Resend, das Hosting läuft bei Vercel, die Gestaltung über Tailwind v4.
Aus derselben Grundlage entstehen mit Capacitor die Apps für iOS und Android. Capacitor verpackt die vorhandene Web-Anwendung in eine echte App, die aus den Stores installiert wird. Statt drei getrennter Entwicklungen gibt es eine Codebasis. Jede Änderung an der Datenbankstruktur wird als nummerierte SQL-Datei abgelegt – so lässt sich jeder Schritt nachvollziehen und auf einer zweiten Umgebung exakt wiederholen.
Das Ergebnis
- Eine gemeinsame Codebasis für Web, iOS und Android statt drei getrennter Entwicklungen
- Die Rechteprüfung sitzt in der Datenbank selbst, nicht nur im Programmcode
- Kein Schlüssel mit Vollzugriff im ausgelieferten Code – alle Zugriffe laufen über den öffentlichen Schlüssel plus Regelwerk
- Karten ohne Datenweitergabe an Google, Kartendaten von OpenStreetMap
- Datenhaltung in der EU: Supabase-Region Frankfurt
- Jede Änderung am Datenmodell als nummerierte SQL-Datei nachvollziehbar
Woraus die Plattform besteht
Sechs Bausteine, die zusammen mehr ergeben als eine Website mit Kontaktformular:
Öffentliches Verzeichnis
Jeder Laden bekommt eine eigene Seite mit Adresse, Kategorie und geplantem Eröffnungstermin – auffindbar über Stadt und Umkreis.
Nutzerkonten
Inhaber melden sich mit E-Mail und Passwort an und pflegen ihren Eintrag selbst. Ohne Anmeldung ist alles nur lesbar.
Karte
Leaflet mit OpenStreetMap zeigt, was in der Umgebung entsteht. Keine eingebettete Fremdkarte, die im Hintergrund Daten sammelt.
Automatische E-Mails
Bestätigungen und Erinnerungen laufen über Resend – von der Anwendung ausgelöst, nicht von Hand verschickt.
Apps für iOS und Android
Capacitor verpackt dieselbe Anwendung als installierbare App. Eine Pflegestelle statt drei.
Redaktionelle Freigabe
Neue Einträge gehen nicht ungeprüft live. Eine Verwaltungsebene entscheidet, was öffentlich sichtbar wird.
Die eingesetzte Technik, in einem Satz erklärt
Jeder Baustein hat einen Grund. Was er tut, steht daneben – ohne Fachjargon:
- Next.js 16Rahmenwerk
- Baut die Seiten auf dem Server fertig zusammen. Dadurch sind Inhalte sofort sichtbar und für Suchmaschinen lesbar.
- React 19Oberfläche
- Setzt die Bedienelemente zusammen: Formulare, Filter, Kartenansicht. Der Teil, mit dem Besucher tatsächlich umgehen.
- Supabase / PostgreSQLDatenbank & Anmeldung
- Speichert Läden, Konten und Sitzungen. PostgreSQL ist eine seit Jahrzehnten erprobte Datenbank, Supabase liefert Betrieb und Anmeldung dazu.
- Row-Level-SecurityRechteprüfung
- Regeln in der Datenbank legen zeilenweise fest, wer was sehen und ändern darf. Dazu unten mehr.
- Leaflet & OpenStreetMapKarten
- Karten aus offenen Daten, eingebunden ohne Umweg über einen Werbekonzern.
- ResendE-Mail-Versand
- Verschickt Bestätigungen und Hinweise so, dass sie zugestellt werden und nicht im Spam-Ordner landen.
- CapacitorApp-Hülle
- Macht aus der Web-Anwendung eine App für iOS und Android, ohne dass beides getrennt entwickelt werden muss.
- VercelHosting
- Betreibt die Anwendung und verteilt sie über ein weltweites Netz aus Auslieferungspunkten.
Row-Level-Security: Sicherheit dort, wo die Daten liegen
Die übliche Bauweise prüft Berechtigungen im Programmcode: Bevor die Anwendung einen Datensatz ausliefert, fragt sie ab, ob der Anfragende ihn sehen darf. Das funktioniert – solange jede einzelne Stelle im Code daran denkt. Vergisst eine von hundert Abfragen die Prüfung, ist die Lücke da, und sie fällt niemandem auf, weil die Seite ja aussieht wie immer.
Row-Level-Security dreht das um. Die Regel steht nicht im Programm, sondern in der Datenbank – für jede Tabelle, zeilenweise. Sinngemäß: „Diesen Laden darf ändern, wem er gehört. Lesen darf ihn jeder, sobald er freigegeben ist.“ Die Datenbank liefert Zeilen, für die keine Regel greift, schlicht nicht aus. Selbst wenn jemand die Oberfläche umgeht und direkt mit der Datenbank spricht, bekommt er nichts, was ihm nicht zusteht. Die Prüfung lässt sich nicht mehr vergessen, weil sie nicht mehr im Code steht.
Daraus folgt die zweite Entscheidung: In der ausgelieferten Anwendung liegt kein Schlüssel mit Vollzugriff. Supabase kennt zwei Sorten – einen öffentlichen Schlüssel, der nur so weit kommt, wie die Regeln es erlauben, und einen Verwaltungsschlüssel, der jede Regel übergeht. Der zweite gehört niemals in etwas, das ein Browser oder eine App herunterlädt. Er wäre dort auslesbar, und wer ihn hat, hat die ganze Datenbank. Deshalb arbeitet die Plattform durchgehend mit dem öffentlichen Schlüssel plus Regelwerk. Wie wir das in Kundenprojekten handhaben, steht unter IT-Sicherheit und Datenbanken.
Wie das Projekt gelaufen ist
- 1
Datenmodell zuerst
Bevor eine Seite gestaltet wurde, stand die Frage, welche Tabellen es gibt und wer auf welche Zeile zugreifen darf. Diese Reihenfolge lässt sich später nur teuer korrigieren.
- 2
Konten und Regelwerk
Anmeldung, Sitzungen über Cookies, Schutz gegen automatisiertes Passwortraten – danach für jede Tabelle die Zugriffsregeln, jeweils gegen einen fremden Zugriff geprüft.
- 3
Oberfläche und Karte
Verzeichnis, Detailseiten, Suche nach Stadt und Umkreis, Karte mit Leaflet. Erst hier wurde aus der Datenstruktur eine benutzbare Anwendung.
- 4
E-Mails und Verwaltung
Automatische Benachrichtigungen über Resend, dazu die Freigabeansicht, mit der neue Einträge geprüft werden, bevor sie öffentlich sind.
- 5
Mobile Apps
Verpackung mit Capacitor, Anpassung an die Eigenheiten von iOS und Android, Vorbereitung der Store-Einreichung.
Website oder Plattform – wo verläuft die Grenze?
Die Frage kommt in fast jedem Erstgespräch. Der Unterschied liegt nicht in der Optik, sondern darin, ob fremde Menschen eigene Daten hinterlassen:
| Klassische Website | Plattform wie bald-in.de | |
|---|---|---|
| Inhalte | Kommen von Ihnen und Ihrem Team | Kommen zusätzlich von fremden Nutzern |
| Konten | Höchstens ein Redaktionszugang | Beliebig viele Konten mit unterschiedlichen Rechten |
| Datenbank | Oft gar keine oder eine sehr einfache | Eigenes Datenmodell mit zeilenweisen Zugriffsregeln |
| Datenschutz | Vor allem Formulare und Einwilligungen | Zusätzlich Auskunft, Löschung und Aufbewahrung fremder Daten |
| Aufwand | Planbar, überschaubarer Rahmen | Deutlich höher – in der Regel im vierstelligen Bereich aufwärts |
Was wir aus dem eigenen Produkt mitnehmen
Weil bald-in.de unser eigenes Projekt ist, gibt es hier kein Kundenzitat – wohl aber etwas, das ein Zitat nicht leisten kann: Wir betreiben die Technik selbst, mit allen Konsequenzen. Fehler fallen auf uns zurück, nicht auf einen Auftraggeber.
Die wichtigste Lehre daraus ist unspektakulär: Sicherheit gehört an den Anfang, nicht ans Ende. Ein Rechtekonzept nachträglich in eine gewachsene Anwendung einzuziehen, kostet ein Vielfaches davon, es vorher zu entwerfen. Dieselbe Reihenfolge halten wir in Kundenprojekten ein – nachzulesen unter Individualsoftware und in unserer Arbeitsweise.
Passend dazu
Bereit, Ihr Projekt umzusetzen?
Lassen Sie uns gemeinsam loslegen.
Wir freuen uns auf Ihr Vorhaben – ob Redesign, neue Website oder langfristige Betreuung.