KI-Video-SaaS mit der Higgsfield API: Geschäftsmodell, Kosten, Risiken

Im Kern funktionieren diese Plattformen fast immer gleich: Sie sind ein Wrapper, also eine Hülle, um Bild- und Videomodelle, die im Hintergrund die eigentlichen Assets erzeugen. Je besser die Modelle werden, desto größer der Bedarf. Und je spitzer der Fokus einer Plattform, desto größer das Potenzial für ein profitables Produkt.

In diesem Artikel zeige ich dir, wie ich so eine Plattform als Software-as-a-Service (SaaS) entwickelt habe: von der Architektur über den Prototyp bis zur fertigen Videogenerierung. Danach schauen wir auf die Rechnung und auf die Risiken des Modells. Transparenzhinweis: Das zugehörige Video ist in Kooperation mit Higgsfield entstanden.

Das Geschäftsmodell: API-Arbitrage

Das Prinzip ist einfach. Du kaufst bei einem API-Anbieter eine Leistung pro Nutzung ein, hier die Generierung eines Bildes oder Videos. Deine Nutzer:innen kaufen bei dir Credits, also ein internes Guthaben, und verbrauchen es in deiner App. Zwischen deinen Einkaufskosten und dem Preis deiner Credits liegt deine Marge.

Die Higgsfield API bietet über einen einzigen API-Key Zugriff auf mehrere Bild- und Videomodelle. Abgerechnet wird nach Verbrauch, ohne Abo. Für ein Arbitrage-Modell ist das praktisch: Deine Kosten wachsen mit der Nutzung, nicht vorab.

Was Nutzer:innen bei dir bezahlen, ist nicht das Modell selbst. Sie bezahlen für deinen Workflow, deine Oberfläche und deinen Zuschnitt auf eine Zielgruppe.

Das Beispielprojekt: ein Creative Studio für Brands

Mein Beispiel ist ein Creative Studio für Marken. Teams laden ihre Brand-Assets hoch, also Logos, Produktbilder und Farben, und erstellen daraus Werbeanzeigen, Social-Media-Bilder und Produktvideos. Die App heißt im Projekt „Folder“.

Die wichtigsten Rahmenbedingungen aus meinem Briefing:

• Rollen: Owner, Admin und Member. Admins laden weitere Teammitglieder ein.
• Gemeinsames Guthaben: Das ganze Team nutzt ein Credit-Wallet.
• Aufladen und Abo: Teams laden Credits einmalig auf oder bekommen sie monatlich über ein Pro-Abo. Kündigung zum Monatsende.
• Eigenes Credit-System: Damit zwischen API-Kosten und Einnahmen eine Marge entsteht.

Die Architektur: Welche Werkzeuge du brauchst

Bevor es an die Entwicklung geht, ein Überblick über die Bausteine:

Row Level Security bedeutet: Die Datenbank sorgt selbst dafür, dass Nutzer A die Daten von Nutzer B nicht sehen kann. Bei einer Plattform, auf der Teams ihre Markenassets ablegen, ist das Pflicht.

Für die Entwicklung brauchst du noch keine Cloud-Version von Supabase. Docker Desktop ist kostenlos und lässt dich eine komplette Supabase-Instanz lokal betreiben. Wie so eine lokale Umgebung funktioniert, beschreibe ich in der Anleitung zur Testumgebung für Claude Code. Beim Hosting nimmst du am besten den Anbieter, den du ohnehin schon nutzt.

Schritt 1: Prototyp in Claude Design

Bevor ich eine Zeile Code entwickeln lasse, baue ich die App in Claude Design. Zuerst ein Designsystem: Ich gebe ein Produktbriefing ein und kann zusätzlich ein GitHub-Repository verknüpfen, Design-Dateien etwa aus Figma verlinken oder Logos, Bilder und Schriften hochladen. Daraus entsteht ein Designsystem mit Logo-Varianten, Markenfarben, Kontrasten, Komponenten und ersten Screens.

Darauf aufbauend erstelle ich einen klickbaren Prototyp. Für das Creative Studio habe ich den kompletten Ablauf zum Erstellen eines Creatives abgebildet: Kategorie wählen, Art des Assets (Anzeige, Produktvideo, Banner), Format, Briefing und Prompt, Modellauswahl, Zusammenfassung und Ergebnisseite.

Der Grund: Strukturänderungen wie eine neue Navigation sind im Prototyp schnell gemacht. In einer fertig entwickelten App sind sie aufwendig.

Exportiert habe ich das Ganze über „Share“ als HTML-Projektarchiv, also als einzelne HTML-Dateien pro Unterseite. Die Option „Standalone HTML“ packt alles in eine Datei, die Claude Code später nur schwer wieder auseinandernehmen kann.

