Moin zusammen,
ich bin S.Weber47, arbeite vollzeit im Vertrieb und versuche nebenbei eine SaaS-Lösung für KMUs hochzuziehen. Derzeit stecke ich in der Entscheidung, ob ich mit No-Code-Tools (Bubble, Make, Zapier etc.) schneller zum MVP komme oder ob ich doch einen Developer für klassische Entwicklung ins Boot holen sollte.
Mein Gedanke war: Mit No-Code kann ich das MVP selbst bauen, spare Zeit und Geld – quasi ein Bootstrapping-Move. Aber ich frage mich, ob das später zur Falle wird. Wenn ich dann skalieren muss und mehr Kunden kommen, muss ich vielleicht komplett neu entwickeln?
Andererseits: Eine vollständige klassische Entwicklung kostet mich Zeit und Geld, die ich als Nebengründer gar nicht habe. Mein Vertriebsjob ist halt zeitintensiv.
Wie habt ihr das gelöst? Gibt es auch einen sinnvollen Mix? Und wie wichtig ist es wirklich, von Anfang an "sauber" zu entwickeln, wenn man noch nicht weiß, ob das Geschäftsmodell überhaupt funktioniert?
No-Code für MVP, klassische Entwicklung zum Skalieren – das ist der Standard und funktioniert auch bei mir. Mein Tipp: Nutze No-Code bewusst als Validierungstool, nicht als Langzeitlösung. Bei 20-30 bezahlten Kunden solltest du ohnehin über einen Dev nachdenken.
Das Problem mit No-Code ist weniger die Performance als die Gebundenheit an die Plattform. Wenn Bubble seine Preise verdoppelt oder Features ändert, stehst du dumm da. Klassische Entwicklung gibt dir Freiheit. Für KMU-SaaS brauchst du diese Freiheit wahrscheinlich später – aber nicht beim MVP. Guter Kompromiss: No-Code MVP + paralleles Design für klassische Rewrite.
Hey S.Weber47, ich bin in einer ähnlichen Situation wie du – auch Vollzeit Vertrieb, nebenher die Fintech-Idee. Ehrlich gesagt: Ich bin mit No-Code gestartet und würde es wieder machen.
Bei mir hat das geholfen, weil ich nebenbei einfach nicht die Kapazität für klassische Dev habe. Mit No-Code konnte ich in 2-3 Wochen testen, ob das Geschäftsmodell überhaupt ankommt. Der technische Overhead war niedrig, die Learning Curve überschaubar.
Aber ja, irgendwann kommt der Point, wo du umbauen musst – wenn's wirklich wächst. Das ist dann aber ein besseres Problem als eine Lösung zu bauen, die keiner braucht.