Entwicklung von Web-Apps, SaaS und MVPs

Was ein Web-App- oder MVP-Projekt umfasst#

Wir richten die Zusammenarbeit am konkreten Briefing aus. Im Angebot steht, welche dieser Leistungen enthalten sind, wer welche Inhalte und Zuarbeiten liefert und wie jede Leistung abgenommen wird.

• Umfang der ersten Version: zentraler Workflow, Rollen und was warten kann
• Zentrale Screens, gestaltet mit Zuständen für leere Ansichten, Ladevorgänge und Fehler
• Datenmodell, serverseitige Zugriffsregeln und Tests, die versuchen, sie zu umgehen
• Nutzerkonten, Rollen und Team-Einladungen
• Zahlungen oder Abos, bestätigt durch verifizierte Callbacks des Zahlungsanbieters
• Admin-Ansicht, Produkt-Analytics-Events und Fehlermonitoring
• Deployment, Dokumentation und Übergabe von Repository und Konten

Zuerst Web-App, Website oder Produktdesign?#

Wählen Sie diese Leistung, wenn Kunden oder Mitarbeitende sich im Produkt anmelden und dort Aufgaben erledigen: etwas kaufen, buchen, einreichen, freigeben oder verwalten. Wenn Sie eine Website brauchen, die Ihr Angebot erklärt und verkauft, passt Web Development besser. Ist der Workflow noch nicht geklärt, beginnen Sie mit Product Design und bauen erst, wenn die zentralen Screens mit Nutzern getestet wurden.

Wie eine erste Version entsteht#

Wir starten mit einer Scoping-Phase: die Nutzer und Rollen, der eine Workflow, den die erste Version abschließen muss, die Daten, die jeder Schritt erzeugt, und die Entscheidungen, die die Kosten verändern, etwa Zahlungen, Integrationen und Berechtigungen. Das Ergebnis ist ein schriftlicher Umfang, klickbare zentrale Screens und ein Release-Plan, der benennt, was zurückgestellt wird.

Danach bauen wir in kurzen Zyklen auf einer Staging-Umgebung, die Sie nutzen können. Der erste Meilenstein ist ein dünner Durchstich des zentralen Workflows, der von Anfang bis Ende läuft, mit echter Anmeldung und echten Datenregeln, bevor die übrigen Screens ausgebaut werden. Zum Launch gehören Monitoring im Produktivbetrieb, ein Rollback-Pfad und die Übergabe von Repository, Hosting, Datenbank sowie Zahlungs- und Analytics-Konten auf Ihren Namen.

Was gehört in die erste Version eines MVP?#

Eine erste Version braucht alles, was ein echter Nutzer benötigt, um einen Workflow abzuschließen, und nichts, was erst in einer Größenordnung zählt, die Sie noch nicht erreicht haben. In der Praxis sind das fünf Dinge: Konten mit den Rollen, die der Workflow verlangt, der zentrale Workflow selbst, eine Admin-Ansicht, damit Ihr Team Datensätze ohne Entwickler einsehen und korrigieren kann, Zahlungen, falls das Geschäftsmodell vom ersten Tag an kassiert, und Analytics-Events, die zeigen, wo Nutzer aussteigen.

Zurückstellen sollten Sie, was sich von Hand erledigen oder später zukaufen lässt: eine native Mobile-App, Single Sign-on für Unternehmenskunden, eine konfigurierbare Berechtigungsmatrix, eine zweite Integration, In-App-Chat und Berichte, nach denen niemand gefragt hat. Jeder zurückgestellte Punkt bekommt trotzdem eine Zeile im Umfang, damit das Datenmodell Platz dafür lässt.

Die meisten Produkte setzen sich aus bekannten Modulen zusammen. Zwei verdienen eine Anmerkung: Buchung und Terminplanung sowie eine Lead-Pipeline für kleine Unternehmen, die Anfragen heute noch von Hand verfolgen. Beide wirken einfach und verbergen Entscheidungen zu Zeitzonen, Status und Zuständigkeit, die sich auf dem Papier günstiger klären lassen.

Welchen Stack nutzt Dardo, und wann entscheiden wir uns anders?#

Unser Standard ist TypeScript durchgängig: Astro für serverseitig gerenderte Seiten und interaktive Islands, Cloudflare Workers für Hosting und APIs, Cloudflare D1 oder Postgres für Daten und PostHog für Analytics und Experimente. Superame läuft auf Astro, das Ranking liegt in Neon Postgres. Eine Sprache und ein Deployment-Ziel halten ein kleines Produkt einfach im Betrieb und in der Übergabe.