Schritt 2: Context7, GitHub und API-Key einrichten

Context7 für aktuelle Dokumentation

Ohne Zugriff auf aktuelle Dokumentation greift Claude auf seine Trainingsdaten zurück, und die sind nicht zwingend aktuell. Das ist eine der häufigsten Fehlerquellen bei der Entwicklung mit KI. Der Context7 MCP Server gibt deinem Coding Agent Zugriff auf aktuelle Dokumentation von Frameworks und Schnittstellen, unter anderem auch der Higgsfield API. Die Einrichtung ist ein einzelner Befehl, danach greift Claude automatisch darauf zu.

Privates GitHub-Repository

In GitHub klickst du auf „New“, gibst einen Namen und eine Beschreibung ein und stellst die Sichtbarkeit auf private. Die Adresse des Repositorys brauchst du gleich.

API-Key bei Higgsfield

Auf platform.higgsfield.ai legst du einen Account an, lädst Guthaben auf und erstellst im entsprechenden Menüpunkt einen API-Key. Optional kannst du ein Ablaufdatum festlegen. Dort findest du auch die Übersicht der verfügbaren Modelle und die API-Dokumentation.

Den Key speicherst du später in der Datei .env.local deines Projekts. Diese Datei wird nicht zu GitHub hochgeladen, und Claude soll sie auch nicht lesen dürfen. Dafür habe ich in der settings.json von Claude Code Deny-Regeln für Lesen und Schreiben dieser Datei hinterlegt. Wie das geht, steht im Artikel Claude Code und deine .env-Datei.

Schritt 3: Das Briefing

Ich arbeite nicht nach dem Prinzip „Hier ist mein Briefing, bau mir das mal“ und dann Prompt für Prompt weiter. Dieser Vibe-Coding-Ansatz hat Probleme, die mit der Größe der App wachsen:

• Du hast keine Kontrolle darüber, wie der Agent den Code schreibt. Coding Agents neigen zu Overengineering und blähen die Codebase auf.
• Fehlen Informationen, trifft der Agent Annahmen und baut Funktionen, die du gar nicht wolltest.
• Es gibt kein Kontextmanagement. Der Agent weiß nicht, was das Ziel der App oder einer Funktion ist.

Deshalb beginne ich mit einem ausführlichen Briefing als Markdown-Datei im Ordner docs. Darin stehen Produkt und Ziel, Kernnutzen, verbindliche Entscheidungen wie der Tech-Stack, Zahlungssystem mit Testguthaben, Aufladungen und Abo, Rollen und Zugriffsrechte, das Credit-System und der Ablauf mit der Higgsfield API. Dazu kommt der Hinweis, das Designsystem und den Prototyp aus Claude Design eins zu eins umzusetzen. Die exportierten HTML-Dateien lege ich mit in den Ordner.

Du musst das nicht alles aus dem Kopf wissen. Bitte Claude, dir gezielt Fragen zu stellen, bis das Briefing vollständig ist.

Schritt 4: Projekt initialisieren und Features planen

Zuerst lasse ich Claude das Projekt mit dem GitHub-Repository verknüpfen:

Bitte verknüpfe dieses Projekt mit folgendem GitHub-Repository: [Adresse deines Repositorys]

Claude verknüpft das Projekt und lädt den Ausgangsstand hoch.

Dann starte ich die Initialisierung meines Frameworks. Die ist nicht zu verwechseln mit dem eingebauten /init von Claude Code, das eine CLAUDE.md anlegt. Mein Initialisierungsschritt nimmt Briefing und Designsystem und zerlegt die Projektidee in einzelne Features. Statt alles auf einmal zu entwickeln, entsteht die App Stück für Stück.

Dabei interviewt mich Claude zum Briefing, zum Beispiel: „Wie viele Marken hat ein Team?“ (Antwort: eine) oder „Was soll das Studio im MVP erzeugen?“ (Bilder und Videos). Heraus kommt eine Feature-Roadmap mit IDs, unter anderem:

• Konto und Team-Onboarding
• App-Grundgerüst und Navigation
• Teamverwaltung und Einladungen
• Markenbasis und Brand Library
• Credit-Wallet und Generierungsaufträge
• Creative Studio und Ergebnisansicht
• Anbindung der Higgsfield API
• Aufladungen und Pro-Abo

