Was sollte man beachten, wenn man Apps für Business/Enterprise entwickelt?
(news.ycombinator.com)Eine auf HN gepostete Frage und stark empfohlene Antworten
Antwort 1
- Wer ist der Käufer? In der Regel ist er nicht identisch mit dem Nutzer des Produkts, und man muss verstehen, was er will.
- SSO, auf SAML-Basis
- Bei der Sicherheit die OWASP Top 10 abdecken und auch AppSec abdecken
- RBAC implementieren. Es Administratoren leicht machen, Nutzer hinzuzufügen und zu verwalten
- Ein Demo-Konto als Sandbox umsetzen und mit Daten befüllen, die realen Daten ähneln. Es für den Sales Pitch sehr einfach machen. Das Produkt für sich selbst sprechen lassen
- Multi-Tenancy von Anfang an berücksichtigen. Später ist es schwer hinzuzufügen
- Compliance-Anforderungen der jeweiligen Domäne von Anfang an einbauen. Dinge wie SOC 2 sind nicht so schwer. In der Zwischenzeit einen guten Security-Anbieter suchen, Tests durchführen lassen, Probleme mit hoher oder mittlerer Priorität beheben und Zertifikate erhalten. Das hilft beim Aufbau von Vertrauen bei Kunden
- Berichte. Administratoren brauchen in der Regel verschiedene Reports. Es ist gut, CSV-/Excel-Downloads anzubieten, damit sie die Daten in ihrer Tabellenkalkulationssoftware weiterverwenden können
- Nutzer können Fehler machen, daher immer Soft-Delete verwenden. Hard-Delete dann ggf. erst nach einigen Monaten
Antwort 2
- Als erster Engineer des Unternehmens habe ich 2 erfolgreiche Enterprise-Apps gebaut (eine verkauft, eine andere ist aktuell über 100M wert)
- Die einzige Sorge sollte sein: „Wollen und brauchen Kunden deine App wirklich?“ 99 % der Enterprise-SaaS-Produkte scheitern daran und nicht an fehlenden Features
- Enterprise-Funktionen wie SSO, Integrationen und Audit Trail kann man bauen, wenn Kunden sie anfordern
Diese Dinge sind größtenteils gelöste Probleme, wirken aber attraktiv, weil man Engineer ist - Das ignorieren und sich nur auf das Business-Problem konzentrieren: „Löst meine App einen akuten Bedarf meiner Kunden?“
Um die richtige Denkweise für diese Frage zu entwickeln, sollte man „The Mom Test“ lesen. Das ist im Moment das Wichtigste
Antwort 3
- Wenn ich an deiner Stelle wäre, würde ich die technischen Aspekte eines B2B-/Enterprise-Produkts zunächst für später aufheben
- Das Hauptproblem ist, den Sales-Prozess bzw. die GTM-(Go-to-Market-)Strategie zu verstehen. Wie andere schon gesagt haben, hilft es, sich mit jemandem zusammenzutun, der die Probleme bzw. die Branche kennt und Erfahrung im Verkauf an Unternehmen hat. Man sollte im Hinterkopf behalten, dass dies zur Kernkompetenz des Unternehmens wird, wenn man viel Geld verdienen will. Die Rolle eines technischen Leaders ist dabei eher beratend als bloß Produkte zu bauen und auszuliefern
- Wenn man allein vorgeht, sollte man mit vielen Personen sprechen, die an dem Business-Prozess beteiligt sind, und herausfinden, warum sie das Problem heute auf genau diese Weise lösen. Als Entwickler sehen wir Probleme oft als technische Probleme, aber in Wirklichkeit sind es häufig organisatorische, politische oder soziale Probleme. Nicht zuerst zu viel bauen, sondern zunächst einen visuellen Prototyp erstellen, den man zeigen und pitchen kann, und ihn Nutzern zum Testen geben
Antwort 4
- Vieles hängt davon ab, welche Art von Business du anstrebst. Wenn du auf Behörden oder Finanzorganisationen zielst, sind die Anforderungen deutlich umfangreicher als bei einem gewöhnlichen Software-Unternehmen
- Bei großen Unternehmen kann der Sales-Zyklus ziemlich lang sein, dafür kann das Volumen der Deals entsprechend groß ausfallen
- Der beste Rat, den ich nach einigen Jahren Verkauf an Unternehmenskunden geben kann, ist: „Verstehe deine Zielkunden.“ Nicht nur das Unternehmen selbst, sondern die tatsächlichen Menschen, denen du die Software verkaufen wirst. Sprich vor dem Start des Baus mit den Zielkunden, um genau zu verstehen, was sie brauchen (und ob das mit deiner Annahme übereinstimmt), und um zu prüfen, welche Hindernisse es für den Kauf deiner Software gibt. Wenn du die Anforderungen im Voraus kennst, erlebst du im Sales-Prozess keine Überraschungen
- Das Buch, das ich empfehle, ist The Mom Test. Dort lernt man, wie man die richtigen Fragen stellt, um Feedback von Zielkunden zu bekommen
Antwort 5
- Die App so bauen, dass sie eine API bereitstellt, und den Web-Client über diese API rendern lassen. Im Enterprise-Bereich ist Server-Side Rendering für SEO normalerweise nicht nötig
- In Unternehmen wollen Menschen nach der Nutzung deiner App oft selbst Automatisierungen bauen oder die App in andere Systeme integrieren. Wenn es dann eine API gibt, musst du dafür keine zusätzliche Arbeit leisten. Alles, was sie in der App tun können, können sie auch automatisieren
- Wenn eine Datenbank im Spiel ist, ermöglicht eine lesbare Read-Only-Replik für Nutzer schnelle Antworten auf alle Business-Fragen. Viele Business-Leute, Report-Ersteller und Engineers kennen sich sehr gut mit SQL aus.
Antwort 6
- Das Wichtigste ist, „ein Problem zu finden, für dessen Lösung Unternehmen bereit sind zu zahlen“. Ein einfaches MVP aufsetzen und von dort aus wachsen
Antwort 7
- Bereits auf Schema-Ebene für Multi-Tenancy bauen und designen
- ID und Login-Mechanismus entkoppeln – mehrere Login-Mechanismen pro Nutzer einplanen (E-Mail/Passwort, SAML, OpenID Connect, Google) und auch mehrere Authentifizierungsfaktoren berücksichtigen (TOTP, Duo, ..). Darauf achten, wie authentifizierte Nutzer unterschieden werden und wie E-Mail-Adressen verifiziert werden
- TLS auch für Datenbankverbindungen verwenden. Verschlüsselung einsetzen. Backups automatisieren und ermöglichen, Daten pro Kunde wiederherzustellen bzw. zu exportieren, nicht nur die gesamte Anwendung
- Eine Time-Series-Datenbank oder ein Event-Logging-System verwenden und einen Audit Trail für alle Aktionen erzeugen, die berechtigte Nutzer im System durchführen, sowie für Konto- oder Rechteänderungen und destruktive Aktionen
3 Kommentare
Das spürt man in den Einblicken.
Was sollte man beim Entwickeln von Apps für Business/Enterprise berücksichtigen?
https://tkim.co/2020/02/12/the-mom-test/
Das Geheimnis von SaaS-Unternehmen: Warum Multitenancy wichtig ist