Technischer Gründer
Von der Idee bis zur Auslieferung: Wie ein technischer Gründer mit Claude Code und vollständigem Kontext baut
Der größte versteckte Kostenfaktor eines Einzelentwicklers besteht nicht darin, Code zu schreiben, sondern darin, genügend Kontext zu rekonstruieren, um den richtigen Code zu schreiben, und dann zu kommunizieren, was er versendet hat, an die richtigen Leute.
Der Betreiber
Ein technischer Gründer, der zwei SaaS-Produkte entwickelt und gleichzeitig vier Kundenprojekte betreut, führt sowohl einen Kontextwechselvorgang als auch einen Softwarevorgang durch. Für jedes Produkt gibt es eine eigene Roadmap, einen eigenen Backlog und eine Reihe von Stakeholder-Gesprächen. Jedes Kundenprojekt hat sein eigenes Repo, seinen eigenen Kommunikationsthread in Slack oder E-Mail und seine eigenen Erwartungen darüber, was wann erstellt wird. Der Gründer ist sowohl das Engineering-Team als auch der Account Manager, was bedeutet, dass jeder Kontextwechsel einen echten Aufwand mit sich bringt: Er muss sich wieder in das richtige mentale Modell versetzen, bevor eine einzige Codezeile geschrieben werden kann.
Die Tools, um die Software gut zu entwickeln, sind bereits vorhanden – Claude Code übernimmt die Implementierung, das Testen und die Iteration auf einem Niveau, das vor ein paar Jahren ein kleines Team erfordert hätte. Die Lücke liegt nicht im Gehirn, das die Arbeit erledigt; Es liegt an dem, was das Gehirn weiß, wenn es beginnt. Jede Arbeitssitzung beginnt mit denselben Fragen: Was habe ich aufgebaut, wo habe ich aufgehört, was hat sich in den Gesprächen mit den Stakeholdern seit der letzten Sitzung geändert und wer muss wissen, wann dies abgeschlossen ist?
Der Bruchpunkt
Der Overhead summiert sich in kleinen Mengen, die sich erst dann als strukturelles Problem anfühlen, wenn sie addiert werden. Der Gründer verbringt die ersten dreißig Minuten der meisten Sitzungen damit, Slack-Threads und E-Mails noch einmal durchzulesen, um den Spezifikationskontext zu rekonstruieren, den er zuletzt vor zwei Tagen klar im Griff hatte. Eine Funktion, die sie letzte Woche ausgeliefert haben, hat eine Stakeholder-Frage generiert, die sie noch nicht beantwortet haben, nicht weil sie sie verpasst hätten, sondern weil sie im falschen Tab angekommen ist. Ein Meilenstein eines Kundenprojekts, der in einer E-Mail vereinbart wurde, hat es in keine Aufgabe oder Zeitleiste geschafft, weil es keinen Moment gab, ihn anzuhalten und zu protokollieren.
Das tiefere Problem besteht darin, dass Claude Code, so mächtig er auch ist, jede Sitzung ohne jegliches Wissen beginnt. Der Gründer fügt den Kontext ein – die Spezifikation, den relevanten Thread, den aktuellen Status der Codebasis – und dann ist die Sitzung produktiv. Der Einfügeschritt ist jedoch manuell, verlustbehaftet und nie ganz abgeschlossen. Das Modell argumentiert brillant über jeden Kontext, den es erhält; Die Einschränkung besteht darin, dass die Zusammenstellung dieses Kontexts menschliche Zeit und menschliches Urteilsvermögen erfordert, bevor die eigentliche Arbeit beginnt.
Wenn etwas versendet wird, fällt der Kommunikationsschritt an das Ende des Prioritätsstapels. Die Funktion ist fertig; Den richtigen Leuten zu sagen, ist Reibung. Ein Stakeholder, der auf eine Lieferung wartete, erfährt es Tage später, nicht weil der Gründer sie vergessen hatte, sondern weil es kein System gab, das eine abgeschlossene Aufgabe in eine ausgehende Benachrichtigung umwandelte.
Der Aufbau
Der technische Gründer verbindet Gmail für Kundenkommunikationsthreads und Google Drive für Spezifikationen, Designdokumente und Projektbeschreibungen. Jedes Produkt und jedes Kundenengagement erhält eine eigene Organisation und ein eigenes Projekt innerhalb von Lodestar – zwei Produktorganisationen mit ihren eigenen Roadmap-Projekten, vier Kundenorganisationen mit jeweils einem Lieferprojekt. Der MCP-Server ist mit Claude Code verbunden, sodass jede Terminalsitzung das vollständige Betriebsbild erreichen kann, ohne zu einem Browser-Tab wechseln zu müssen.
Lodestar erfasst die vorhandenen E-Mail-Threads und Drive-Dokumente und beginnt mit der Extraktion von Aktionselementen mit Beweisen – jeweils verknüpft mit dem genauen Angebot oder der Datei, aus der sie stammen. Innerhalb eines Tages sind die offenen Punkte in allen sechs Kontexten an einem Ort sichtbar, geordnet nach Projekten, wobei die Fälligkeitstermine dort angegeben sind, wo sie im Quellmaterial erschienen sind. Der Gründer hat nichts davon manuell eingegeben; es tauchte aus der bereits existierenden Kommunikationsgeschichte auf.
Der Arbeitsablauf
Eine typische Arbeitssitzung beginnt mit einer Aufforderung in natürlicher Sprache an Claude Code: Wie ist der aktuelle Stand des Tages? Ab diesem Zeitpunkt läuft die Sitzung vollständig im Editor. Kein Tab-Wechsel, keine manuelle Kontextzusammenstellung, kein separater Kommunikationsschritt am Ende.
- ·Sinn – Claude Code ruft „dashboard_today“ über das MCP auf, um das tägliche Ranglistenbild zu erhalten. Die Antwort zeigt drei fällige Maßnahmen in den sechs Kontexten: eines blockiert eine Produktveröffentlichung, eines eine vom Kunden zu erbringende Leistung und eines eine Antwort von Stakeholdern, die gewartet hat.
- ·Sinn – Der Gründer sagt: Implementieren Sie das blockierende Element. Claude Code ruft „action_items_retrieve“ für die ID dieses Elements auf, um den vollständigen strukturierten Datensatz abzurufen: das Spezifikationsfragment, aus dem es extrahiert wurde, das verknüpfte Drive-Dokument, den E-Mail-Thread, in dem sich der Stakeholder zuletzt beteiligt hat, und den zugehörigen Codebasiskontext.
- ·Sinn – Claude Code ruft „knowledge_search“ und „files_content“ auf, um die aktuelle Spezifikation und alle vorherigen in Drive protokollierten Designentscheidungen abzurufen. Es ruft „context_resume“ auf, um anzuzeigen, was zuletzt im Stakeholder-Thread entschieden wurde. All dies kommt in der Sitzung an, ohne dass der Gründer einen einzigen Browser-Tab öffnet.
- ·Entscheiden – Sobald der vollständige Kontext zusammengestellt ist, plant Claude Code die Implementierung: Was soll erstellt werden, in welcher Reihenfolge, wie soll es getestet werden. Der Gründer prüft den Plan, bestätigt oder passt den Ansatz an und die Umsetzungssitzung beginnt.
- ·Handeln – Claude Code schreibt den Code, führt Tests durch und iteriert. Wenn die Implementierung fertig ist, sagt der Gründer: Versenden Sie sie und schließen Sie den Kreis. Claude Code ruft „action_items_partial_update“ auf, um das Element als erledigt zu markieren, und dann „timeline_events_create“, um den Abschluss anhand der Zeitleiste des Projekts zu protokollieren.
- ·Schließen – Claude Code ruft „emails_reply_link“ auf, um eine Stakeholder-Benachrichtigung zu verfassen – basierend auf dem genauen Element, das abgeschlossen wurde, und verweist auf die ursprüngliche Anfrage aus dem Thread. Der Entwurf wird im Fenster „Erstellen“ des Gründers geöffnet. Sie überprüfen es und klicken auf „Senden“. Claude Code ruft „milestones_partial_update“ auf, um den Projektmeilenstein voranzutreiben, wenn der Abschluss einen solchen auslöst.
- ·Das gleiche Muster wiederholt sich für die vom Kunden zu erbringende Leistung: Kontext abrufen, implementieren, schließen, benachrichtigen. Die gesamte Sitzung – Kontextzusammenstellung, Implementierung, Statusaktualisierung, Stakeholder-Benachrichtigung – bleibt im Editor.
Was ändert sich
Der Einfügeschritt verschwindet. Claude Code kommt zu jeder Sitzung mit der Spezifikation, dem Thread-Verlauf, den vorherigen Entscheidungen und den offenen Verpflichtungen, die bereits im Gültigkeitsbereich liegen – weil Lodestar sie in strukturierter Form bereithält und der MCP sie bei Bedarf anzeigt. Die Reibung, bevor die eigentliche Arbeit beginnt, reicht von einer halbstündigen Rekonstruktionsübung bis hin zu ein paar Sekunden Modellabruf.
Die Stakeholder-Kommunikation wird zu einem Nebenprodukt der Schifffahrt und nicht zu einer separaten Aufgabe. Wenn ein Element geschlossen wird, wird der Benachrichtigungsentwurf aus dem tatsächlichen Abschlusskontext und nicht aus dem Speicher generiert. Der Gründer überprüft und verschickt, anstatt alles von Grund auf neu zu verfassen. Die Kluft zwischen etwas, das versendet wird, und der richtigen Person, die darüber Bescheid weiß, bricht zusammen.
Das Betriebsbild in sechs Kontexten bleibt ohne manuelle Wartung aktuell. Aktionselemente werden automatisch aus Kommunikationsthreads angezeigt. Meilensteine schreiten voran, wenn die Beweise eintreffen. Die Zeitleiste spiegelt wider, was tatsächlich passiert ist, und basiert auf demselben Quellmaterial, das Claude Code für die Erstellung der Software verwendet hat.
Was sich ändert
- ·Die Kontextzusammenstellung vor jeder Arbeitssitzung wird durch den MCP-Abruf ersetzt – die Spezifikation, der Thread-Verlauf und frühere Entscheidungen sind im Editor verfügbar, ohne dass die Anwendung gewechselt werden muss.
- ·Durch das Versenden einer Funktion wird der Stakeholder-Kreislauf automatisch geschlossen – die Benachrichtigung wird anhand des tatsächlichen Fertigstellungsdatensatzes erstellt und nicht aus dem Speicher rekonstruiert.
- ·Offene Aktionselemente in sechs Kontexten (zwei Produkte, vier Kundenprojekte) sind an einem Ort sichtbar, aus E-Mail und Drive extrahiert und mit Beweisen versehen.
- ·Die modellunabhängige Architektur bedeutet, dass beim Wechsel von Claude Code zu einem anderen Tool der gesamte akkumulierte Kontext erhalten bleibt – das Gehirn ist austauschbar, das Betriebsbild jedoch nicht.
- ·Meilensteine und Zeitpläne werden anhand realer Arbeitsereignisse aktualisiert und nicht anhand manueller Statuseinträge, sodass der Projektdatensatz widerspiegelt, was tatsächlich geliefert wurde.