Action Items mit KI extrahieren – Indie Builder Scope

Falls du um 23 Uhr vor einem leeren Terminal sitzt und überlegst, was du bauen könntest: Action Items aus Meeting mit KI extrahieren ist nicht zu groß für ein Wochenend-Projekt. Du brauchst einen Extraktor für diese strukturierte Information. Füttere das Tool mit einem Call-Transkript oder einem Haufen Notizen, es spuckt am Ende eine saubere Liste raus – wer macht was, bis wann. Der Code selbst braucht nur wenige Stunden API-Gluing. Die knifflige Frage ist: Findest du zwanzig Leute, die deine Version nutzen, statt einer der fünf etablierten Tools?

Was "Action Items" als Build-Ziel bedeutet

Wenn man den Buzzword-Kram weglässt, ist die Aufgabe sehr konkret: Unstrukturierter Text (ein Transkript, eine Voice-Memo-Transkription, ein Haufen Slack-Nachrichten) wird zu einer Liste von Objekten {task, owner, due_date, confidence}. Nur das. Keine Zusammenfassungen, keine Sentiment-Analyse, kein Dashboard. Nur Extraktion in ein Format, das eine Todo-App verarbeiten kann.

Das ändert die Scope-Schätzung massiv. Ein allgemeiner "Meeting Assistant" ist ein Sechsmonats-Produkt mit Transkriptions-Infrastruktur, Kalender-Sync und einer UI, über die eine ganze Abteilung streiten wird. Ein Action-Items-Extraktor ist ein Prompt, ein Schema und ein Platz für die Ergebnisse. Du kannst eine funktionierende Version live nehmen, bevor dein Kaffee kalt wird.

Die Eingabe muss nicht einmal ein Meeting sein. Das gleiche Schema funktioniert bei Commitments aus einem Slack-Standup, aus Tickets im Support-System, oder aus einer Client-Voice-Memo. Meetings sind die offensichtliche erste Zielgruppe, weil es dafür bereits Transkripte gibt – sie sind aber nicht der einzige Markt.

Der Stack für die erste Version (vom Transkript zur Task-List in 48 Stunden)

Hier die komplette Pipeline für v0:

1. Input: Transkript pasten oder .txt/.vtt hochladen (noch keine Live-Audio)
2. LLM-Call: Structured Output mit erzwungenem JSON-Schema
3. Storage: Supabase-Tabelle oder notfalls JSON-Datei für v0
4. Output: Markdown-Checkliste + optionaler Webhook zu Linear/Notion

Der Extraction-Prompt ist das einzige, das echte Iteration braucht. Etwas wie das hier bringt dich 80% weit:

Extrahiere Action Items aus dem Transkript unten.
Gib JSON-Array zurück: [{task, owner, due_date, confidence}]
Regeln:
- owner = genannter Name, sonst "unassigned"
- due_date = nur explizites Datum, sonst null
- vermeide vague Aussagen ("wir sollten über X nachdenken")
- confidence: 0–1, basierend auf Explizitheit des Commitments

Wei-Chen Liao, der an Recommendation Systems bei Appier in Taipei arbeitet, fasste ein ähnliches Projekt so zusammen: "Die Extraktions-Qualität hängt von der Transkript-Qualität ab, nicht von der Modell-Qualität. Investiere dein erstes Wochenende in Input-Cleaning, nicht in Model-Switching."

Die Kosten im Indie-Maßstab sind marginal. Ein einstündiges Meeting-Transkript zehrt 8.000 bis 12.000 Token durch einen Structured-Output-Call. Bei aktuellem API-Preis sind das Bruchteile eines Cents pro Meeting. Das teuerste ist die Transkription selbst – wenn du nicht bereits exportierte Text-Files nutzt.

Nimm nicht das größte verfügbare Modell. Ein kleines, günstiges Modell mit erzwungenem JSON-Schema und ein paar Beispiele erreicht Extraktions-Genauigkeit fast auf Flagship-Level, zu einem Bruchteil der Latenz und der Kosten. Spar die größeren Modelle für die Fälle auf, wo Confidence niedrig kommt und du einen zweiten Pass möchtest – nicht für jeden einzelnen Call.

