Hallo zusammen,
sitze gerade vor einem klassischen Dilemma und würde gerne eure Erfahrungen hören. Wir entwickeln eine B2B-SaaS-Plattform für Logistik und stehen vor der Frage: Wie weit kann man beim MVP gehen, bevor technische Schulden später richtig teuer werden?
Konkret geht es um die Architektur unserer API. Wir könnten jetzt schnell mit einem Monolithen starten, alles in eine Datenbank packen und in 6 Wochen live gehen. Oder wir investieren 3-4 Monate mehr und bauen gleich eine saubere Microservice-Architektur mit ordentlicher Trennung der Bounded Contexts.
Das Team ist gespalten: Die einen sagen "ship fast and learn", die anderen warnen vor dem großen Refactoring-Albtraum später. Wir haben schon erste Pilotkunden, die ungeduldig werden, aber ich kenne auch Stories von Startups, die nach 2 Jahren komplett neu entwickeln mussten.
Wo zieht ihr persönlich die Grenze? Welche technischen Entscheidungen haben sich bei euch später als teuer erwiesen, welche als richtig pragmatisch? Besonders interessant wären Erfahrungen aus dem B2B-Bereich, wo man nicht mal eben die App neu deployen kann wenn was schief geht.
Danke schonmal!
Kommt auf die Branche an würd ich sagen. B2B ist schon nochmal was anderes als Consumer-Apps.
Wir haben damals zu schnell shipped und mussten nach nem Jahr komplett neu machen. War aber auch nicht schlimm - haben dadurch viel über die echten Requirements gelernt.
Puh, schwierige Sache. Wir sind auch durch diese Hölle gegangen letztes Jahr.
Bei uns war's so: Monolith für MVP war richtig, aber wir haben ein paar grundlegende Dinge falsch gemacht. Keine Tests, keine ordentliche Logging-Strategie, alles hart kodiert. Das war dann später echt teuer.
Meine Faustregel mittlerweile: Infrastruktur und Grundlagen sauber machen, aber Features quick & dirty. Also: Monitoring, Deployment-Pipeline, Datenbank-Migrations, Error-Handling - da nicht sparen. Aber die Business-Logic kann erstmal hacky sein.
Und ganz wichtig: Von Anfang an Feature-Flags einbauen! Damit kann man später viel entspannter refactoren ohne die Kunden zu nerven.
Klassische Frage! Aus meiner Erfahrung würde ich sagen: Bei der Datenbank-Architektur nicht sparen. Alles andere kann man refactoren, aber Datenstrukturen zu ändern wenn erstmal Kundendaten drin sind ist der reinste Horror.
Wir haben damals bei einem Projekt genau den Fehler gemacht - alles in eine große Tabelle geworfen für's MVP. Nach einem Jahr hatten wir 50k Datensätze und mussten live migrieren. Hat uns 3 Wochen Entwicklungszeit gekostet plus jede Menge graue Haare.
Mein Kompromiss: Saubere Datenmodellierung von Anfang an, aber bei der Service-Architektur kann man pragmatisch bleiben. Monolith mit klaren Modulen ist oft besser als schlecht gemachte Microservices. Hatte ja schon mal über das Thema "zu früh optimieren" geschrieben - aber Datenstrukturen sind was anderes.