Wie wir PARAT gebaut haben — Learnings & Fuckups
Ein ehrlicher Blick hinter die Kulissen: Architektur-Entscheidungen, Next.js Fallstricke und warum wir Supabase lieben gelernt haben.
Die Entwicklung eines eigenen SaaS-Produkts ist immer eine Achterbahnfahrt. PARAT.pro, unser Bewerbungstool für den Schweizer Markt, war da keine Ausnahme.
In diesem Artikel teile ich die wichtigsten technischen Learnings aus sechs Monaten intensiver Entwicklung. Was hat funktioniert? Wo sind wir hart auf die Nase gefallen? Und was würden wir heute anders machen?
Der Stack: Warum Next.js und Supabase?
Wir brauchten eine Architektur, die schnell iterierbar, sicher und skalierbar ist. Die Wahl fiel auf:
- Frontend & API: Next.js (App Router)
- Datenbank & Auth: Supabase (PostgreSQL)
- Styling: Vanilla CSS Modules (Ja, ganz bewusst ohne Tailwind!)
Diese Kombination hat sich als äusserst mächtig erwiesen, brachte aber auch einige Herausforderungen mit sich.
Learning 1: Next.js Server Components sind grossartig, aber...
Der Wechsel zum App Router von Next.js war ein Paradigmenwechsel. Die Möglichkeit, Daten direkt in der Komponente zu laden, reduziert den Boilerplate-Code enorm.
Der Haken: Das Caching. Next.js cacht standardmässig sehr aggressiv. Wir hatten oft Situationen, in denen Benutzer veraltete Daten sahen, weil wir revalidatePath vergessen oder an der falschen Stelle aufgerufen haben.
Die Lösung: Wir haben gelernt, das Caching sehr bewusst zu steuern und export const dynamic = 'force-dynamic' dort einzusetzen, wo absolute Aktualität zwingend ist (z.B. im Dashboard der Bewerber).
Learning 2: Supabase Row Level Security (RLS) ist ein Gamechanger
Bei einem Bewerbungstool ist Datensicherheit das oberste Gebot. Mit Supabase RLS konnten wir die Sicherheitslogik direkt in die Datenbank verlagern.
Anstatt in jeder API-Route zu prüfen, ob Benutzer X Zugriff auf Bewerbung Y hat, definieren wir eine Regel auf Tabellenebene: auth.uid() = user_id.
Der Fehler: Am Anfang haben wir RLS-Policies zu komplex gestaltet, was zu massiven Performance-Problemen bei komplexen Queries führte. Die Erkenntnis: Halte RLS-Policies so simpel wie möglich. Nutze Views für komplexe Datenabfragen und sichere diese separat ab.
Learning 3: Warum wir Tailwind verbannt haben
Das ist ein heisses Thema in der Entwickler-Community. Wir haben uns bei PARAT (wie auch bei unserer Agentur-Webseite) bewusst gegen Tailwind CSS und für CSS Modules entschieden.
Warum?
- Sauberes HTML: Keine kilometerlangen Klassen-Strings.
- Kapselung: CSS Modules verhindern ungewollte Nebenwirkungen.
- Langlebigkeit: Wir wollen uns nicht von einem Utility-Framework abhängig machen.
Der Aufwand am Anfang war höher (wir mussten eigene Design-Patterns definieren), aber die Wartbarkeit nach 6 Monaten ist unschlagbar.
Fazit: Weniger ist mehr
Das grösste Learning? Overengineering tötet Projekte. Wir haben oft Tage damit verbracht, "die perfekte Architektur" für ein Feature zu bauen, das die Nutzer am Ende kaum verwendet haben.
Heute bauen wir erst den "Happy Path", launchen schnell und optimieren dann basierend auf echtem Nutzerfeedback.
Suchen Sie einen Partner für Ihr nächstes Webprojekt? Lassen Sie uns reden – wir kennen die Fallstricke und wissen, wie man sie umgeht.
