Wie ich eine KI-Tools-Datenbank in Kotlin und Next.js solo entwickelte

Nach einem halben Jahr harter Arbeit steht die Plattform endlich – doch die Reise war voller Stolpersteine, die niemand in einem schnellen "Lessons Learned" zusammenfasst. Von fragwürdigen Backend-Entscheidungen über Next.js-Fallen bis hin zu einem SEO-Desaster, das mich nächtelang an der Google Search Console verzweifeln ließ: Hier sind die echten Erfahrungen hinter dem fertigen Produkt.

Ein multilinguales Projekt mit klarem Ziel

Die Idee zu AI Explorer entstand aus einem ganz persönlichen Problem: Wieder und wieder suchte ich nach französischen Alternativen zu US-dominierten KI-Tools – doch die Ergebnisse waren oft unbrauchbar oder automatisch übersetzte Massenware. Also baute ich eine Plattform, die speziell auf frankophone Nutzer zugeschnitten ist, mit Inhalten in Französisch und Englisch. Heute umfasst die Datenbank über 1.400 KI-Tools, geordnet in 37 Kategorien – von klassischen Chatbots bis hin zu Nischenanwendungen wie KI für Rechtsberatung oder Energiemanagement.

Das Besondere? Die Plattform ist nicht nur mehrsprachig, sondern auch aus einer nicht-amerikanischen Perspektive entworfen. Während die meisten vergleichbaren Verzeichnisse ihre Inhalte mit Google Translate übersetzen, setzt AI Explorer auf native Texte und kulturelle Anpassungen. Die Zielgruppe reicht von Solo-Gründern bis zu Entwicklern, die nach spezialisierten Lösungen suchen – der lange Tail steht hier im Fokus.

Kotlin und Ktor: Warum ich gegen den Strom schwamm

Jedes Mal, wenn ich mein Tech-Stack erwähne, ernte ich dieselben Reaktionen: "Warum nicht Node.js? Dann hättest du nur eine Sprache." oder "Warum nicht Go? Das ist doch viel schneller!" Die Antwort ist simpel: Kotlin mit Ktor ist die Technologie, in der ich seit Jahren produktiv arbeite – und genau das zählt am Ende.

Der Backend-Stack besteht aus:

• Kotlin + Ktor für den Webserver
• PostgreSQL mit Flyway für Datenbankmigrationen
• JVM mit angepassten Einstellungen (-Xms1g -Xmx3g -XX:+UseG1GC)
• Docker auf einem OVH-VPS mit 24 GB RAM und 8 vCores

Die Kombination aus Kotlin-Koroutinen und Ktor ermöglicht mir eine präzise Steuerung von Parallelität – besonders nützlich, wenn Daten gleichzeitig von externen APIs abgerufen, Bilder verarbeitet und in die Datenbank geschrieben werden müssen. Ein Node.js-Prototyp fühlte sich dagegen oft wie ein Gewirr aus Callbacks an.

Doch der größte Vorteil? Ich musste mich nicht neu einarbeiten. Manchmal ist die richtige Technologie einfach die, mit der man vertraut ist – selbst wenn sie nicht der aktuellen Hype-Welle entspricht.

Die Hardware-Frage: Selbsthosting als langfristiges Ziel

Während ich mit dem aktuellen Setup zufrieden bin, träumt ein Teil von mir von einer ganz anderen Architektur: einer vollständig selbstgehosteten Lösung auf einem dedizierten Server mit GPU-Beschleunigung. Die Vision? Alle KI-Modelle lokal laufen lassen – von Mistral über Qwen bis zu Llama-Varianten – ohne Abhängigkeit von externen APIs, ohne Rate-Limits, ohne Plattformrisiko.

Die Realität schlägt jedoch schnell zu Buche. Ein OVH-Dedicated-Server mit Ryzen-Prozessor, 64 GB RAM und einer GPU der 4090-Klasse kostet zwischen 200 und 400 Euro pro Monat – lange bevor die Plattform genug Umsatz generiert, um das zu rechtfertigen. Zwei Stimmen in mir kämpfen ständig:

• Der rationale Gründer sagt: "Warte, bis die Zahlen stimmen."
• Der Hardware-Enthusiast flüstert: "Du weißt doch, wie viel Spaß das machen würde."

Bisher gewinnt meist der rationale Teil. Doch die Idee bleibt – irgendwann wird die Plattform groß genug sein, um diese Investition zu tragen.

Next.js App Router: Die Falle der serverseitigen Daten

Next.js mit dem App Router ist großartig – und gleichzeitig eine der tückischsten Fallen für Entwickler, die Performance ernst nehmen. Der Grund: Es ist verlockend einfach, Daten direkt in Server-Komponenten zu fetchen und die Seite komplett serverseitig zu rendern. In der Entwicklung sieht alles perfekt aus. Doch sobald die Anwendung live geht, schlägt die Realität zu.

Jede Seitenanfrage traf plötzlich mein Backend-API, um frische Daten zu holen. Die Time-to-First-Byte (TTFB) explodierte von akzeptablen Werten auf peinlich langsame Ladezeiten. Die Lösung? Ein komplexes Caching-System mit einer Mischung aus revalidate, ISR (Incremental Static Regeneration) und Edge-Caching auf Cloudflare-Ebene.

Doch hier kommt der Haken: Die Next.js-Dokumentation macht Caching so einfach aussehen, als wäre es ein Knopfdruck. In der Praxis muss man jedoch akribisch planen, welche Daten wie oft aktualisiert werden müssen. Eine Seite ändert sich täglich? Eine andere nur wöchentlich? Und dann gibt es noch Nutzer-generierte Inhalte? Plötzlich wird aus einem einfachen Feature ein komplexes Cache-Invalidierungs-System – und wir alle wissen, wie unberechenbar das sein kann.

Mein Rat für alle, die vor dem gleichen Problem stehen: Nehmt euch einen halben Tag Zeit, um eure Anforderungen an Datenaktualität pro Seitentyp zu dokumentieren. Es wird euch Wochen an Frust ersparen.

Das SEO-Desaster, das ich mir selbst eingebrockt habe

Drei Wochen vor diesem Artikel hatte ich eine Funktion namens "LLMs-Seite" – eine Unterseite für jedes KI-Modell, das ich von Hugging Face importiert hatte. Klingt logisch, oder? Falsch gedacht. Innerhalb kürzester Zeit entstanden 3.000 dünne Seiten, die meine Indexierung bei Google mehr verwässerten als bereicherten.

Also entschied ich mich, die Funktion komplett zu entfernen. Ich wusste genug über SEO, um 410 Gone-Statuscodes zu senden, die Sitemap zu aktualisieren und die robots.txt anzupassen. Doch was ich nicht bedacht hatte, war die Kettenreaktion: Google hatte meine Domain gerade erst in einem Evaluierungsmodus – und als ich 40 % meines Contents löschte, reagierte die Suchmaschine schneller, als neue Inhalte indexiert werden konnten.

Die Folge? Meine Indexierungsrate stürzte von 7.500 Seiten auf nur noch 954 innerhalb von zwei Wochen. Für mehrere Tage glaubte ich ernsthaft, eine Penalty erhalten zu haben. Stundenlang saß ich nachts vor der Google Search Console und aktualisierte verzweifelt die Daten. Erst später verstand ich: Es war kein Algorithmus-Penalty, sondern einfach die natürliche Folge einer radikalen Inhaltsbereinigung.

Die Lehre daraus? Veränderungen an großen Websites brauchen Zeit – und Geduld ist die härteste Lektion von allen.

Fazit: Was bleibt – und was noch kommt

Ein halbes Jahr Arbeit, unzählige Stunden Debugging und mehr als ein "Aha!-Moment", der mich zur Verzweiflung trieb. Doch trotz aller Rückschläge hat sich die Mühe gelohnt: AI Explorer ist heute eine stabile, mehrsprachige Plattform, die eine echte Lücke im Markt füllt.

Die nächsten Schritte? Die Performance weiter optimieren, das Caching-System stabilisieren und – ja – vielleicht irgendwann den Sprung zum vollen Selbsthosting wagen. Denn eines ist sicher: Die Reise ist noch lange nicht vorbei.