Von der Idee zum ersten Prototyp mit der Gemini API – internes Kundenwerkzeug oder Mini-SaaS in einem Tag
SerieGoogle AI / Gemini im Freelancer-Alltag
Teil 13 von 16
Freelancer haben oft Ideen für kleine Tools, die sie selbst täglich nutzen würden – aber die Vorstellung, dafür eine vollständige Produktinfrastruktur aufzubauen, stoppt die meisten. Dieser Artikel zeigt, wie man mit der Gemini API und minimalem Entwicklungsaufwand ein internes Kundenwerkzeug oder eine kleine SaaS-Idee realisiert: von der Idee über das API-Design bis zum ersten lauffähigen Prototypen. Der Aufwand ist kleiner als gedacht, wenn man weiß, wo man anfängt.
Warum Freelancer eigene Tools brauchen
Standardtools passen selten exakt. Das liegt nicht daran, dass die Tools schlecht sind – sie sind auf den größten gemeinsamen Nenner optimiert. Als Freelancer hast du aber sehr spezifische Workflows: deine Kunden haben eigene Anforderungen, dein Stil ist einzigartig, deine Prozesse unterscheiden sich von denen einer Agentur.
Ein eigenes Tool, das genau deinen Ablauf kennt, hat zwei Vorteile. Erstens spart es Zeit, weil es keine Anpassungen braucht. Zweitens ist es ein Wettbewerbsvorteil: Du arbeitest schneller als Mitbewerber, die denselben manuellen Prozess haben.
Und dann gibt es noch eine dritte Dimension: Wenn das Tool gut genug ist, dass andere dafür zahlen würden, hast du ein zusätzliches Einkommensmodell aufgebaut – ohne ein Startup zu gründen.
Der kritische Irrtum ist der Gedanke, dass eigene Tools eine vollständige Produktinfrastruktur voraussetzen. Das tun sie nicht. Ein internes Tool braucht keinen Login, keine Datenbank, keine CI/CD-Pipeline. Es muss nur funktionieren.
Das Minimum Viable Tool: Was braucht man wirklich?
Die minimale Infrastruktur für ein funktionierendes Tool besteht aus drei Teilen:
1. Gemini API als Backend-Logik Die Gemini API übernimmt die eigentliche Arbeit – Text generieren, analysieren, strukturieren, transformieren. Du schreibst keine komplexe Logik, du schreibst gute Prompts.
2. Ein einfaches Frontend Für interne Tools reicht Streamlit – eine Python-Bibliothek, die aus einem Skript eine Weboberfläche macht. Keine HTML-Kenntnisse nötig, keine JavaScript-Infrastruktur. Für externe Tools (wenn andere es nutzen sollen) reicht ein einfaches HTML-Formular mit JavaScript-Fetch-Aufruf.
3. Hosting
Lokal starten: Tool läuft auf deinem Rechner, du nutzt es über localhost. Wenn andere darauf zugreifen sollen, kommen günstige Hosting-Optionen ins Spiel – dazu später mehr.
Was du für einen ersten Prototyp nicht brauchst: Datenbank, Benutzer-Login, Monitoring, automatische Tests, Docker, CI/CD. Das alles kommt irgendwann. Nicht am Tag 1.
Beispiel-Tool 1: SEO-Briefing-Generator
Ein konkretes Beispiel aus der Praxis: Du bekommst ein Thema oder eine URL, und das Tool generiert daraus ein strukturiertes SEO-Briefing – Keyword-Liste, Gliederungsvorschlag, Wettbewerber-Hinweise, Zielgruppen-Beschreibung.
Ohne Tool: Du öffnest ChatGPT oder AI Studio, schreibst einen Prompt, kopierst das Ergebnis in ein Dokument, formatierst es. Pro Briefing: 10 bis 15 Minuten.
Mit Tool: Du gibst das Thema ein, klickst auf „Generieren”, bekommst ein fertig formatiertes Briefing. Pro Briefing: 2 Minuten.
Hier ist der vollständige Code:
import streamlit as st
import google.generativeai as genai
import json
# API Key aus Streamlit Secrets oder Umgebungsvariable
genai.configure(api_key=st.secrets.get("GEMINI_API_KEY", ""))
SYSTEM_INSTRUCTION = """
Du bist ein erfahrener SEO-Analyst. Erstelle für ein gegebenes Thema oder eine URL
ein strukturiertes SEO-Briefing.
Antworte ausschließlich als gültiges JSON-Objekt mit diesen Feldern:
- keywords: Array mit 8-10 relevanten Keywords (Haupt- und Nebenkeywords gemischt)
- gliederung: Array mit H2-Überschriften für den Artikel (5-7 Einträge)
- zielgruppe: Kurze Beschreibung der primären Zielgruppe (2-3 Sätze)
- suchintention: "informational", "navigational", "transactional" oder "commercial"
- wettbewerber_hinweise: Array mit 3 konkreten Tipps, um sich von typischen Artikeln zu diesem Thema abzuheben
Kein Text außerhalb des JSON. Keine Erklärungen.
"""
def generate_briefing(topic: str) -> dict:
model = genai.GenerativeModel(
model_name="gemini-2.0-flash",
system_instruction=SYSTEM_INSTRUCTION,
generation_config=genai.GenerationConfig(
response_mime_type="application/json",
temperature=0.2,
),
)
response = model.generate_content(topic)
return json.loads(response.text)
# Streamlit UI
st.title("SEO-Briefing-Generator")
st.caption("Gibt ein strukturiertes Briefing für ein Thema oder eine URL aus.")
topic = st.text_input("Thema oder URL", placeholder="z.B. 'Headless CMS für Agenturen'")
if st.button("Briefing generieren") and topic:
with st.spinner("Wird generiert..."):
briefing = generate_briefing(topic)
st.subheader("Keywords")
st.write(", ".join(briefing.get("keywords", [])))
st.subheader("Suchintention")
st.write(briefing.get("suchintention", "–"))
st.subheader("Zielgruppe")
st.write(briefing.get("zielgruppe", "–"))
st.subheader("Gliederungsvorschlag (H2)")
for i, heading in enumerate(briefing.get("gliederung", []), 1):
st.write(f"{i}. {heading}")
st.subheader("Tipps gegen die Konkurrenz")
for tip in briefing.get("wettbewerber_hinweise", []):
st.write(f"- {tip}")Starten mit:
pip install streamlit google-generativeai
streamlit run briefing_generator.pyDas öffnet automatisch http://localhost:8501 im Browser. Fertig.
Beispiel-Tool 2: Angebots-Texte aus Stichpunkten
Das zweite Beispiel ist ein klassischer Freelancer-Workflow: Du hast 4 bis 5 Stichpunkte zur Aufgabe, daraus soll ein professioneller Angebotstext in deinem eigenen Stil werden.
Das Besondere: Die System Instruction enthält Few-Shot-Beispiele deiner eigenen Texte. Das Modell lernt nicht nur den Inhalt, sondern auch Satzbau, Länge und Ton. Das Ergebnis klingt nach dir – nicht nach generischem KI-Text.
Diese Version ist als einfaches HTML-Formular mit JavaScript-Fetch-Aufruf gebaut. Sie braucht kein Python, kein Streamlit – nur einen Browser und einen Webserver (oder lokal über file://).
<!DOCTYPE html>
<html lang="de">
<head>
<meta charset="UTF-8">
<title>Angebots-Text-Generator</title>
<style>
body { font-family: sans-serif; max-width: 700px; margin: 40px auto; padding: 0 20px; }
textarea { width: 100%; height: 120px; margin-bottom: 12px; padding: 8px; font-size: 14px; }
button { padding: 10px 20px; background: #1a73e8; color: white; border: none; cursor: pointer; border-radius: 4px; }
#output { margin-top: 24px; white-space: pre-wrap; background: #f5f5f5; padding: 16px; border-radius: 4px; }
</style>
</head>
<body>
<h1>Angebots-Text-Generator</h1>
<p>Stichpunkte zur Aufgabe eingeben (eine pro Zeile):</p>
<textarea id="input" placeholder="- Website-Relaunch für B2B-SaaS-Unternehmen - Astro + Headless CMS - ca. 15 Seiten, kein Shop - Fertig bis Ende Q2"></textarea>
<button onclick="generate()">Text generieren</button>
<div id="output"></div>
<script>
const SYSTEM_INSTRUCTION = `Du bist ein erfahrener Webentwickler-Freelancer.
Schreibe professionelle Angebotsabsätze im folgenden Stil:
Beispiel 1:
Stichpunkte: Website-Relaunch, 10 Seiten, Astro, bis Ende März
Text: Für den Relaunch Ihrer Unternehmenswebsite schlage ich eine Umsetzung mit Astro vor –
ein modernes Static-Site-Framework, das maximale Ladegeschwindigkeit mit einfacher
Inhaltspflege verbindet. Der Scope umfasst 10 Seiten inkl. Startseite, Leistungsübersicht
und Kontaktseite. Fertigstellung bis Ende März ist bei Projektstart Anfang Februar realistisch.
Beispiel 2:
Stichpunkte: E-Commerce-Migration, Shopify zu WooCommerce, 800 Produkte, SEO-Migration
Text: Die Migration von Shopify zu WooCommerce bei 800 Produkten erfordert sorgfältige
Planung – insbesondere für die SEO-Migration: Weiterleitungen, Canonical-Tags und
Structured Data müssen vollständig übertragen werden. Ich übernehme die technische
Umsetzung inklusive Datenimport, Theme-Anpassung und Post-Launch-Monitoring für 30 Tage.
Schreibe jetzt einen Angebotsabsatz für die folgenden Stichpunkte.
Länge: 3-4 Sätze. Ton: direkt, professionell, keine Floskeln.
Nur den Angebotstext, keine Einleitung, keine Erklärungen.`;
async function generate() {
const input = document.getElementById('input').value.trim();
const output = document.getElementById('output');
if (!input) return;
output.textContent = 'Wird generiert...';
const apiKey = 'DEIN_API_KEY'; // In Produktion: nie im Frontend-Code!
const url = `https://generativelanguage.googleapis.com/v1beta/models/gemini-2.0-flash:generateContent?key=${apiKey}`;
const body = {
system_instruction: { parts: [{ text: SYSTEM_INSTRUCTION }] },
contents: [{ parts: [{ text: input }] }],
generationConfig: { temperature: 0.6 }
};
try {
const res = await fetch(url, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify(body)
});
const data = await res.json();
output.textContent = data.candidates?.[0]?.content?.parts?.[0]?.text ?? 'Kein Ergebnis';
} catch (err) {
output.textContent = 'Fehler: ' + err.message;
}
}
</script>
</body>
</html>Die eigene Stimme trainieren
Die Few-Shot-Beispiele in der System Instruction sind der entscheidende Unterschied zum generischen KI-Output. Drei bis vier Beispiele reichen, um Satzbau, Länge und Tonalität zu übertragen. Konkret:
- Nimm 3 bis 4 Angebotstexte, die du in der Vergangenheit geschrieben hast und mit denen du zufrieden bist
- Füge sie als Beispiele in die System Instruction ein (Stichpunkte → fertiger Text)
- Teste mit einem neuen Stichpunkt-Set, ob der Stil passt
- Passe ein bis zwei Beispiele an, bis das Ergebnis stimmt
Das ist keine aufwendige Fine-Tuning-Session. Es sind 15 Minuten Arbeit – und danach generiert das Tool Texte, die klingen, als hättest du sie selbst geschrieben.
Von intern zu extern: Wann wird ein Tool zur SaaS-Idee?
Die Grenze ist einfach: Ein Tool wird zur SaaS-Idee, wenn andere dafür zahlen würden. Nicht wenn du denkst, dass sie es tun würden – sondern wenn du drei Personen fragst und mindestens eine sagt: „Was kostet das?”
Bevor du über Hosting, Login und Abrechnung nachdenkst, mach diesen Test. Die meisten Tool-Ideen bleiben intern – und das ist völlig in Ordnung.
Hosting-Optionen
Wenn das Tool für andere zugänglich sein soll, gibt es mehrere Optionen:
| Plattform | Stärken | Geeignet für |
|---|---|---|
| Cloudflare Workers | Günstig, global, Edge-Netzwerk | Einfache API-Wrapper, statische Tools |
| Railway | Einfaches Deployment, unterstützt Python | Streamlit Apps, FastAPI-Backend |
| Render | Ähnlich Railway, Free Tier vorhanden | Kleine APIs, erste externe Tools |
| Cloud Run (GCP) | Skaliert auf 0, Container-basiert | Wenn du ohnehin auf GCP bist |
Für ein Streamlit-Tool ist Railway die einfachste Option: Repository verknüpfen, requirements.txt hinzufügen, fertig.
Wann braucht man Login?
Erst wenn mehr als drei Personen das Tool nutzen. Vorher ist Auth-Overhead, der vom eigentlichen Produkt ablenkt.
Eine pragmatische Zwischenlösung: HTTP Basic Auth oder ein einfaches eingebettetes Passwort im Frontend. Das ist kein echtes Security-Feature, aber es hält Crawler und Zufallsbesucher fern.
Echtes Auth (OAuth, JWT, Session Management) kommt dann, wenn du weißt, dass das Tool wächst.
Kosten kalkulieren
Bevor du Preise festlegst, musst du die API-Kosten kennen. Gemini 2.0 Flash kostet Stand April 2026 etwa 0,10 USD pro Million Input-Token und 0,40 USD pro Million Output-Token. Ein typischer Briefing-Generator-Aufruf verbraucht etwa 500 Input-Token und 400 Output-Token.
Beispielrechnung für das SEO-Briefing-Tool:
- 500 Input-Token: 0,00005 USD
- 400 Output-Token: 0,00016 USD
- Gesamt pro Aufruf: ~0,00021 USD
Selbst bei 1000 Aufrufen pro Monat sind das 21 Cent API-Kosten. Hosting kostet mehr. Das bedeutet: Bei einem Preis von 9 EUR pro Monat hast du ab dem ersten zahlenden Nutzer eine positive Marge – und das ist der Punkt, wo eine Idee interessant wird.
Typische Fehler beim ersten Tool
Zu komplex von Anfang an. Der häufigste Fehler: Statt eines einfachen Prototypen wird ein vollständiges System entworfen – mit Datenbank, Benutzerrollen, Exportfunktionen und API-Dokumentation. Nichts davon braucht man am Tag 1. Baue das Minimum, das die Kernaufgabe löst.
Kein Rate Limiting. Wenn ein Tool extern zugänglich ist und kein Rate Limiting hat, kann jemand in einer Minute tausende API-Aufrufe auslösen – absichtlich oder durch einen Bug. Beim ersten externen Tool: Budget-Alert in Google Cloud einrichten, und wenn möglich, einen einfachen IP-basierten Counter ergänzen.
Kein Feedback-Mechanismus. Ein internes Tool, das nur du nutzt, braucht keines. Sobald andere es nutzen, fehlt dir ohne Feedback-Kanal das Wissen, was funktioniert und was stört. Ein einfaches Textfeld „Feedback” reicht.
Direkt bauen statt erst validieren. Bevor du Code schreibst: Zeig die Idee drei Personen aus deiner Zielgruppe. Nicht das fertige Tool – die Idee. Eine Skizze, ein Screenshot aus AI Studio. Wenn niemand begeistert reagiert, ist das ein Signal. Wenn alle sofort fragen „wann ist das fertig?”, ist das auch ein Signal.
Woran du merkst, dass aus einem Tool ein Produkt wird
Ein internes Tool darf roh sein. Es darf Kanten haben, nur für deinen Workflow funktionieren und an genau deinen Annahmen hängen. Ein Produkt darf das nicht mehr.
Der Übergang beginnt meist früher als gedacht. Nicht erst bei Login und Abo, sondern in dem Moment, in dem andere Menschen sich darauf verlassen. Ab dann entstehen Anforderungen, die mit dem eigentlichen Prompt wenig zu tun haben:
- verlässliche Verfügbarkeit
- nachvollziehbare Fehler
- Versionsklarheit bei Output und Eingaben
- Datenschutz und Zugriffskontrolle
- Supportaufwand bei Missverständnissen
Das ist der Punkt, an dem viele “kleine SaaS-Ideen” schwerer werden als erwartet. Nicht wegen der Modellkosten, sondern wegen allem drum herum. Genau deshalb ist die sauberste Reihenfolge: erst internes Werkzeug, dann validierter externer Nutzen, dann Produktdenken. Wer diesen Schritt unterschätzt, hat oft kein Modellproblem, sondern ein Betriebsproblem.
Einordnung
Ein eigenes Tool ist keine große Investition, wenn der Scope stimmt. Ein Nachmittag reicht für einen funktionierenden ersten Prototypen – wenn du nicht versuchst, sofort alles zu bauen.
Der Schlüssel ist die Sequenz: Erst validieren (AI Studio), dann implementieren (Streamlit oder einfaches HTML), dann skalieren (Hosting, Auth, Abrechnung). Wer diese Reihenfolge umkehrt, baut oft das Richtige zur falschen Zeit.
Die Gemini API ist dabei der günstigste Teil des Stacks. Die Kosten für einen Prototypen liegen im Cent-Bereich – das Risiko ist minimal, der mögliche Nutzen hoch.
Im nächsten Artikel dieser Serie geht es um die Realität: was Gemini API wirklich kostet, welche Limits in der Praxis zählen, und wie man Token-Verbrauch und Kosten sinnvoll unter Kontrolle hält.