aeternum

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.

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

  1. 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.

  2. 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.

  3. 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.

  4. Langfristige Wartung

    Dependency-Updates, Reaktion auf Störungen, und dieselben zwei Leute, die es gebaut haben, damit niemand die Codebasis neu lernen muss.

Fragen zu Produktentwicklung.

Was ist das kleinste sinnvolle Mandat?

Eine Scoping-Runde, bevor irgendetwas gebaut wird. Am Ende stehen Scope, eine Schätzung und eine ehrliche Meinung dazu, ob überhaupt gebaut werden soll. Uns ist lieber, wir verlieren den Build, als dass wir einen auf einem ungeprüften Briefing starten.

Baut ihr MVPs oder Produktivsysteme?

Beides, und der Unterschied ist kleiner als gedacht. Auth, Billing und Deployments sind auch im MVP ab Woche eins dabei, weil genau diese drei verhindern, dass ein Prototyp je ein Produkt wird.

Habt ihr ein eigenes Produkt ausgeliefert?

Ja. DriveFlow ist unser eigenes SaaS für Schweizer Fahrschulen, von uns beiden gebaut und betrieben und jetzt auf dem Weg in den Pilotbetrieb. Wir betreiben es weiterhin selbst und tragen damit die Wartung und die Supportanrufe, die unsere eigenen Architekturentscheidungen erzeugen.

Was passiert, wenn der Termin fix ist?

Dann bewegt sich der Scope, weil er der einzige Hebel ist, der das zuverlässig tut. Wir zeigen dir, welche Teile wegfallen können, was jeder davon an Zeit zurückgibt und was der Verzicht die Nutzer kostet. Mehr Leute auf ein spätes Zweierprojekt zu setzen macht es später.

Beiträge dazu

  1. Was wir prüfen, bevor ein echter Betrieb damit arbeitetProdukt4 Min. Lesezeit
Alle Beiträge

Erzähl uns, was du bauen möchtest.

Schick uns das Briefing. Scope und Rahmen bekommst du innerhalb von zwei Arbeitstagen.