Wo der Markt schon lebt – und er ist nicht leer

Bevor du baust, kennst du die Konkurrenz. Eine aktuelle Analyse von Action-Item-Tools sortiert die Kategorie zwischen $4 und etwa $40 pro Monat pro Seat ein – aufgeteilt in zwei Lager: Nur-Extraktions-Tools, die Tasks in Dokumenten liegen lassen, und Full-Loop-Tools, die Tickets direkt in Jira, Linear oder Asana vor Call-Ende schieben.

Die Teilung ist der interessante Teil. Der überfüllte Mittelgrund ist Nur-Extraktion: saubere Notes, kein Routing. Die Tools, die die letzte Meile automatisieren – das Ticket tatsächlich anlegen – sind seltener und teurer. Wenn du v1 scopest, das ist dein Keil: niemand braucht noch eine weitere Zusammenfassung. Sie wollen, dass das Task am Call-Ende bereits irgendwo existiert.

TicNote ist ein nützlicher Referenzpunkt hier – nicht weil du es empfehlen statt bauen sollst, sondern weil es zeigt, wie "gut genug zum Geldnehmen" auf der kleinen Seite aussieht: Es generiert echte Dateien, nicht nur eine Zusammenfassung in einem Chat-Fenster. Das ist der Standard.

Validiere, bevor du den Extraction-Prompt über das hinaus polierst, was jemand gefordert hat. Teile deine v0 in zwei, drei Freelancer- oder Indie-Hacker-Communitys, biete an, sie kostenlos auf echte Calls zu testen, und beobachte, was sie mit dem Output machen. Falls niemand dir ein Transkript in einer Woche schickt, nachdem du gefragt hast, ist das das Signal, den Niche zu ändern – nicht den Modell.

Skip die Echtzeit-Meeting-Bot. Bau zuerst die Async-Version.

Jeder Tutorial, den du findest, setzt voraus, du baust einen Bot, der live dem Call beitritt, zuhört und mid-Meeting zu Slack postet. Skip das. Echtzeit bedeutet Audio-Streaming, Diarization (Redner auseinanderhalten), einen Bot, der lag-frei im Call sitzt. Das ist nicht ein Wochenende. Das ist die Version, die Side-Projects in Woche drei tötet.

Die Async-Version ist die gleiche Kernlogik minus die harten Teile: Jemand paßt ein Transkript ein (von Zooms Export, von Otter, von einem Whisper-Lauf auf einer Aufnahme) und bekommt dreißig Sekunden später eine Task-Liste. Es ist weniger beeindruckend im Demo-Video. Es ist auch die Version, die du tatsächlich zu Ende bringst.

Es gibt bereits ein öffentliches n8n-Template, das AssemblyAI und GPT-4 in Google Sheets verkettet – genauso für das. Wert, vorher zu studieren, Wert, als Endprodukt zu ignorieren: Es kippt alles in ein Spreadsheet, das über ein Dutzend User zusammenbricht und dir nichts zum Monetisieren gibt.

Was ein Freelancer in Bangkok braucht, das ein Jira-Plugin nicht bietet

Die Rohversion dieses Tools ist für Teams bereits in Jira oder Linear gebaut. Das ist eine überfüllte, gut finanzierte Spur. Die unterversorgte Ecke sind Solo-Consultants und Freelancer – die Art von Person, die Napat Charoenwong schreibt, sein Studio in Bangkok runnt – die fünf Client-Calls pro Woche nehmen und kein Project-Management-Tool haben oder wollen.

Für diese Person ist der Gewinn nicht Ticket-Routing. Es ist eine Task-Liste, die nach dem Call in WhatsApp oder Email ankommt, getaggt nach Client, ohne Konfiguration. Drei echte Client-Calls pro Woche schlagen tausend Enterprise-Seats, die du als Solo-Builder ohne Sales-Team nie abschließen wirst.

