03 / was wir machen
Produktentwicklung, von der Discovery bis zum zweiten Release.
Ein kleines Team, das ein Produkt von der unbewiesenen Idee zu zahlenden Nutzern bringt und es danach am Laufen hält.
was drin ist
Scope ist der einzige Hebel, der einen Termin zuverlässig bewegt.
- Discovery
- MVP Build
- Plattformarchitektur
- Langfristige Wartung
Was wir hier machen
Aeternum bringt ein Produkt von der Idee, für die jemand argumentiert hat, zu einem System, für das echte Nutzer zahlen. Zwei Entwickler gehen den ganzen Weg: Discovery, Build, Architektur und die Wartung danach. An keiner Stelle wird an ein anderes Team übergeben.
Die Reihenfolge zählt mehr als das Tempo. Die meisten gescheiterten Produkte waren sauber gebaut und falsch gezielt.
Wir betreiben ein eigenes Produkt
DriveFlow ist unser SaaS für Schweizer Fahrschulen: Buchung, Ausbildungskarte, Rechnungen und Schulverwaltung in einer App. Wir haben es gebaut, wir betreiben es, und es geht jetzt mit echten Fahrschulen in den Pilotbetrieb.
Das ist hier aus einem Grund relevant. Jede architektonische Abkürzung, die wir dir empfehlen könnten, haben wir selbst schon bezahlt, auf einem System, von dem wir nicht weglaufen können.
Wie wir schätzen
Wir offerieren Bandbreiten statt Punktwerte und sagen dir, welches Ende wir erwarten. Die Breite ist selbst eine Information: eine weite Spanne heisst, im Briefing steckt eine offene Frage, und der schnellste Weg sie zu schliessen ist meist ein Tag Prototyp statt eines weiteren Meetings.
Was wir nicht ehrlich schätzen können, sagen wir als nicht schätzbar an und schlagen einen Spike vor.
Wartung gehört zum Build
Ein Produkt, das ohne Wartungsplan startet, bekommt trotzdem einen, meist im ungünstigsten Moment. Wir klären vorher, wer alarmiert wird, wie schnell, und was ein Fix kostet. Dependency-Updates laufen monatlich. Du bekommst eine schriftliche Notiz, was sich geändert hat, in einer Sprache, die du an einen Kunden weiterleiten kannst.
wie ein build abläuft
Wie ein Build abläuft
Discovery
Wir kartieren den Ablauf, den das Produkt ersetzt, benennen die eine Aufgabe, die es besser können muss als der heutige Zustand, und streichen alles andere. Am Ende stehen Scope, ein grober Plan und eine ehrliche Meinung dazu, ob gebaut werden soll.
MVP Build
Die schmalste Version, für die jemand tatsächlich zahlt. Auth, Billing und Deployment sind ab der ersten Woche drin, denn sie nachzurüsten ist der klassische Grund, warum aus einem Prototyp kein Produkt wird.
Plattformarchitektur
Sobald die Form belegt ist, werden die bewusst naiven Teile neu gebaut: Datenmodell, Hintergrundjobs, Berechtigungen, Mandantenfähigkeit. Das passiert mit Nutzern auf dem System, nicht davor.
Langfristige Wartung
Dependency-Updates, Reaktion auf Störungen, und dieselben zwei Leute, die es gebaut haben, damit niemand die Codebasis neu lernen muss.
fragen
Fragen zu Produktentwicklung.
Was ist das kleinste sinnvolle Mandat?
Baut ihr MVPs oder Produktivsysteme?
Habt ihr ein eigenes Produkt ausgeliefert?
Was passiert, wenn der Termin fix ist?
beiträge dazu
Beiträge dazu
Alle BeiträgeErzähl uns, was du bauen möchtest.
Schick uns das Briefing. Scope und Rahmen bekommst du innerhalb von zwei Arbeitstagen.