Dazu liefert Claude eine Build-Reihenfolge, weil Features voneinander abhängen, einen ersten Entwurf des Datenmodells mit den nötigen Tabellen und das App-Grundgerüst mit allen Menüpunkten. Außerdem hat der Schritt die lokale Supabase in Docker eingerichtet und gestartet. URL und Key für die lokale Datenbank trage ich selbst in die .env.local ein.

Damit Claude jederzeit weiß, wo das Projekt steht, gibt es einen Features-Ordner mit einem Status pro Feature. Ohne diese Dokumentation muss sich Claude den Stand immer wieder aus dem Code zusammensuchen, und das wird mit wachsendem Projekt kritisch. Nach jeder Phase mache ich außerdem einen Commit, also einen Speicherpunkt in Git.

Schritt 5: Ein Feature von der Spezifikation bis zum Test

Jedes Feature durchläuft dieselben Phasen. Am Beispiel „Konto und Team-Onboarding“:

Spezifikation. Claude interviewt mich zum Feature und schreibt dann ein Anforderungsdokument mit User Stories, einem Abschnitt „nicht im Umfang“ und vor allem Akzeptanzkriterien mit IDs. Ein Beispiel:

Angenommen, eine Person ist abgemeldet. Wenn sie auf /signup eine gültige E-Mail-Adresse und ein Passwort mit mindestens 10 Zeichen eingibt und das Captcha besteht, dann wird ein Konto angelegt und sie sieht den Hinweis, dass ein Bestätigungslink an ihre E-Mail-Adresse geschickt wurde.

Das wirkt ausführlich, verhindert aber Lücken. Claude und du können jedes Kriterium überprüfen.

Architektur. Das technische Design legt fest, welche Seiten, Routen, Zugangsregeln und Komponenten es braucht, verfeinert das Datenmodell und dokumentiert technische Entscheidungen.

Aufgabenplan. Aus Spezifikation und Architektur entsteht eine Checkliste in Ebenen: Datenbank und Grundlagen, Serverbausteine, Seiten, Absicherung und Feinschliff. Aufgaben, die parallel laufen können, sind markiert. Dafür startet Claude Subagents.

Umsetzung. Vorher legt Claude einen eigenen Feature-Branch an, damit der funktionierende Hauptcode unberührt bleibt. Dann entwickelt er nach Plan.

Qualitätssicherung. Ein unabhängiger Agent schreibt Tests, prüft das Ergebnis gegen die Akzeptanzkriterien und erstellt einen Testbericht. In meinem Durchlauf liefen dabei drei Agents parallel.

Danach teste ich selbst: Konto anlegen, Bestätigungsmail im lokalen Mail-Testtool Mailpit öffnen, Team und Marke anlegen. Feature 1 funktioniert.

Mit diesem standardisierten Ablauf lassen sich die weiteren Features weitgehend automatisiert entwickeln, bei erwartbarer Qualität. So bin ich bis zur Higgsfield-Anbindung gekommen. Den Einstieg in Next.js, Supabase und Hosting beschreibe ich ausführlicher in Claude Code für Einsteiger: deine erste Web-App.

Schritt 6: Die Higgsfield API anbinden

Auch die API-Anbindung ist ein eigenes Feature mit Spezifikation. Ein Akzeptanzkriterium daraus, sinngemäß: Ist der echte Anbieter aktiv und ein freigegebenes Bildmodell gewählt, wird ein gestarteter Auftrag bei Higgsfield erzeugt, das Ergebnis gespeichert, die Variante auf „fertig“ gesetzt und der Auftrag genau einmal abgerechnet.

Ohne dass ich es angewiesen hatte, hat Claude die Higgsfield-Dokumentation abgerufen und zusammengefasst: welche Endpunkte es braucht und welche Bild- und Videomodelle verfügbar sind.

Die Architektur gliedert die Anbindung in Blöcke:

• Anbieterschnittstelle
• Modellkatalog und Modellauswahl im Studio
• Fortschrittsanzeige eines Auftrags
• Wiederholung fehlgeschlagener Aufträge
• Übernahme der Ergebnisse in die eigene App
• Betreiberprotokoll

Vorgelegt wurden mir auch Entscheidungen, etwa welche Modelle angeboten werden. Für Video habe ich Kling und Seedance gewählt.

Testen mit echtem API-Key

Vor der eigentlichen Umsetzung prüft Claude die Verbindung mit dem echten Key und schlägt eine Testgenerierung für ein Bild und ein Video vor, inklusive Preisangabe. Der erste Versuch scheiterte mit dem Fehler 403 not enough credits: Mein Guthaben war nicht aufgeladen. Lade also vor dem Testen Guthaben auf.

Danach habe ich Claude den Test mit einer Einschränkung wiederholen lassen:

Bitte teste Higgsfield erneut. Beschränke deinen Test auf einen geringen Credit-Verbrauch.

Das Bild war sofort fertig, das kurze Video brauchte rund 3 Minuten. Dabei fiel auf, dass die Ergebnisse von einem eigenen Host ausgeliefert werden. Den musste ich als zusätzliche Variable in der .env.local eintragen, sonst hätte die App die Generierung blockiert.

Der Test in der fertigen App

Im Creative Studio habe ich ein Produktvideo im Querformat angelegt, 6 Sekunden, 720p, mit Seedance. Als Prompt diente eine kurze Beschreibung der Kaffeemarke plus die Markenfarben, dazu Referenzbilder aus der Brand Library. Eigentlich gehören die Farben in die Markenbasis der App, ich habe sie hier abgekürzt direkt in den Prompt kopiert.

Die App zeigte vorab die Kosten an und zog sie beim Start direkt vom Team-Guthaben ab. Das Ergebnis war ordentlich, mit Luft nach oben. Anschließend habe ich noch ein quadratisches Social-Media-Bild in 1K generiert.

Die Rechnung: Was hat das gekostet?

Alle Zahlen stammen aus meinem Testlauf. Modellpreise, Credit-Umrechnungen und Konditionen legt der Anbieter fest, sie können sich jederzeit ändern. Prüf die aktuellen Preise immer in der Konsole oder auf der Preisseite.

Die Konsole zeigt jede Anfrage, den Verbrauch pro Modell und die genutzten Modelle. So behältst du die Einkaufsseite im Blick.

Wo die Marge entsteht

Die Credit-Preise in meiner App hat Claude so vorgeschlagen, dass sie grob beim Doppelten der Anbieterkosten liegen. Den Vorschlag habe ich übernommen. Ob das reicht, hängt davon ab, was ein Credit bei dir in Euro kostet, und diesen Preis habe ich im Test noch nicht festgelegt. Eine fertige Gewinnrechnung pro Video lässt sich daraus also noch nicht ablesen.

Beachte bei deiner Kalkulation: Von deinem Credit-Preis gehen noch Zahlungsgebühren, Hosting, Speicher und die Kosten für fehlgeschlagene oder wiederholte Generierungen ab. Ein Faktor 2 auf die reinen Modellkosten ist kein Faktor 2 auf den Gewinn.

Die Risiken des Geschäftsmodells

API-Arbitrage ist ein legitimes Modell, aber kein Selbstläufer. Diese Punkte solltest du vorher durchdenken:

• Abhängigkeit vom Anbieter. Preise, verfügbare Modelle und Bedingungen bestimmt der API-Anbieter. Steigen die Preise, schrumpft deine Marge sofort. Deine Credit-Preise sollten sich deshalb ohne neue Programmierung anpassen lassen.
• Leicht kopierbar. Eine Oberfläche über einer API kann jeder nachbauen, auch mit Claude Code. Dein Vorteil muss im Nischenfokus und im Workflow für eine bestimmte Zielgruppe liegen, nicht im Modellzugang.
• Asynchrone Abläufe. Ein Video dauert Minuten. Deine App muss Fortschritt anzeigen, Fehler abfangen, Aufträge wiederholen und darf trotzdem nur einmal abrechnen.
• Kostenkontrolle. Jede Generierung kostet dich echtes Geld. Das Credit-System muss serverseitig sauber abrechnen, und dein API-Key darf nie im Browser landen.
• Fehlende Bausteine vor dem Livegang. Im Test fehlten noch die Stripe-Anbindung, Datenschutz und weitere Punkte für den Livebetrieb. Hochgeladene Markenassets sind Kundendaten, entsprechend sorgfältig musst du mit ihnen umgehen.

Einordnung: Vom Prototyp zum verkaufbaren Produkt

Technisch ist eine eigene KI-Video-Plattform heute erstaunlich schnell entwickelt. Für die komplette Bild- und Videogenerierung reicht ein einziger API-Key, abgerechnet wird nach Verbrauch. Die eigentliche Arbeit liegt woanders: in einer Nische mit echtem Bedarf, in einer tragfähigen Credit-Kalkulation und in einer App, die Zahlungen, Daten und Fehler zuverlässig handhabt.

Genau deshalb habe ich nicht einfach drauflos gepromptet, sondern jedes Feature mit Spezifikation, Architektur, Aufgabenplan, Umsetzung und unabhängiger Qualitätssicherung entwickelt. Für ein Produkt, das Geld von echten Kund:innen annimmt, brauchst du einen strukturierten Entwicklungsprozess, in dem nachvollziehbar dokumentiert ist, was gebaut wurde und warum.