Zum Inhalt springen

SaaS-Anwendungsentwicklung

Next.js-SaaS-Entwicklung

Mandantenfähige SaaS-Produkte auf dem App Router - Mandantentrennung und Autorisierung vor dem ersten Screen entschieden, prüfungsfestes Billing und ein Dashboard, das auf dem Server bleibt.

Ein SaaS-Produkt ist keine Website mit Login. Drei Entscheidungen der ersten zwei Wochen - wie Mandantentrennung funktioniert, wo Autorisierung lebt und wie der Billing-Zustand die Anwendung erreicht - bestimmen, was die nächsten zwei Jahre kosten, und alle drei sind teuer umzukehren, sobald es Produktionsdaten gibt.

Wir bauen solche Produkte, und wir beginnen bei diesen dreien.

Mandantentrennung, vor dem ersten Screen entschieden

Es gibt drei Modelle, und das richtige hängt von Ihren Kunden ab, nicht von der Mode.

ModellIsolationWann es richtig ist
Gemeinsame Tabellen, MandantenspalteIm Code durchgesetztDie meisten Produkte. Am günstigsten im Betrieb und in der Migration.
Schema pro MandantVon der Datenbank durchgesetztRegulierte Kunden, Export oder Restore pro Mandant.
Datenbank pro MandantVollständigWenige, große, vertraglich isolierte Kunden.

Das gemeinsame Modell ist meistens richtig, und sein einziges echtes Risiko ist eine Query, die den Mandantenfilter vergisst. Das ist kein Disziplinproblem für Code Reviews - es wird mit Row-Level Security in der Datenbank gelöst, sodass ein fehlender Filter nichts zurückgibt statt der Daten eines anderen.

Autorisierung an den Daten, nicht an der Route

Middleware, die entscheidet, wer eine Seite sehen darf, ist ein Tor, und Tore sind nützlich. Autorisierung sind sie nicht. Server Actions und Route Handler lassen sich direkt aufrufen - eine Prüfung, die nur in der Middleware lebt, ist eine Prüfung, die der Endpunkt nicht hat.

Jede Query trägt Mandant und Handelnden. Jede Mutation leitet die Berechtigung neu aus der Session ab, statt einem Argument zu trauen. Die Begründung steht in Server Actions und die drei üblichen Fehler, und in einem mandantenfähigen Produkt ist der Fehlerfall kein Bug, sondern ein Kunde, der die Daten eines anderen liest.

Billing, das eine Prüfung übersteht

Stripe ist der Standard, und die Integration ist nicht der schwere Teil. Schwer ist, dass Ihre Anwendung und Stripe dieselbe Tatsache halten - worauf dieser Kunde Anspruch hat - und dass sie sich widersprechen werden.

Wir behandeln Stripe als Quelle der Wahrheit und die Kopie der Anwendung als Cache, der aus Webhooks neu aufgebaut wird, mit idempotentem und signaturgeprüftem Handler. Ansprüche werden bei jedem Request aus Ihrer eigenen Datenbank gelesen, denn Stripe im Request-Pfad aufzurufen macht die Verfügbarkeit Ihres Produkts von deren abhängig.

Anteilige Abrechnung, Testphasen, Sitzplatzänderungen und fehlgeschlagene Zahlungen sind jeweils ein Zustand, den die Oberfläche ausdrücken muss. Was ein überfälliger Account noch darf, ist eine Produktentscheidung - wir fragen danach, statt eine zu erfinden.

Das Dashboard-Problem

SaaS-Dashboards sind die Stelle, an der App-Router-Anwendungen langsam werden. Der Reflex ist ein use client ganz oben, weil es Charts und Filter gibt - und dann geht der ganze Dashboard-Baum an den Browser.

Tabellen, Kopfzeilen, Navigation und Datenholen bleiben auf dem Server. Chart, Filter und Datumswähler sind Client-Inseln. Der URL-Zustand trägt die Filter, was eine gefilterte Ansicht teilbar und den Zurück-Button korrekt macht. Und keine Seite wartet auf ihr langsamstes Widget - jedes streamt hinter seiner eigenen Grenze, was der Punkt an loading.tsx ist kein Spinner ist.

Was wir nicht tun

