Posting this from Nouméa (New Caledonia), currently here for work. Big timezone gap with most of you, so apologies if I'm a few hours behind on replies. Happy to answer any questions about the stack, the SEO disaster, the bot detection, or anything else 🌊
I'll be honest, I almost didn't write this post. There's a glut of "I built X in Y months" articles on DEV right now and most of them follow the same arc: developer has idea, ships fast, "lessons learned" in 5 bullet points, plug at the end. I don't want to do that.
What I want to do is talk about the parts that aren't on my landing page. The architectural decision I regret. The week I almost killed my SEO by being too clever. The moment I realized I'd been optimizing the wrong thing for a month.
So if that sounds useful, stay. Otherwise the back button is right there.
What I'm actually building
It's called AI Explorer. It's a directory of AI tools — comparisons, FAQ, use cases, alternatives, the usual — with a 4-tool side-by-side comparator and 37 thematic categories. The angle is that it's bilingual (French and English) and built from a French perspective, which sounds like a footnote until you realize that 95% of comparable platforms are US-centric and translate their content with Google Translate when they bother at all.
I started it because I kept hitting the wall of "alternative française à ChatGPT" and getting served either nothing useful or content farms. Six months later I have 1,424 tools indexed across categories ranging from the obvious (chatbots, image generation) to the unexpected (AI tools for legal, real estate, immigration, energy management). The tooling for indie hackers and solo founders sits right next to the niche stuff because that's how directories should work — long tail matters.
The backend choice that everybody questions
Kotlin + Ktor for the backend. Yes, I know.
The reaction I get every time:
- "Why not Node? You'd have one language."
- "Why not Go? Faster, simpler."
- "Why not Python? Everyone in AI uses Python."
The boring answer is that I've been writing Kotlin for years professionally, I'm productive in it, and I know its sharp edges. The slightly better answer is that Ktor with Exposed ORM and HikariCP gives me a level of type safety and concurrency control that I genuinely struggled to match in Node when I prototyped both. Coroutines are kind of magical when you've got a pipeline that fans out to enrichment APIs, image processing, and DB writes simultaneously.
The honest answer is that I picked it on day one and never looked back. Sometimes the right tech is the one you'll actually ship with.
For the record: PostgreSQL with Flyway for migrations, JVM tuned with -Xms1g -Xmx3g -XX:+UseG1GC running in Docker on an OVH VPS with about 24GB of RAM and 8vCores. It costs me roughly 24 euros a month to host. Could be cheaper. Could also be on Vercel for 200 a month. Pick your poison.
Honestly though, what I really want is to ditch hosted AI APIs altogether and run everything locally on a beefy dedicated server with a proper GPU. Mistral, Qwen, Llama variants — full self-hosted, no platform risk, no rate limits. I've been pricing OVH dedicated boxes (Ryzen + 64GB + 4090-class GPU) for months. The cost makes me wince every time. We're talking 200-400 euros a month, before revenue justifies it.
And this is where I have to admit something: I'm a hardware nerd. I love big machines I can manage myself. SSH into the box, monitor the metrics, tune the JVM, watch the GPU utilization climb under load — that's not a chore for me, that's the fun part. Which makes the decision genuinely hard. The rational founder in me says "wait until the numbers justify it". The hardware enthusiast in me says "you know you'd love it, just do it". Most of the time the rational founder wins. Most of the time.
But it's where this is going. Eventually.
The Next.js trap I fell into
Next.js App Router. I love it. I also hate it. Sometimes in the same hour.
Here's the trap I fell into and that nobody really warns you about: the App Router makes it really tempting to do everything server-side, fetch data inside server components, and render. Beautiful in dev. Then you push to production and realize that every page request hits your backend API for fresh data, and your TTFB goes from "fine" to "embarrassing" because you didn't properly think about caching strategy.
I spent two weekends figuring out the right mix of revalidate, ISR, and edge caching at the Cloudflare level. The thing nobody tells you is that the Next.js docs make it sound simple, but the moment you have a real-world combination of "this page changes daily, this one weekly, this one only when the user creates content", you're suddenly architecting a cache invalidation system. And we all know what they say about cache invalidation.
What I wish I'd known: spend a half-day mapping out your data freshness requirements per route type before you start. It will save you weeks.
The SEO disaster I created myself
This is the part that hurts.
About three weeks ago, I had a feature called "LLMs page" — basically a page per LLM model imported from HuggingFace. It made sense conceptually but it became 3,000 thin pages that were polluting my index. I decided to kill the feature.
I'm experienced enough to know to send 410 Gone, update the sitemap, clean robots.txt. Did all that. What I didn't anticipate was the ripple effect on Google's perception of my domain. The 7,500 indexed pages I had at peak dropped to 954 in two weeks, because Google was busy purging the deleted content faster than it was discovering my actual product pages.
For a few days I genuinely thought I'd been penalized. Spent an embarrassing amount of time refreshing Search Console at 2am. Eventually I figured out it was just the natural consequence of removing 40% of my content surface in a domain that was already in evaluation mode. Patience is the actual answer, but patience is hard when your traffic graph looks like a cliff.
The lesson I keep relearning: SEO is the slowest feedback loop in software, and yet it's the one I'm most tempted to obsess over. Checking Search Console daily fixes nothing. The data only becomes meaningful at the weekly or monthly scale. Knowing this and acting on it are two very different things.
The content quality problem I think about a lot
Here's a question I keep wrestling with.
The top 50 tools on the directory — Claude, ChatGPT, Cursor, Midjourney, etc. — have descriptions, FAQs, use cases, and alternatives that I've written and refined personally. I read the docs, I tested the products, I formed opinions. I'd defend these pages to anyone.
For the long tail, I've built an enrichment pipeline using Mistral that generates structured content (descriptions, FAQs, categorized use cases) from the official sources of each tool. Every output passes a validation step before it goes live: structured prompts, schema enforcement, rejection of anything that doesn't meet a quality threshold. The result is content that's factually grounded, properly bilingual (not auto-translated), and substantially better than the typical scraped-and-templated approach you see on most directories. I sample-check regularly and I'm comfortable with what's published.
That said, I'm honest with myself: pipeline-generated content, even when good, isn't the same as content I've personally written. Both have a place. The pragmatic position is that nobody can manually curate 1,400 tools solo, and well-engineered automated content beats either no content or shallow human-written content. The principled position is that the tools my readers care about most deserve the human treatment.
So my approach is to work backwards from the head: every week I take 5 tools from the top of the funnel and rewrite them properly. The directory's value isn't in being complete, it's in being trustworthy where it matters.
The taxonomy problem nobody talks about
Here's a problem I underestimated by an order of magnitude: how do you categorize 1,400+ tools when half of them straddle multiple categories?
Is Cursor a "Code/Dev" tool or a "Productivity" tool? Both, obviously, but I have to pick one for the canonical category. Is a tool that generates marketing copy with a chat interface a "Chatbot", a "Marketing" tool, or a "Writing" tool? The honest answer is "all three", but a directory needs a primary path or your nav becomes incoherent.
I currently have 37 categories. Some are healthy (150 tools in Code/Dev, 355 in AI Agents — that one exploded). Some are sad (1 tool in Energy, 2 in Pet Care, 4 in Smart Home). I keep going back and forth between "merge the small ones into bigger buckets" and "leave them as discoverable niches because that's where long-tail SEO lives". I don't think there's a clean answer here. Right now I lean toward consolidating anything below 6 tools into broader buckets — but every time I do, I lose the specificity that made the directory useful in the first place.
If anyone has experience with this on a similar scale, I'd love to compare notes.
On the AI infrastructure choices
Quick note since people always ask: my enrichment pipeline runs on Mistral, which I picked specifically because it's a French model with strong multilingual capabilities and excellent French output quality. For a bilingual directory targeting French speakers first, that's not a small detail — using a US-centric model gives you content that "feels translated" even when it's grammatically correct. Mistral handles French as a first-class language, not as a translation target.
The pipeline isn't just "send prompt, save response". There's structured output enforcement (JSON schema), validation against the source data, language consistency checks, and a rejection pipeline for outputs that don't meet quality bars. Roughly 9,000 successful calls per month make it through. The ones that don't get manual treatment.
If Mistral ever changes their pricing or capabilities significantly, my plan B is a self-hosted Ollama instance with a French-tuned model on a beefier server. I've already prototyped it. The output quality is close, but Mistral's hosted models still have the edge for now.
This kind of "AI infrastructure planning" is, I think, going to be one of the defining skills for indie builders in the next few years.
The bot defense layer I built (because I had to)
While we're talking about infrastructure, here's another thing I built that I'm probably too proud of.
Running a directory means you become a magnet for scrapers. Within weeks of going live I had bots hitting the API in patterns that were obviously not human: 50 requests per second from rotating IPs, user-agents that pretended to be Chrome but missed every single secondary header, full-site crawls hitting URLs in alphabetical order at 3am.
I didn't want to outsource this entirely to Cloudflare's managed rules — partly because I wanted granular control, partly because (let's be honest) I find this kind of problem fun to solve. So I built a detection layer in the Ktor backend that scores incoming requests against a set of behavioral signals: request frequency per IP, header consistency, navigation patterns, time-of-day distribution, divergence from real-user baselines. When the score crosses a threshold, the backend automatically generates a custom Cloudflare WAF rule via their API and pushes it. The rule blocks or challenges the offending range, and the event is logged for review.
Is it overkill for a directory at my scale? Probably. Did it cut my server's wasted CPU cycles by something like 40% the first week it ran? Yes. Was it deeply satisfying to build? Also yes. Some problems are worth solving even when buying the off-the-shelf solution would be more rational.
This is the kind of thing that doesn't show up on a landing page or in a pitch deck. It's just infrastructure work that quietly makes everything else better. And honestly, it's part of why I do this.
The community layer most directories skip
Most AI tool directories are read-only. You land on a tool page, you read the description, maybe you check pricing, you leave. There's no place to ask "does this work for X use case?" or "anyone tried it for Y?" — and that's a missed opportunity, because those are the questions that actually matter when you're picking a tool.
So I built a discussion layer on top of every tool page. Users can open threads, ask questions, share their experience, push back on something I wrote in the description. Each tool has its own dedicated forum-style space. It's not a comment section bolted on at the end — it's a proper structured conversation with topics, replies, and persistence.
Right now it's mostly empty. Same chicken-and-egg problem as reviews: communities don't form without traffic, and traffic finds communities once they exist. I'm okay with that. The infrastructure is in place, the moderation tooling is in place, and when a critical mass of users arrives, the conversations will follow. Building the community layer before having the community feels backwards, but it's the only order that actually works — you can't bolt this on later without breaking trust.
The deeper bet I'm making: a directory that lets users genuinely discuss tools is qualitatively different from one that just lists them. It changes the value proposition from "here's a catalog" to "here's where the conversation happens". I don't know if it'll pay off. I think it will.
What I'd do differently
A few real ones, not the polite kind:
I'd start the SEO work earlier. I built the product first and thought about SEO later, which is the most classic developer mistake there is. Robots.txt, canonical URLs, sitemap structure, hreflang for the bilingual setup — all of this should have been in place from day one. Retrofitting it is painful.
I'd be more skeptical of auto-generated taxonomy. Tags felt like a cheap win. Build SEO traffic on long-tail tag pages, win. Except the auto-generated taxonomy produced 200+ tags including absolute gems like "willingness-to-pay" and "form-replacement", and Google rightfully flagged most of those pages as thin content. Lesson: every auto-generated structural element will eventually need manual curation. Generated content needs human-defined boundaries to stay useful.
I'd accept earlier that the chicken and egg of reviews has no clean solution. I waited months for "real" user reviews to materialize. They won't, not until I have traffic, and I won't have traffic without reviews. The actual answer is editorial reviews ("AI Explorer's take") on top tools, owned and signed by me. I should have started that on day one.
I'd talk to users earlier. I built a lot of features I thought were obvious. A 4-tool side-by-side comparator. Detailed alternatives pages. Sister blog integration. Some of these get used heavily; others I'm not sure anyone has touched. I should have shown a wireframe to ten people in week one instead of shipping multiple features in month four.
What's next
A few things, in vague priority order:
Editorial reviews on the top 100 tools. This is the chicken-and-egg solution to the no-reviews problem.
Real screenshots instead of just official logos. This is the kind of detail that distinguishes a directory you trust from one you don't.
Consolidating the long tail of categories. Or not. Still arguing with myself about it.
The monetization layer is already live, which is something I'm cautiously proud of. There are paid premium listings, time-limited spotlight boosts (9 to 25 euros), accelerated submission, enriched listings — the full toolkit for tools that want visibility on a French-speaking platform. The unit economics make sense in theory. In practice, premium revenue scales with traffic, and traffic is the bottleneck right now. So the strategic question isn't "should I build B2B features?" — that's done. It's "how fast can I grow the audience that makes those features actually valuable to advertisers?"
Which loops back to everything else in this article: SEO, reviews, content, patience.
The unfinished thought
Six months in, I'm not sure if I've built a real business or a really detailed hobby. I don't think that's a question I'll be able to answer for at least another year. But I've shipped something that didn't exist before, in two languages, on infrastructure I control, with a working monetization model, and I learned a stupid amount along the way.
If you're building something similar — directory, comparison platform, AI-adjacent content product — I'd genuinely love to compare notes. Drop a comment. The thing I crave most as a solo builder, more than traffic, more than features, is conversation with people who are wrestling with the same trade-offs.
If you found anything in here useful, that makes the writing worth it. And if not — well, the back button is still there. No hard feelings.
— Nicolas, AI Explorer
Top comments (0)