Entwickeln
Sensaria entwickelt SaaS-Produkte für Gründerteams und Unternehmen, in der Schweiz wie im Ausland, vom ersten MVP bis zur mandantenfähigen Plattform, auf die sich zahlende Kunden verlassen. Wir konzipieren Architektur, Mandantentrennung, Abos und Billing, Benutzerverwaltung, öffentliche API und Dashboards und bleiben danach für Skalierung und Weiterentwicklung an Bord.
Ein SaaS-Produkt hat zwei Teile: die Funktionen, für die Kunden bezahlen, und die Plattform, die es vielen Kunden erlaubt, sie gleichzeitig und sicher zu nutzen. Zur Plattform gehören Mandantentrennung, Registrierung und Teamverwaltung, Abos und Billing, eine öffentliche API, Admin-Werkzeuge, Monitoring und ein Release-Prozess. Im ersten Jahr macht sie oft genauso viel Arbeit wie die Funktionen, und sie ist der Teil, der sich am teuersten nachrüsten lässt. Wir konzipieren beides von Anfang an und bauen nur so viel Plattform, wie die aktuelle Phase braucht.
| Phase | Ziel | Was am Ende steht |
|---|---|---|
| Analyse | Die riskanteste Annahme finden und das kleinste Produkt, das sie testet | Umfang, Architekturnotiz, Mandanten- und Preismodell |
| MVP | Echte Nutzer mit echten Daten | Registrierung, Kern-Workflow, Billing, Error-Tracking, Backups |
| Produktion | Zahlende Kunden, die sich darauf verlassen | Rollen, Audit-Log, öffentliche API, Admin-Konsole, Monitoring, Security-Review |
| Skalierung | Wachstum ohne ständiges Feuerlöschen | Queues, Caching, Limits pro Mandant, Performance-Budgets, Runbooks für den Pikettdienst |
Ein MVP ist klein im Umfang, nicht in der Qualität. Authentifizierung, Mandantentrennung und Logging sind ab dem ersten Release dabei, denn wer sie später ergänzt, muss jede Abfrage und jeden Screen anfassen.
Mandantenmodell. Gemeinsame Datenbank mit Mandantenspalte, ein Schema pro Mandant oder eine Datenbank pro Mandant. Meist starten wir mit einer gemeinsamen PostgreSQL-Datenbank und erzwingen die Trennung mit Row-Level Security, damit ein vergessener Filter im Anwendungscode nie die Zeilen eines anderen Mandanten preisgibt. Das Design lässt Raum, einen grossen Kunden später auf eine eigene Datenbank zu verschieben, wenn ein Vertrag das verlangt.
Identität und Zugriff. Sessions für die Webanwendung, API-Keys mit eingeschränktem Geltungsbereich für Integrationen und kurzlebige signierte Tokens (RS256), wenn das Produkt in eine andere Plattform eingebettet ist. Berechtigungen prüft das Backend bei jeder Anfrage.
Billing. Für Zahlungen ist der Billing-Anbieter die massgebliche Quelle; dafür, was ein Plan erlaubt, ist es Ihr Produkt. Signaturgeprüfte Webhooks halten beides synchron, und Zugriff wird nie allein aufgrund einer Weiterleitung im Browser gewährt.
API first. Eine versionierte REST-API mit OpenAPI-Dokument, Cursor-basierter Paginierung und Idempotency Keys bei schreibenden Anfragen. Für Produkte, die KI-Agenten nutzen können sollen, steht ein MCP-Server mit reinem Lesezugriff neben der API.
KI-Funktionen mit Grenzen. Wo das Produkt LLMs aufruft, ergänzen wir Kostenobergrenzen pro Mandant, eine Validierung des Modell-Outputs, einen Ausweich-Anbieter und für jeden Aufruf einen Eintrag mit Modell, Prompt-Version, Tokens und Kosten.
Als Checkliste für die Produktionsreife nutzen wir den OWASP Application Security Verification Standard (ASVS) und folgen den Praktiken des NIST Secure Software Development Framework (SP 800-218): Code-Review, statische Analyse und Secret-Scanning in der CI sowie ein dokumentierter Release-Prozess. Das revidierte DSG gilt für Personendaten, die in der Schweiz bearbeitet werden oder deren Bearbeitung sich dort auswirkt. Die DSGVO gilt, wenn Sie in der EU niedergelassen sind oder das Produkt Personen in der EU anbieten, und der EU AI Act kann KI-Funktionen erfassen, deren Output dort verwendet wird. Datenflüsse, Listen der Auftragsbearbeiter und Hosting (Schweiz oder EU-Region) legen wir so an, dass Ihre Antworten auf die Sicherheitsfragebogen Ihrer Kunden stimmen.
| Faktor | Wirkung auf den Aufwand |
|---|---|
| Mandantenmodell und Trennung | Eigene Datenbanken oder regionales Hosting pro Kunde erhöhen den Aufwand für Entwicklung und Betrieb. |
| Billing-Modell | Lizenzplätze, Nutzungsmessung, Testphasen und Steuern bringen jeweils eigene Regeln und Sonderfälle. |
| Integrationen | Jedes Drittsystem hat eigene Authentifizierung, eigene Limits und eigene Fehlerbilder. |
| KI-Funktionen | Prompt-Design, Evaluation und Kostenkontrolle kommen zur eigentlichen Funktion hinzu. |
| Enterprise-Anforderungen | Single Sign-on, Audit-Exporte und Security-Reviews kommen mit grösseren Kunden. |
| Bestehendes MVP | Die Ablösung einer No-Code- oder Prototyp-Codebasis braucht Datenmigration und Parallelbetrieb. |
Nach der Analysephase offerieren wir das MVP als Projekt mit festem Umfang und planen die späteren Etappen anhand dessen, was es Ihnen zeigt. Die Phasen und eine Checkliste zur Produktionsreife beschreiben wir ausführlicher im Beitrag vom MVP zum produktiven Betrieb.
Ein SaaS-Produkt braucht ein kommerzielles System rundherum. Testphasen und Registrierungen fliessen in CRM und Vertriebsautomatisierung. Onboarding-, Billing- und Nutzungs-E-Mails laufen über die E-Mail-Automatisierung. Produktdaten tauschen Sie über API-Integrationen mit den Tools Ihrer Kunden aus.
Wir bauen und betreiben Plattformen dieser Art. Ein Verzeichnis von Kommunikations-APIs, das wir gebaut haben, stellt eine öffentliche REST-API mit mehreren Endpunktgruppen und einem OpenAPI-Dokument bereit, dazu einen MCP-Server mit reinem Lesezugriff; Freitextanfragen verarbeitet ein deterministischer Parser statt eines LLM, sodass dieselbe Frage immer dieselbe Antwort erhält. Für einen Kunden haben wir ein mandantenfähiges Produkt mit PostgreSQL Row-Level Security gebaut, mit signierten ausgehenden Webhooks samt Wiederholungen und automatischer Deaktivierung sowie einem einbettbaren Widget, das sich mit kurzlebigen Tokens authentifiziert. Die Sensaria AG hat ihren Sitz in Lugano, Schweiz, und arbeitet auf Deutsch, Englisch, Italienisch und Französisch.
Was dazugehört
Domänenmodell, Mandantenmodell, Service-Grenzen und Datenflüsse werden früh entschieden und dokumentiert, damit das MVP nicht neu geschrieben werden muss, sobald der erste grosse Kunde kommt.
Das kleinste Produkt, das Ihre riskanteste Annahme mit echten Nutzern testet, auf produktionsreifen Grundlagen (Authentifizierung, Mandantentrennung, Logging), die sich später nur teuer nachrüsten lassen.
Mandantentrennung direkt in der Datenbank mit PostgreSQL Row-Level Security, dazu automatisierte Tests, die mandantenübergreifend zu lesen versuchen und scheitern müssen.
Pläne, Testphasen, Lizenzplätze und Nutzungslimits sind in Ihrem Produkt abgebildet; Zahlungen und Rechnungen übernimmt ein Billing-Anbieter wie Stripe Billing, synchron gehalten über signaturgeprüfte Webhooks.
Registrierung, Einladungen, Rollen und Berechtigungen, API-Keys mit eingeschränktem Geltungsbereich und Session-Richtlinien, dazu eine interne Admin-Konsole für Ihr Support-Team.
Eine versionierte REST-API mit OpenAPI-Dokument und, wo KI-Agenten Ihr Produkt nutzen sollen, ein MCP-Server mit reinem Lesezugriff daneben.
Dashboards für Ihre Kunden und eine interne Sicht auf Mandanten, Nutzung, fehlgeschlagene Jobs und Webhook-Zustellungen.
Ausgehende Webhooks, pro Endpunkt signiert, mit Wiederholungen und automatischer Deaktivierung toter Endpunkte; eingehende Webhooks werden geprüft und idempotent verarbeitet.
Hintergrund-Queues, Caching dort, wo es sich lohnt, Error-Tracking und strukturierte Logs sowie ein Release-Prozess, mit dem Sie jede Woche ausliefern können.
Typische Szenarien
Ein Gründerteam mit Interviews und Warteliste braucht ein Produkt, für das Kunden bezahlen. Wir schneiden das MVP auf den einen Workflow zu, für den Kunden zahlen, und starten von Anfang an mit Billing. So wird die Zahlungsbereitschaft gemessen statt angenommen.
Ein System, das für ein einzelnes Unternehmen gebaut wurde, erhält Mandanten, Self-Service-Onboarding und Billing, ohne die Workflows der ursprünglichen Nutzer zu stören.
Stösst ein No-Code-Prototyp bei Performance, Berechtigungen oder Integrationen an Grenzen, bauen wir ihn mit einem sauberen Datenmodell neu, migrieren die bestehenden Konten und betreiben beide Versionen parallel bis zur Umstellung.
Eine öffentliche REST-API mit OpenAPI-Dokument und ein MCP-Server mit reinem Lesezugriff erlauben es den Entwicklern und KI-Assistenten Ihrer Kunden, Ihr Produkt direkt abzufragen.
Ein Editor oder Widget, das andere Softwareunternehmen für ihre eigenen Nutzer einbetten: isoliert in einem iframe, mit kurzlebigen signierten Tokens und Theming pro Mandant.
FAQ
Ein fokussiertes MVP mit Registrierung, einem Kern-Workflow und Billing dauert typischerweise zwei bis vier Monate. Vom MVP zu einer produktiven Plattform, auf die sich zahlende Kunden verlassen, braucht es meist weitere drei bis sechs Monate mit mehreren Releases: Rollen, Audit-Logs, öffentliche API, Admin-Werkzeuge, Monitoring und ein Security-Review. Das Tempo hängt vor allem von Entscheidungen zum Umfang und von Integrationen ab.
Die wichtigsten Kostentreiber sind die Anforderungen an Mandantentrennung und Hosting, das Billing-Modell (Lizenzplätze, Nutzungsmessung, Testphasen, Steuern), Integrationen, KI-Funktionen und Enterprise-Anforderungen wie Single Sign-on oder Audit-Exporte. Preise veröffentlichen wir nicht. Nach der Analysephase offerieren wir das MVP als Projekt mit festem Umfang und planen die nächsten Etappen anhand dessen, was Sie aus dem MVP lernen.
Dass sich Kunden darauf verlassen können. Konkret: Mandantendaten sind auf Datenbankebene getrennt, der Zugriff wird bei jeder Anfrage geprüft, Fehler werden erfasst und gemeldet, Backups werden nicht nur erstellt, sondern testweise wiederhergestellt, Deployments sind automatisiert und umkehrbar, und Sie können den Sicherheitsfragebogen eines Kunden wahrheitsgemäss beantworten. Für den Sicherheitsteil dient uns OWASP ASVS als Checkliste.
Fragen Sie, wie Mandanten getrennt werden, wie der Billing-Status synchron bleibt, wie Test- und Release-Prozess aussehen und wer das Produkt nach dem Launch betreibt. Lassen Sie sich ein live betriebenes Produkt zeigen, das der Partner gebaut hat, inklusive API. Warnsignale sind Festpreise ohne Analysephase, fehlende automatisierte Tests und kein Plan für Code-Eigentum und Übergabe.
Ein Festpreis funktioniert gut für ein klar abgegrenztes MVP oder Release. Ist das Produkt live und ändern sich die Prioritäten wöchentlich, passt ein monatliches Kapazitätsmodell oder eine Abrechnung nach Aufwand besser, weil Sie laufend Dinge lernen, die den Plan verändern. Zahlungen nach Meilensteinen, gekoppelt an funktionierende Software im produktiven Betrieb, verbinden beides.
Für die Anwendung ist OWASP ASVS eine praxistaugliche Prüf-Checkliste, und das NIST Secure Software Development Framework (SP 800-218) beschreibt die Entwicklungspraktiken rundherum. SOC 2 und ISO/IEC 27001 sind organisatorische Zertifizierungen, die grössere Kunden später verlangen können; wer nach ASVS baut und Audit-Logs führt, hat es dabei deutlich leichter.
Das revidierte DSG gilt für Personendaten, die in der Schweiz bearbeitet werden oder deren Bearbeitung sich dort auswirkt. Die DSGVO gilt, wenn Sie in der EU niedergelassen sind oder das Produkt Personen in der EU anbieten; oft sind beide relevant. Der EU AI Act kann KI-Funktionen erfassen, deren Output in der EU verwendet wird, mit Pflichten je nach Risikokategorie. Datenflüsse, Listen der Auftragsbearbeiter und Hosting konzipieren wir mit Blick auf diese Regeln.
Ja. Wir exportieren das Datenmodell und die bestehenden Datensätze, bauen das Produkt mit sauberer Mandantentrennung, Berechtigungen und Tests neu, migrieren Konten und Daten und betreiben beide Versionen parallel, bis die Nutzer umgestiegen sind. Der Neubau lohnt sich, sobald das No-Code-Tool Performance, Zugriffskontrolle oder Integrationen begrenzt, aber nicht, bevor Sie zahlende Nutzer haben.
Eingesetzte Technologie
TechnologieSaaS-Produkte vom ersten MVP bis zur mandantenfähigen Plattform: Architektur, Mandantentrennung, Abos und Billing, Benutzerverwaltung, öffentliche API, Dashboards und Weiterentwicklung.