Softwareentwicklung

SaaS-Entwicklung in Marokko: Wie aus einer Idee ein Produkt wird, das sich verkauft

Von Codevista InnovationsVeröffentlicht am 12. Oktober 202610 Min. Lesezeit

Wer in Marokko ein SaaS aufbaut, muss zuerst nachweisen, dass ein klar umrissenes Problem es wert ist, dafür zu bezahlen, und dann ein schlankes MVP liefern, bevor der Umfang wächst. Die grundlegenden Entscheidungen fallen früh: Multi-Tenant-Modell, Authentifizierung und Rollen, Zahlungsabwicklung (ein lokales Gateway wie das CMI für Zahlungen in Dirham, ein internationaler Zahlungsdienstleister je nach Struktur Ihres Unternehmens) und ein Hosting, das mit dem marokkanischen Datenschutzgesetz 09-08 vereinbar ist. Sicherheit, Observability und Preismodell werden ab dem ersten Sprint mitgedacht, nicht erst nach dem Launch.

Wo fängt man an, wenn man ein SaaS entwickeln will?

Am Anfang steht keine Funktionsliste, sondern ein Problem, das ein bestimmter Nutzer tatsächlich hat. „Die Personalverantwortliche eines mittelständischen Unternehmens trägt jeden Monat die Urlaubstage von Hand in einer Tabelle zusammen“ ist verwertbar; „HR digitalisieren“ ist es nicht. Die Discovery-Phase prüft vor jeder größeren Investition drei Dinge:

1. Das Problem ist real und tritt häufig auf: Gespräche mit Nutzern aus der Zielgruppe verraten mehr als eine theoretische Marktstudie.
2. Jemand ist bereit zu zahlen: Wer unterschreibt die Bestellung, und was ersetzt Ihr Tool (eine Tabelle, eine bestehende Software, eine Person)?
3. Die Lösung ist machbar, mit den unverzichtbaren Integrationen (ERP, E-Mail, Lohnabrechnung …) und mit einem Budget, das zu dem Preis passt, den der Markt akzeptieren wird.

Klickbare Prototypen, denselben Nutzern gezeigt, korrigieren die Customer Journey, bevor entwickelt wird. Sie fließen in ein brauchbares Lastenheft ein, das sich auf Bedarf und Akzeptanzkriterien konzentriert statt auf eine Liste von Bildschirmen.

Welchen Umfang sollte ein SaaS-MVP haben?

Das MVP (Minimum Viable Product) ist keine schlampige Version, sondern die kleinste Version, mit der ein Kunde sein Problem lösen und bezahlen kann. Es deckt die gesamte Customer Journey ab, wenn auch bescheiden:

• Registrierung und Anlage des Kundenkontos;
• die Kernfunktion, für die der Kunde das Abonnement abschließt;
• eine Zahlungsmöglichkeit, anfangs auch halb manuell;
• ein Support-Kanal und ein Weg, Feedback zu sammeln.

Alles andere (erweiterte Dashboards, mobile App, nachrangige Konnektoren) wartet auf das erste Feedback. Eine praktische Regel: Eine Funktion, die keiner der befragten Nutzer verlangt hat, gehört nicht ins MVP. Kurze Sprints, die mit einem Review enden, in dem das funktionierende Produkt gezeigt wird, helfen, diesen Umfang zu halten; eine Scrum-Schulung gibt dem Produktteam den Rahmen, um das Backlog zu priorisieren, ohne abzudriften.

Multi-Tenant-Architektur: gemeinsames Schema oder Datenbank pro Kunde?

Ein SaaS bedient mehrere Kunden (die „Tenants“) mit einer einzigen Anwendung. Die entscheidende Frage ist, wie weit die gemeinsame Nutzung der Daten reicht, und jede Option verlagert die Kosten an eine andere Stelle.

Gemeinsames Schema mit Tenant-ID

Jede Tabelle enthält eine Spalte, die den Kunden identifiziert, und jede Abfrage filtert danach. Das ist das Modell, das sich am einfachsten betreiben lässt: eine einzige Datenbank, eine einzige Migration pro Änderung, überschaubare Infrastrukturkosten, einfache übergreifende Auswertungen. Das Hauptrisiko ist ein Datenleck zwischen Kunden, wenn ein Filter vergessen wird. Man verringert es, indem man die Tenant-Auflösung in einer einzigen Schicht bündelt, Row-Level Security aktiviert, wenn die Datenbank sie anbietet (zum Beispiel PostgreSQL), und automatisierte Tests schreibt, die gezielt versuchen, Daten eines anderen Kunden zu lesen.