Wir starten nicht von einem SaaS-Boilerplate. Diese kodieren Entscheidungen zu Mandanten, Auth und Billing, die für ein anderes Produkt getroffen wurden, und sie später aufzutrennen kostet mehr als die zwei Wochen, die sie gespart haben.

Wir bauen auch nicht das Admin-Panel zuerst. Es ist der Teil, den Gründer am liebsten spezifizieren, und der Teil, den Kunden nie sehen.

Wie ein Projekt abläuft

Die erste Woche ist eine Entscheidung und kein Bau: welches Mandantenmodell, welche Isolation Sie nachweisen müssen, und wonach die Sicherheitsprüfung Ihres größten plausiblen Kunden fragen wird.

Daraus wird ein schriftlicher Leistungsumfang mit dem Modell, dem Autorisierungsansatz, dem Abrechnungsverhalten und den Phasen, bepreist. Er wird unterschrieben, bevor das Produkt gebaut wird, denn dies ist das eine auf dieser Seite, das keine spätere Migration billig macht.

Dann die Phasen, die jeweils deployt enden, mit den Isolationstests direkt neben den Features.

Was Sie erhalten

Das Mandanten- und Autorisierungsmodell schriftlich geklärt, bevor der erste Screen entsteht, dann das Produkt dagegen gebaut. Die Testsuite zählt hier mehr als sonst, denn die Tests, auf die es ankommt, behaupten ein Scheitern: eine Anfrage mit der Session des einen Mandanten darf die Zeile eines anderen nicht erreichen.

Die Abrechnung kommt mit ihrer Abstimmung und nicht nur mit ihrem Checkout. Dazu die schriftliche Antwort auf die Isolationsfrage, die jeder Enterprise-Interessent irgendwann in eine Sicherheitsprüfung schreibt und die fertig weit billiger ist als unter Termindruck verfasst.

Umfang und Konditionen

Zusammenarbeit
Fester Umfang, schriftlich vereinbart, bevor die Arbeit beginnt. Kein Tagessatz gegen ein offenes Backlog.
Preis und Dauer
Beides wird je Projekt festgelegt, sobald der Umfang steht. Gemeinsam angeboten, bevor etwas gebaut wird.
Was wir von Ihnen brauchen
Eine Person, die entscheiden darf, und Zugang zu Ihrem Repository und Ticketsystem.
Nicht enthalten
Alles außerhalb des vereinbarten Umfangs. Es wird ein eigener Umfang statt eines Änderungsauftrags.
Kosten Dritter
Hosting, Lizenzen, API-Gebühren und SaaS-Abonnements schließen und zahlen Sie selbst.
Rechnungsstellung
Codefacture Yazılım A.Ş., Türkiye. EUR, USD oder GBP per Überweisung, ohne türkische Umsatzsteuer auf exportierte Leistungen.

Häufige Fragen

Eine Datenbank oder eine pro Mandant?
Für fast alle eine gemeinsame Datenbank mit einer Mandantenspalte, durchgesetzt in der Datenschicht und nicht in einer Middleware-Prüfung. Eine Datenbank pro Mandant ist eine ernsthafte Antwort, wenn ein Vertrag Isolation verlangt, und sie kostet Sie Migrationen, Backups und ein Verbindungsproblem, solange das Produkt lebt. Entscheiden Sie das vor dem ersten Screen.
Bauen Sie die Abrechnung?
Ja, meist auf Stripe. Der Checkout ist nicht der zeitaufwändige Teil. Anteilige Berechnung, Tarifwechsel mitten im Zyklus und ein Datenbestand, der ein Jahr später noch für eine Prüfung stimmt, sind es.
Können Sie an einem bestehenden Produkt arbeiten?
Ja, beginnend mit einem Audit, denn Mandantenfähigkeit in eine Anwendung nachzurüsten, die von einem einzigen Kunden ausging, ist eine andere Arbeit als sie einzubauen.
Wie lange bis zum ersten Kunden?
Drei bis vier Monate bis zu etwas Verkaufbarem, bei einem fokussierten Produkt mit abgestimmtem Umfang. Wir würden eher den Umfang kürzen als die Arbeit an Mandantenfähigkeit und Autorisierung, weil genau die sich nicht günstig nachrüsten lässt.
Anrufen+1 848 272 7583WhatsApp+90 850 308 5436E-Mailinfo@codefacture.comKontaktseite