Der Bauunternehmer hat den Überblick. Der Bauleiter verwaltet seine Baustellen. Der Bauherr sieht seine Villa. Der Architekt prüft ein Projekt. Jeder sieht genau das, was er sehen soll · nicht mehr, nicht weniger.
Wenn jeder alles sieht, sieht niemand etwas richtig. Der Bauherr liest interne Abstimmungen. Der Bauleiter sieht Margen. Der Architekt stolpert über Kundennamen. Rollen sind kein Admin-Thema · sie sind Kundenpflege.
BuildFlow kennt vier Rollen. Jede hat einen klar definierten Ausschnitt · technisch durchgesetzt, nicht nur visuell versteckt.
Der Bauunternehmer. Meist Geschäftsführer oder Projektleiter. Verwaltet das ganze Unternehmen.
Team vor Ort, Bauleitung, Projektassistenz. Arbeitet für das Bauunternehmen.
Der Kunde. Familie Weber aus Ettelbrück. Der Architekt einer Résidence in Esch.
Architekt, Bauingenieur, Subunternehmer. Externer Beobachter für ein einzelnes Projekt.
BuildFlow nutzt bewusst keinen Magic-Link. Jedes Team-Mitglied setzt ein echtes Passwort · weil das Konto wiederverwendet wird und Arbeitsgeräte geteilt werden.
Bauherren sind die Ausnahme: sie brauchen keinen Account. Sie öffnen einen Link und sehen sofort den Stand ihrer Villa.
E-Mail und Name eingeben. Für Team-Mitglieder: Projekte auswählen. Für Gäste: ein einzelnes Projekt auswählen. Die Einladung wird serverseitig erzeugt · nicht im Browser.
Ein signierter Link, gültig für sieben Tage. Der Link zeigt auf app.buildflow.lu/register mit vorausgefüllter E-Mail. Die eingeladene Person setzt ein Passwort und ist sofort einsatzbereit.
Eine Edge Function prüft den Token, verifiziert die E-Mail, aktiviert die Mitgliedschaft in genau den zugewiesenen Projekten. Kein clientseitiger Code kann diesen Schritt umgehen.
Jede Anfrage an die Datenbank prüft die Rolle und die Projekt-Zuordnung. Es gibt keinen „versteckten“ Modus, der Daten ausblendet · die Datenbank gibt einfach nichts anderes zurück.
Row-Level-Security auf Datenbankebene. Ein Admin von Bauunternehmen A kann technisch keine Projekte von Bauunternehmen B abfragen · selbst dann nicht, wenn er die interne Projekt-ID kennt.
Die Zuordnung wird über das Feld project_ids gesteuert. Eine nicht-zugewiesene Projekt-Zeile kommt in keiner Abfrage zurück · weder über die UI noch über die API.
Kalkulationen, interne Notizen, Abrechnungen sind in separaten Tabellen mit eigener RLS. Ein Client-Token kann diese Tabellen technisch nicht lesen, auch nicht über eine andere Route.
Wer wann wen eingeladen hat, wann die Einladung aktiviert wurde, wann sie zurückgezogen wurde · alles in einer separaten Audit-Tabelle. Für Sie wie für den Rechtsanwalt.
Richten Sie Ihr Team in zehn Minuten ein. Der erste Admin sind Sie. Den Rest laden Sie mit wenigen Klicks ein.
