Die Agentur hat vorgeschlagen, unser Tool als SaaS-Entwicklung zu bauen: Was bedeutet das für uns?

Klingt nach der klassischen Agenturfalle. Sie haben euren internen Betriebsbedarf gesehen, der für 15-20 Tausend Dollar zu lösen wäre, und das Projekt zu SaaS umgebaut, um das Budget zu verdoppeln. Habt ihr ein Marketingteam, Supportpersonal oder Vertriebsnetz, um an andere Firmen zu verkaufen? Wenn nicht, bleibt diese Infrastruktur völlig ungenutzt.

Trefft bei der Bewertung des Angebots folgende Unterscheidung: 1) Internes Nutzungstool: Es formt sich nur nach euren Geschäftsprozessen, Flexibilität ist nicht nötig. 2) SaaS: Es erfordert flexible Einstellungen, Panelverwaltung und Zahlungsintegration, um die unterschiedlichen Arbeitsweisen anderer Firmen zu unterstützen. Wenn euer erstes Ziel ist, euer eigenes Geschäft zu retten, arbeitet zuerst nur für euer eigenes Team.

Wir sind vor drei Jahren mit genau derselben Euphorie für unser eigenes Logistikunternehmen gestartet. Haben 55.000 Dollar hingeblättert und eine SaaS-Architektur aufbauen lassen. Das Produkt ist super geworden, aber uns fehlte schlicht die Zeit, es an andere Firmen zu verkaufen; außerdem wollten die Konkurrenten ihre Daten natürlich nicht in unser System einpflegen. Am Ende saßen wir nur auf monatlichen Mehrkosten von 600 Dollar für Server und Wartung.

Softwareanbieter zu sein und ein Lebensmittelgroßhändler zu sein sind zwei völlig verschiedene Berufe. Ein SaaS zu betreiben bedeutet: mitten in der Nacht klingelt das Telefon, weil der Server abraucht externe Kunden meckern wegen Rechnungen und fordern ständig neue Features. Seid ihr bereit quasi über Nacht ein Software-Supportcenter hochzuziehen, obwohl euer Kerngeschäft Logistik ist? Wenn die Antwort darauf Nein lautet, dann lasst euch eine interne Software bauen statt eines SaaS.

Wenn sie eine Multi-Tenant-Architektur aufsetzen: Wird die Datenbanktrennung logisch oder physisch umgesetzt? Selbst wenn Sie es nicht nach außen verkaufen: Die Wartungs-, Test- und Release-Zyklen von Systemen, die als SaaS gecodet wurden, sind um ein Vielfaches aufwendiger als bei monolithischen internen Tools, die nur für ein einziges Unternehmen gedacht sind.

Fordern Sie von der Agentur ein überarbeitetes Angebot an: „Wie sähen Budget und Zeitplan aus, wenn Sie dasselbe Tool als reines Single-Tenant-Webpanel nur für unsere interne Nutzung entwickeln?“ Wahrscheinlich halbiert sich das Angebot. Wenn man die beiden Zahlen nebeneinanderlegt fällt die Entscheidung gleich viel leichter.

agenturen hypen kunden gerne mal so auf nur um ein vorzeigeprojekt fürs eigene portfolio zu haben dann naja lasst es lieber, holt euch was schlichtes was euren zweck erfüllt und spart euch zeit und geld.

eigentlich ist die Idee gar nicht so verkehrt; wenn es in der Branche da wirklich eine Lücke gibt, könnte das später ein super Nebeneinkommen sein. aber ihr könnt das Budget drücken, indem ihr der Agentur sagt: „Lasst uns die erste Version erst mal nur intern nutzen. haltet die Datenbank so flexibel dass man sie später erweitern kann aber lasst Module wie Rechnungsstellung und Billing erst mal komplett weg.“

Das hier Beschriebene ist genau das, was wir erlebt haben. Nur weil alle es tun, heißt es nicht, dass es richtig ist.

Wenn der Umfang wächst, müssen entweder Zeit oder Budget wachsen. Eine dritte Option gibt es nicht. Wenn deine Situation anders ist, ändert sich das natürlich.

Das hatte ich auch schon überlegt. Scheut euch nicht zu fragen, wer nicht fragt, zahlt am Ende mehr.

Zwei Wochen Notizen machen liefert bessere Ergebnisse als eine sechsmonatige Schätzung. Nur als Notiz, könnte nützlich sein.

Ich möchte etwas fragen. In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf.

Schreibt mir wenn ihr Fragen habt ich antworte so gut ich kann.

Es gab drei verschiedene Ansichten, die sich alle ergänzen. naja ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

Das ist meine Meinung ich behaupte nicht dass es absolut richtig ist.

Kannst du das etwas genauer erklären? Der Zahlungsplan sollte an die Projektphasen gekoppelt sein, nicht an den Kalender.

Wenn deine Situation anders ist, ändert sich das natürlich.

So klar geschriebene Texte sind selten. Wer bei was bedeutet saas entwicklung hetzt, stolpert alle an derselben Stelle.

In den ersten drei Monaten läuft alles gut, die Probleme tauchen im vierten Monat auf. Das ist meine Meinung, ich behaupte nicht, dass es absolut richtig ist.

Ich fasse das Thema mal zusammen, da es mehrere unterschiedliche Antworten gab. Kein Prozess ohne Dokumentation verbessert sich, weil man nicht weiß, was man verbessern soll.

Schreibt mir, wenn ihr Fragen habt, ich antworte so gut ich kann.

Kannst du das etwas genauer erklären? Ein Change-Request-Prozess verlangsamt die Arbeit nicht, sondern beschleunigt sie.

Vor zwei Jahren habe ich genau dasselbe erlebt. Wenn du zu einem Thema drei verschiedene Antworten bekommst, war die Frage falsch gestellt.

Das war's, entschuldige, wenn ich zu lang war.

Ich spreche mal aus der Gegenperspektive, ich bin auf der Lieferantenseite. Wenn wir ohne Messung entscheiden landen wir immer wieder am selben Punkt.

Schreibt mir wenn ihr Fragen habt, ich antworte so gut ich kann.