Wir entscheiden uns anders, wenn das Produkt es verlangt. Eine dichte Oberfläche, die den ganzen Tag geöffnet bleibt, kann eine clientseitige React-Anwendung rechtfertigen, wie beim Prototyp von Shiimain. Auch lang laufende Jobs, aufwendige Datenverarbeitung oder ein internes Team, das bereits mit einem anderen Framework arbeitet, ändern die Antwort. Wenn Ihre Entwickler den Code nach dem Launch übernehmen, gewinnt in der Regel deren Stack.

Die Zugriffskontrolle testen wir zuerst. Die OWASP Top 10:2025 führen Broken Access Control weiterhin auf Platz eins und berichten, dass jede getestete Anwendung in irgendeiner Form davon betroffen war. Wir setzen Berechtigungen bei jeder Anfrage auf dem Server durch, verweigern standardmäßig, beschränken jede Abfrage auf die Organisation des angemeldeten Nutzers und schreiben automatisierte Tests, die versuchen, die Datensätze eines anderen Kunden zu lesen.

Wie sollten Zahlungen in einer Web-App funktionieren?#

Eine Zahlung wird vom Zahlungsanbieter auf dem Server bestätigt, nie durch den Browser, der vom Checkout zurückkehrt. Superame, ein öffentliches Projekt-Leaderboard in den veröffentlichten Arbeiten von Dardo, zeigt dieses Muster. Käufer zahlen im gehosteten Checkout von Dodo Payments, sodass Kartendaten nie in die App gelangen. Anschließend sendet der Anbieter einen signierten Callback; der Server prüft die Signatur und die Zahlungsdetails, bevor er Guthaben gutschreibt.

Rückerstattungen und Streitfälle laufen auf demselben Weg. Jedes Anbieter-Ereignis wird nur einmal verarbeitet, sodass ein doppelt, verspätet oder in falscher Reihenfolge eintreffender Callback Guthaben nicht zweimal hinzufügen oder abziehen kann. Superame veröffentlicht keine Nutzungs- oder Umsatzzahlen; es belegt, wie die Zahlungslogik aufgebaut ist, nicht den Verkaufserfolg.

• Käufer, die den Tab vor der Weiterleitung schließen, erhalten ihr Guthaben trotzdem, sobald der Callback eintrifft.
• Ein wiederholter oder gefälschter Callback wird abgelehnt.
• Eine Rückerstattung oder ein Streitfall macht genau das rückgängig, was die ursprüngliche Zahlung gewährt hat.
• Tarifgrenzen werden auf dem Server geprüft und nicht nur in der Oberfläche ausgeblendet.
• Test- und Live-Schlüssel sind getrennte Secrets und werden nie im Repository gespeichert.

Ihre Kunden mit eigenen Domains arbeiten lassen#

B2B-SaaS-Kunden möchten das Produkt oft unter ihrer eigenen Adresse nutzen, etwa portal.theircompany.com. Cloudflare for SaaS löst das mit Custom Hostnames: Die Tarife Free, Pro und Business enthalten 100, jeder zusätzliche Hostname kostet $0.10, das Maximum liegt bei 50,000. Wildcard-Custom-Hostnames gibt es nur im Enterprise-Tarif.

Ihr Kunde legt einen CNAME-Eintrag an, der auf Ihr Ziel verweist. Ein A-Record, der auf dieses Ziel zeigt und den eine Root-Domain bräuchte, wird standardmäßig nicht unterstützt, und Apex-Proxying ist ein Enterprise-Add-on, daher sollten die meisten Kunden eine Subdomain verwenden. Zertifikate werden per HTTP, TXT oder E-Mail validiert oder mit Delegated DCV, einem einmaligen Eintrag, mit dem Cloudflare sie automatisch erneuern kann. Ausgestellt werden sie von Let's Encrypt, Google Trust Services oder SSL.com.

Die Produktarbeit drumherum ist genauso wichtig: Nur bezahlte Tarife können eine Domain verbinden, ein Onboarding-Screen zeigt genau den Eintrag, der hinzuzufügen ist, der Verifizierungsstatus erklärt ausstehende und fehlgeschlagene Zustände in verständlicher Sprache, und das Monitoring warnt Ihr Team, wenn ein Zertifikat nicht erneuert werden kann, weil ein Kunde sein DNS geändert hat. Andere Hosts setzen andere Grenzen: Vercel erlaubt 50 Domains pro Projekt im Hobby-Tarif und unbegrenzt bei Pro und Enterprise, mit Soft Limits von 100,000 und 1,000,000; Netlify empfiehlt höchstens 50 Domain-Aliase pro Site.

Fragen vor Ihrer Entscheidung#

Aus dem Blog#

• Custom Domains für SaaS: Kunden mit Cloudflare for SaaS die eigene Domain nutzen lassen

  Kunden die eigene Domain auf Ihre SaaS zeigen lassen mit Cloudflare for SaaS: wie die Validierung funktioniert, was es Stand Oktober 2026 kostet und wo es hakt.