Ein Schema pro Kunde

Die Tabellen jedes Kunden liegen in einem eigenen Bereich derselben Datenbank. Die Isolation ist klarer, und einen einzelnen Kunden wiederherzustellen ist einfacher. Dafür muss jede Migration auf alle Schemas angewendet werden, und die Deployment-Werkzeuge müssen dort weitermachen können, wo sie abgebrochen sind.

Eine Datenbank pro Kunde

Maximale Isolation, geschätzt von Großkunden und regulierten Branchen, mit der Möglichkeit, einen Kunden separat zu hosten. Der Preis: Monitoring, Backups, Verbindungen und Migrationen vervielfachen sich mit der Zahl der Kunden.

Für den Start genügt meist das gemeinsame Schema, vorausgesetzt, die Tenant-ID ist überall vorhanden und der Code erlaubt es, einen anspruchsvollen Kunden später in eine eigene Datenbank zu verschieben. Achten Sie auch auf den „Noisy Neighbour“-Effekt: Ein sehr aktiver Kunde darf die anderen nicht ausbremsen, daher sind Quoten und Verarbeitungs-Queues pro Tenant sinnvoll. Die Wahl des Tech-Stacks wirkt sich auf all das aus: siehe den Tech-Stack mit Go und Next.js modernisieren.

Authentifizierung, Rollen und Zahlung: welche Optionen gibt es in Marokko?

Ein B2B-Kunde erwartet mindestens, Kolleginnen und Kollegen einladen zu können, getrennte Rollen (Administrator, Nutzer, nur Lesen) und Zwei-Faktor-Authentifizierung; große Unternehmen verlangen oft Single Sign-on (SSO) mit ihrem Verzeichnisdienst. Das ist ein sensibler Baustein: Besser auf einen Identitätsanbieter oder eine bewährte Bibliothek setzen, als ihn selbst neu zu schreiben.

Bei der Zahlungsabwicklung hängt alles von Ihren Kunden und der Rechtsform Ihres Unternehmens ab:

• Marokkanische Kunden, die per Karte zahlen: Die lokalen Online-Zahlungslösungen, etwa die auf das CMI (Centre Monétique Interbancaire, die marokkanische Interbanken-Clearingstelle für Kartenzahlungen) gestützten Angebote von Banken und Zahlungsdienstleistern, sind der übliche Weg, um in Dirham zu kassieren. Klären Sie mit Ihrer Bank, ob wiederkehrende Zahlungen im gebuchten Angebot enthalten sind, bevor Sie Ihr Abo-Modell darauf aufbauen.
• Internationale Kunden: Ein internationaler Zahlungsdienstleister (Stripe oder Vergleichbares) übernimmt Abonnements, Mahnungen und Rechnungen, doch der Zugang hängt vom Land ab, in dem Ihr Unternehmen eingetragen ist. Klären Sie das mit Ihrer Bank und Ihren Beratern, einschließlich der Devisenvorschriften.
• Großkunden: Die Überweisung auf Bestellung ist weiterhin üblich; planen Sie von Anfang an eine saubere manuelle Rechnungsstellung ein.

Kapseln Sie die Abo-Logik (Tarife, Testphasen, Planwechsel, Gutschriften) hinter einer internen Schnittstelle: Ein Wechsel des Zahlungsdienstleisters oder die Kombination mehrerer darf nicht dazu zwingen, das Produkt neu zu schreiben.

Wo hostet man ein SaaS in Marokko? Gesetz 09-08 und CNDP

Sobald ein SaaS personenbezogene Daten verarbeitet (Mitarbeitende, Endkunden, Patienten …), gilt das Gesetz Nr. 09-08 über den Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten, das marokkanische Datenschutzgesetz. Je nach Verarbeitung kann eine vorherige Meldung oder Genehmigung bei der CNDP, der nationalen Datenschutzbehörde, erforderlich sein, und die Übermittlung von Daten ins Ausland ist geregelt: Auch sie kann eine Genehmigung erfordern.