Das ist eine echte Scope-Entscheidung, nicht ein Nice-to-have: Pick einen Delivery-Kanal (Email-Digest ist am billigsten zu bauen) und eine narrow Persona (Freelancer, Therapeuten, Consultants – jeden, der nach Call abrechnet) bevor du eine zweite Integration anrührst.

Die Ökonomie unterscheidet sich über Märkte. Ein $9/Monat-Tool schaut trivial von einer US-Perspektive, schaut wie eine echte Rechnung in Manila oder Bangkok aus, wo der gleiche Freelancer-Satz mehr abrechenbare Stunden abdeckt, die durch Admin verloren gehen. Preise für den Wert der Stunde, die du sparst, nicht für was ein Silicon-Valley-SaaS nimmt.

Wieso die No-Code-Version eher bricht als die bezahlte

Die n8n-und-Spreadsheet-Route ist das ehrliche Startsignal, hat aber ein Plafond: Rate Limits auf der Transkriptions-API, ein Spreadsheet, das über ein paar Dutzend Reihen unlesbar wird, und null Platz, um einen Login oder ein Abo reinzubauen. Es ist ein Prototype, keine Product.

Der Move, sobald du Demand validiert hast: Ersetze das Spreadsheet mit einer echten Tabelle (Supabase funktioniert in diesem Scale), füg ein Login hinzu, und setz einen Preis drauf. Du musst die Extraction-Logik nicht umbauen. Du musst aufhören, State an einem Platz zu speichern, durch den dir niemand zahlen kann.

Wert zu notieren, bevor du deep in die Pipeline gehst: Garbage Audio produziert Garbage Transcripts, und Garbage Transcripts produzieren Garbage Action Items, unabhängig davon wie gut dein Prompt ist. Falls deine Target-User auf messy Calls sind (schlechtes Wifi, Background-Noise, akzentiertes English über ein verteiltes Team), ein Noise-Cleanup-Schritt wie Krisp vor der Transkription spart dir mehr Debugging-Zeit, als den Extraction-Prompt zu tunen je wird.

Solltest du dafür Geld nehmen, oder es in was Größeres falten

Skip, wenn du gehofft hast, das wird ein Standalone-SaaS mit Venture-Scale-Zahlen. Die Kategorie ist billig gepreist ($4 bis $10 pro Seat sind realistisch, sobald du auf Preis konkurrierst) und die Giants haben bereits Kalender-Integrationen, Mobile Apps, und Sales-Teams. Solo-Dev gewinnt das nicht head-on.

Wert zu bauen, wenn du es als Feature behandelst – nicht als Company: Bolt es an eine Consulting-Practice als Value-Add, ship es als $9/Monat-Tool für einen einzelnen narrow Niche, den du bereits verstehst, oder nutze es als technischen Centerpiece eines Portfolio-Pieces, das dir LLM-Integration-Freelance-Work bringt. Alle drei sind realistische Outcomes für ein Wochenend-Build. "Otter.ai schlagen" ist nicht.

Falls der Extraction-Tool ein Stück eines größeren Toolkits ist, das du für Clients zusammensetzt – ein Client-facing Summary Doc oder One-Pager, das du sonst per Hand um die raw Task-Liste herum bautest – dann ist was wie Skywork wert einen Look zu bekommen für die umgebenden Deliverables.

Was wir tatsächlich zuerst shippten würden

Eine Single-Page-App: Transkript reinkopieren, Checkliste raus, zu Email exportieren oder als Markdown kopieren. Kein Login für v0. Keine Integrations. Teste es zwei Wochen auf deinen eigenen Calls, bevor du es jemand anderem zeigst – der Extraction-Prompt braucht echte Transcripts zum Brechen, nicht synthetische Test-Daten, die du selbst geschrieben hast.

Wenn es deine eigenen Calls übersteht, ohne commitment zu verpassen, zeig es fünf Freelancern oder Consultants, die du wirklich kennst. Nicht ein Reddit-Post, nicht ein Product-Hunt-Launch. Fünf Leute, deren Calls du anschauen kannst, wenn der Output falsch ist. Das ist der ganze erste Monat.

Was würden deine ersten zehn Transcripts wirklich brauchen, das das nicht bereits abdeckt?