Vom Einfall zum Produkt
SaaS heißt: Software, die im Browser läuft und monatlich bezahlt wird. Wir bauen den Kern, bringen ihn zu echten Nutzern und entwickeln ihn im Betrieb weiter.
Software as a Service, kurz SaaS, bedeutet, dass Kunden eine Anwendung mieten statt kaufen. Sie melden sich an, nutzen die Software im Browser und zahlen pro Monat oder Jahr. Für den Anbieter verschiebt sich damit die Arbeit: Der Bau ist der kleinere Teil, der größere ist alles, was danach kommt.
Genau dieser Teil wird beim Planen gern übersehen. Registrierung, Tarife, Zahlungsausfälle, Kündigungen, Support, Datenexport, Löschfristen. Wir kennen diese Liste aus dem eigenen Betrieb, weil wir zwei Produkte selbst anbieten und betreuen. Beide stehen ausführlich unter Eigene Software.
Für Gründer heißt das vor allem eines: früh in den Markt. Eine schlanke erste Fassung mit echten Nutzern bringt in wenigen Wochen mehr Erkenntnis als ein Jahr Konzeptarbeit. Was danach gebaut wird, entscheidet die Nutzung und nicht die ursprüngliche Ideensammlung.
Jemand arbeitet seit Jahren in einer Branche und weiß genau, woran es dort hakt. Das ist die beste Ausgangslage für ein Produkt, weil das Fachwissen schon da ist. Was fehlt, ist die Umsetzung und jemand, der die technischen Entscheidungen verantwortet.
Im eigenen Betrieb läuft eine Anwendung, die andere in derselben Branche ebenfalls brauchen könnten. Der Weg dorthin führt über Mandantenfähigkeit, also getrennte Daten je Kunde, über Selbstregistrierung und über eine Abrechnung. Der fachliche Kern bleibt.
Es gibt eine Anwendung und erste Kunden, aber die Anmeldung bricht ab, die Abrechnung läuft von Hand, und jede Frage landet beim Gründer. Hier lohnt sich der Blick auf Einstieg, Tarife und Automatisierung, bevor neue Funktionen dazukommen.
Das unterscheidet ein Produkt von einer Anwendung für einen einzelnen Betrieb.
Am Anfang steht die Frage, welcher Ausschnitt schon allein nützlich ist. Diese erste Fassung enthält bewusst wenig, dafür funktioniert sie vollständig. Alles andere wird notiert und später nach Bedarf entschieden.
Mehrere Kunden teilen sich ein System, ohne je die Daten der anderen zu sehen. Diese Trennung wirkt bis in die Datenbank hinein und beschränkt sich nicht auf die Oberfläche. Sie nachträglich einzubauen ist aufwendig, deshalb steht sie von Beginn an.
Neue Kunden legen ihr Konto selbst an und kommen ohne Hilfe zum ersten Erfolgserlebnis. Eine kurze Checkliste führt durch die Einrichtung, ein Datenimport übernimmt vorhandene Bestände aus einer Tabelle.
Abos, Testphasen, Wechsel zwischen Tarifen und fehlgeschlagene Zahlungen laufen über Stripe. Rechnungen entstehen automatisch, Kündigungen ebenso. Was der Tarif freischaltet, prüft die Anwendung an jeder Stelle selbst.
Im Kundenkonto arbeiten mehrere Personen mit unterschiedlichen Rechten. Inhaber sehen Auswertungen und Abrechnung, Mitarbeitende nur ihren Bereich. Einladungen und Sperren erledigt der Kunde selbst.
Bestätigungen, Erinnerungen und Hinweise gehen über die eigene Domain raus, damit sie ankommen und nicht im Spam landen. Inhalt und Zeitpunkt lassen sich je Produkt festlegen.
Hosting in der EU, Auftragsverarbeitungsvertrag für die eigenen Kunden, Export und Löschung auf Knopfdruck. Wer ein Produkt anbietet, verarbeitet fremde Daten und braucht dafür klare Antworten.
Sicherungen, Protokolle und eine Meldung, wenn etwas ausfällt. Dazu ein Weg, Fehler zu sehen, bevor Kunden anrufen. Dieser Teil kostet wenig und verhindert die unangenehmen Überraschungen.
Ein eigenes Produkt zu betreiben verändert den Blick auf Entwicklung. Plötzlich sind es nicht mehr Funktionen, die den Tag bestimmen, sondern Rückfragen zur Rechnung, ein Kunde mit einer alten Tabelle zum Import und die Frage, warum eine Erinnerung nicht angekommen ist. Diese Erfahrungen fließen in jedes Projekt ein, das wir für andere bauen.
Daraus folgen ein paar Entscheidungen, die wir früh treffen. Der Datenexport gehört in die erste Fassung, nicht in die dritte. Fehler bei Zahlungen bekommen einen eigenen Ablauf statt einer E-Mail an den Gründer. Und jede Funktion, die Support erzeugt, wird so gebaut, dass Kunden sie selbst bedienen können. Ein Produkt, das ständig erklärt werden muss, wächst nicht.
Wir klären, für wen das Produkt gedacht ist, welches Problem es löst und woran sich der Nutzen messen lässt. Aus der Ideensammlung wird eine Liste, sortiert nach dem, was für den Start wirklich nötig ist.
Die zentralen Ansichten entstehen als klickbarer Entwurf, dazu kommt ein Vorschlag für Tarife und Rechte. Danach steht ein Angebot für die erste Fassung mit festem Leistungsumfang.
Der Kern wird entwickelt, getestet und mit einer kleinen Gruppe ausprobiert. Diese Runde heißt Alpha und läuft mit Zugangscode, damit die ersten Sonderfälle nicht öffentlich passieren.
Registrierung und Zahlung gehen an, die ersten Kunden kommen ohne Begleitung ins Produkt. Ab hier zählt, was die Nutzung zeigt, nicht was geplant war.
Neue Funktionen entstehen in kurzen Abständen, jeweils an der Stelle mit dem größten Effekt. Betrieb, Überwachung und Support laufen daneben weiter.
Technik, mit der wir arbeiten
Produkte entstehen mit Next.js und einer PostgreSQL-Datenbank über Supabase. Abrechnung läuft über Stripe, gehostet wird in der EU. Für Trennung der Mandanten sorgen Rechte auf Datenebene.
Ein Produkt wird nach Umfang und Komplexität kalkuliert, feste Preise gibt es nicht. Üblich ist ein Angebot für die erste nutzbare Fassung und danach eine Abrechnung nach Aufwand für den Ausbau. Wie ein Angebot entsteht, steht auf der Seite Kosten.
Je enger der Zuschnitt, desto schneller steht das Produkt. Jede Funktion, die für den Start nicht zwingend ist, verschiebt den Moment, ab dem Nutzer zahlen können.
Ein einziger Tarif ist schnell umgesetzt. Mehrere Stufen, Zusatzmodule, Rabatte oder Abrechnung nach Nutzung brauchen jeweils eigene Regeln und eigene Tests.
Produkte mit Gesundheits-, Personal- oder Zahlungsdaten verlangen mehr Aufwand bei Rechten, Protokollen und Dokumentation als ein Werkzeug ohne solche Daten.
Wenn Kunden Bestände aus anderer Software mitbringen oder das Produkt mit fremden Systemen sprechen soll, kommt für jede Verbindung Entwicklungsarbeit dazu.
Support, Überwachung und regelmäßige Weiterentwicklung planen wir getrennt, damit du das Tempo nach den ersten Kundenzahlen selbst bestimmen kannst.
Fragen
MVP steht für die kleinste Fassung eines Produkts, die schon nützlich ist. Sie enthält einen Ablauf vollständig, statt viele Abläufe halb. Der Sinn dahinter ist einfach: Du bekommst Rückmeldung von echten Nutzern, bevor viel Geld in Funktionen fließt, die vielleicht niemand braucht. Für fast jedes Produkt ist das der sinnvolle Start.
Ja. Du bekommst den Quellcode, die Zugänge zu Hosting und Datenbank sowie eine Dokumentation. Wir arbeiten mit verbreiteten Werkzeugen, für die es viele Entwickler gibt. Eine Abhängigkeit, die nur auf fehlendem Zugang beruht, entsteht bei uns nicht.
Über Stripe. Kunden hinterlegen ihre Zahlungsart selbst, Abos verlängern sich automatisch, Rechnungen entstehen ohne Zutun. Fehlgeschlagene Zahlungen lösen einen festen Ablauf aus, vom Hinweis bis zur Sperre. Welche Tarife es gibt und was sie freischalten, legst du fest.
In der EU, in der Regel in Frankfurt. Jeder Kunde hat seinen eigenen Bereich, die Trennung wirkt bis in die Datenbank. Für deine eigenen Kunden brauchst du einen Auftragsverarbeitungsvertrag. Die technischen Angaben dazu liefern wir, den Vertrag selbst gibt dir dein Anwalt. Export und Löschung sind als Funktion im Produkt vorgesehen.
Ja, und das ist meist der längere Teil der Zusammenarbeit. Wir kümmern uns um Betrieb, Pflege und Weiterentwicklung, während du dich um Vertrieb und Kunden kümmerst. Wie eng die Begleitung ist, entscheidest du nach den ersten Monaten.
Oft ja. Wir sehen uns an, wie stark die Anwendung auf deinen Betrieb zugeschnitten ist und was an Mandantenfähigkeit, Registrierung und Abrechnung fehlt. Daraus entsteht eine Einschätzung, ob der Umbau günstiger ist als ein Neubau mit dem vorhandenen Fachwissen.
Passt dazu
Softwareentwicklung in der Region
Antwort innerhalb eines Werktags
Das erste Gespräch ist kostenfrei, 30 Minuten am Telefon oder im Online-Meeting. Per Formular, E-Mail, Telefon oder WhatsApp.