Die Wahl zwischen einem Hoster in Marokko und einer internationalen Cloud ist daher nicht nur eine Frage von Preis oder Latenz. Drei Fragen geben den Rahmen vor:

• Welche personenbezogenen Daten verarbeitet das Produkt, und welche davon sind sensibel (zum Beispiel Gesundheitsdaten)?
• Was verlangen Ihre Zielkunden in ihren Verträgen, insbesondere Behörden und regulierte Branchen?
• Welche Formalitäten schreibt die CNDP für diese Verarbeitung und gegebenenfalls für die Übermittlung vor?

Klären Sie diese Punkte mit Ihrem Rechtsbeistand, bevor Sie einen Vertrag mit einem Hoster unterschreiben: Produktionsdaten nachträglich zu migrieren ist langwierig und riskant.

Sicherheit und Observability ab der ersten Version

Ein SaaS bündelt die Daten all seiner Kunden: Eine Sicherheitslücke betrifft sie alle gleichzeitig. Das Minimum ab dem ersten Produktivgang:

• Verschlüsselung der Datenübertragung und der Backups, mit tatsächlich getesteten Wiederherstellungen;
• Secrets außerhalb des Codes gespeichert und personengebundene Administrationszugänge;
• Audit-Logs für sensible Aktionen (Exporte, Rechteänderungen, Löschungen);
• Observability: Metriken, zentralisierte Logs und Alarme, aufgeschlüsselt nach Tenant, um einen Vorfall vor Ihren Kunden zu bemerken;
• aktuell gehaltene Abhängigkeiten und systematisches Code-Review.

B2B-Einkäufer stellen genau diese Fragen in ihren Sicherheitsfragebögen. Die Norm ISO/IEC 27001 bietet einen anerkannten Rahmen, um sie zu beantworten: siehe was ein ISO-27001-Zertifikat wirklich belegt.

Welches Preismodell passt zu einem B2B-SaaS?

Der Preis wird getestet wie eine Funktion. Die gängigsten Modelle:

• Pro Nutzer (pro Seat): leicht verständlich und passend für Collaboration-Tools, verleitet den Kunden aber dazu, die Zahl der Konten zu begrenzen und damit die Nutzung.
• Nutzungsbasiert: nach Volumen (Dokumente, Transaktionen, API-Aufrufe); am Wert ausgerichtet, aber für das Budget des Kunden weniger planbar.
• Gestaffelt: Tarife, die Funktionen und Limits kombinieren; zum Start oft der Kompromiss, der sich am einfachsten verkaufen lässt.
• Hybrid: ein Basis-Abonnement nach Stufe, zuzüglich einer nutzungsbasiert abgerechneten Überschreitung.

Unabhängig vom Modell gilt: Knüpfen Sie den Preis an die Werteinheit, die der Kunde wahrnimmt, sehen Sie für Großkunden einen Tarif „auf Anfrage“ vor und speichern Sie die Tarife als Konfigurationsdaten statt im Code, damit sich Preise ohne erneutes Deployment anpassen lassen. Eine Testphase dient dazu, den Nutzen zu beweisen; ein dauerhaft kostenloses Angebot ergibt nur Sinn, wenn es tatsächlich zahlende Abschlüsse bringt.

Die Fehler, an denen SaaS-Projekte scheitern

Am Scheitern ist selten die Technologie schuld:

• Das MVP überladen: monatelange Entwicklung vor dem ersten zahlenden Kunden, auf Annahmen, die nie am Markt überprüft wurden.
• Das Onboarding vernachlässigen: Ein Kunde, der den Nutzen des Produkts nicht schnell erkennt, bleibt kaum. Einrichtungsassistent, Beispieldaten und Import aus dem bisherigen Tool sind vollwertige Funktionen.
• Den Churn ignorieren: Kündigungen verfolgen, abwandernde Kunden befragen und die tatsächliche Nutzung messen sagt mehr aus als die Zahl der Registrierungen.
• Sicherheit und Compliance aufschieben: Sie nachträglich aufzuholen kostet mehr und blockiert Abschlüsse mit Großkunden.
• Einen Dienstleister nur nach dem Preis auswählen: siehe die Kriterien, um eine Softwareagentur in Casablanca auszuwählen.

Individuelle Softwareentwicklung in Casablanca: was sollten Sie vorbereiten?

