Entrepreneur.com hat vor kurzen einen Artikel veröffentlicht über die richtige Auswahl einer Low-Code Plattform. (Originaltitel: How to Choose a Low-Code Development Platform That Has Your Best Interests In Mind). Der Titel ist allerdings etwas irreführend, denn im Grunde geht es in dem Artikel nur um das Pricing und andere, wichtige Faktoren werden außer Acht gelassen. Hier ist die Essenz dieses Artikels. Ich habe zu jeder Variante noch Go und No-Go Cases eingefügt:
Wenn das Pricing Modell einer LC/NC (Low-Code/No-Code) Plattform sich nach der Anzahl der Endanwender richtet, wird dir das potenziell teuer zu stehen kommen. Dabei bist nicht du als Anwender der SaaS gemeint, sondern die User der fertigen App. D.h. jeder neue Endanwender kostet dich X€ pro Monat.
Für eine kleine App, die ggf. nur deine 40 Mitarbeiter:innen als User nutzen, kann das sehr wohl etwas sein. Vor allem, wenn die anderen Features für sich sprechen.
Für eine B2C App, mit der du Hunderttausende User erreichen willst, kann das nichts werden.
Eine Variante bei sehr vielen SaaS Produkten ist das Pricing Pro „Sitz“. In diesem Fall zahlst du X€ pro Monat pro Mitarbeiter Account. Das kann pro Account zwar recht teuer sein, aber sich unterm Strich dennoch rentieren. Im Vergleich zu obigen Methode lassen sich diese Kosten wesentlich besser prognostizieren und einhalten.
Wenn du wenige Developer:innen hast und sich die evtl. hohen Kosten rechtfertigen lassen. Außerdem sollte sichergestellt sein, dass auch wirklich alle das Tool nutzen.
Wenn du ein großes Developer Team hast, die Kosten pro Account hoch sind und nur wenige Developer ihre Account aktiv nutzen. Es kann Fälle geben, bei denen alle Zugang zum Back-End brauchen aber nur Wenige die Features nutzen müssen. Wenn das Tool dir dann nicht erlaubt zwischen den Rollen zu differenzieren (z.B. zwischen „Viewer“ und „Admin“), dann wird das unnötig teuer.
Vorab und bevor PETA diesen Post boykottiert: Tier im Englischen heißt so viel wie „Stufe“ oder „Rang“. Hier werden keine Tiere verkauft. D.h., du zahlst X€ pro Monat, je nachdem welche Stufe du buchst. Du kennst das von Freemium Modellen und sehr viele SaaS Tools setzen ihr Pricing so an. Basic, Premium, Enterprise etc. Der Vorteil hier ist, du hast einen fixen Monats- oder Jahrespreis. Der kann aber auch sehr hoch sein.
Wenn du User und Developer einladen möchtest, ohne Mehrkosten zu verursachen. Aber auch, wenn sich die Kosten für die angebotenen Features rentieren.
Wenn sich die monatlichen oder jährlichen Kosten nicht gegen die Benefits und Einnahmen aufwiegen lassen. Schließt du z.B. einen Jahresvertrag ab, weil er 25% weniger kostet, als der monatliche Plan - du aber nach 3 Monaten merkst, dass deine Idee nicht funktioniert… ja, dann werden es 9 teure Monate.
Zu guter Letzt die Kosten pro Nutzungseinheit. Oft sind das z.B. X€ pro GB Datenspeicher, X€ pro API Call oder aber auch X€ pro eigene Einheiten der Tools. Zuletzt hat Bubble.io ihre Einheit „Workload Units“ eingeführt und das Pricing daran festgesetzt. Der Vorteil hierbei ist, dass man wirklich nur für das zahlt, was man nutzt.
→ Übrigens haben Alex & Lilith letztens zu Bubble’s neuen Workload Units gesprochen und was das nun für Bubble Apps bedeutet. Hier geht's zur Folge.
Du willst deine Produktkosten möglichst flexibel halten. Oder auch wenn das Tool Einheiten berechnet, die für dein Produkt irrelevant sind - denn hier kannst du ggf. wichtige Features nutzen aber die Kosten gering halten.
Das Tool macht er unüberschaubar wie sie die Einheiten berechnen. Die nötige Leistung für deine App hängt direkt an den Einheiten dran die dazu noch teuer sind. Oder auch, wenn du zwar viel Einheiten brauchst diese aber eigentlich nicht relevant für den Mehrwert sind.
Ich habe zuletzt eine App mit Glide gebaut. Der limitierende Faktor dabei ist die Anzahl an Zeilen, die ich in der Datenbank haben kann. Bei mehr als 500 Zeilen, hätte ich 25$ pro Monat zahlen müssen. Das wäre für meine Anwendung, zu teuer gewesen. Für den Mehrwert der App war es aber überhaupt nicht wichtig, dass Glide die eingegebenen Daten als Zeilen sammelt. Also habe ich das System umgangen. Wie? Das erzähle ich in Folge 88 des VisualMakers Podcast. Hier lang!