Ob Sie intern entwickeln oder mit einem Dienstleister: Mit diesen Unterlagen gewinnen Sie in den ersten Wochen Zeit:

• das Problem in einem Satz formuliert, und die Nutzer, die bereits befragt wurden;
• die Customer Journey des MVP, einschließlich dessen, was ausdrücklich ausgeschlossen ist;
• die Liste der verarbeiteten personenbezogenen Daten und Ihre Vorgaben zum Hosting;
• die geplanten Zahlungskanäle und die juristische Einheit, die die Rechnungen stellt;
• ein Budgetrahmen und ein realistischer Termin, auch wenn beides nur grob geschätzt ist.

Codevista Innovations entwickelt in Casablanca individuelle SaaS-Lösungen (Multi-Tenant-Architekturen, Abonnementverwaltung; Next.js, Go, Python, TypeScript) nach Scrum: eine Discovery- und UX/UI-Designphase, danach zweiwöchige Sprints, die zur Abnahme auf einer Staging-Umgebung bereitgestellt werden. Das Unternehmen ist nach ISO 27001:2022 zertifiziert. Um Ihr Projekt zu umreißen, sprechen Sie uns an.

Häufige Fragen

Wie lange dauert die Entwicklung eines SaaS-MVP?

Das hängt vom Umfang, von den Integrationen und davon ab, wie verfügbar die Testnutzer sind. Statt ein festes Datum anzupeilen, beschränken Sie das MVP auf eine minimale, aber vollständige Customer Journey (Registrierung, Kernfunktion, Bezahlung, Support), die in kurzen Sprints geliefert wird. Jedes Sprint-Review hilft, Überflüssiges zu streichen. Ein MVP, das sich endlos hinzieht, deutet fast immer auf einen zu großen Umfang hin, nicht auf ein zu langsames Team.

Was kostet die Entwicklung eines SaaS in Marokko?

Einen Standardpreis gibt es nicht: Die Kosten hängen vom Umfang des MVP ab, von der Zahl der Integrationen (ERP, Zahlung, SSO), von den Anforderungen an Isolation und Sicherheit und schließlich vom Betrieb (Hosting, Monitoring, Wartung). Ein klar abgegrenztes Problem und ein bedarfsorientiertes Lastenheft ermöglichen vergleichbare Angebote und erlauben es, den Umfang zu verkleinern, statt an der Qualität zu sparen.

Müssen die Daten eines SaaS in Marokko gehostet werden?

Nicht grundsätzlich, aber die Frage sollte früh geklärt werden. Das Gesetz 09-08 regelt die Verarbeitung personenbezogener Daten und ihre Übermittlung ins Ausland, unter der Aufsicht der CNDP. Je nach Art der Daten und den Anforderungen Ihrer Kunden, insbesondere öffentlicher oder regulierter Auftraggeber, kann ein Hosting in Marokko notwendig werden. Lassen Sie diese Entscheidung von Ihrem Rechtsbeistand prüfen und klären Sie die geltenden Formalitäten mit der CNDP, bevor Sie einen Vertrag mit einem Hoster unterschreiben.

Kann man für ein SaaS Abonnements in Dirham abrechnen?

Ja. Für marokkanische Kunden, die per Karte zahlen, ermöglichen die lokalen Online-Zahlungslösungen, insbesondere die auf das CMI gestützten Angebote von Banken und Zahlungsdienstleistern, Zahlungen in Dirham. Wiederkehrende Zahlungen hängen vom gebuchten Angebot ab: Klären Sie das mit Ihrer Bank. Bei Großkunden ist die Überweisung auf Bestellung weiterhin üblich. Machen Sie die Abonnementverwaltung unabhängig vom Zahlungsdienstleister, damit Sie ihn wechseln oder mehrere kombinieren können.

Welche Multi-Tenant-Architektur eignet sich für den Start eines SaaS?

Für die meisten Projekte ist ein gemeinsames Schema mit einer Tenant-ID in jeder Tabelle der beste Ausgangspunkt: eine einzige Datenbank, einfache Migrationen, überschaubare Kosten. Es verlangt konsequentes Filtern, abgesichert durch Row-Level Security, wenn die Datenbank sie anbietet, und durch Isolationstests. Ein eigenes Schema oder eine eigene Datenbank ist für Kunden gerechtfertigt, die eine starke Isolation verlangen.