Shipping Tool Index Solo With SvelteKit And Meilisearch

Most directory sites are useless the moment your catalog grows past a screen of links. The data is there, but you cannot find anything, so the visitor bounces and the work was wasted. I kept running into that as a user, and when I decided to build my own AI and SaaS tool directory, the first decision I made was that the search had to be good before anything else mattered. That one constraint shaped the whole project.

Tool Index is a directory of AI and SaaS tools that I built and run solo. It holds roughly 197 tools today, each with categories, a set of curated alternatives, and an original long-form description. There is a blog and a generated sitemap with hundreds of URLs. You can see the live product at Tool Index. This post is about how I scoped it, because the scoping decisions are the part that travels to your own work, not the specific tools I picked.

Make Search The Core UX, Not A Feature

A directory lives or dies on whether people can find the right tool fast. If I cannot type three letters and land on the thing I want, every other feature is decoration. So I treated search as the spine of the build rather than a box in the header I would polish later.

That meant Meilisearch over a SQL LIKE query against Postgres. The difference is what the user feels. Meilisearch gives you instant results as you type and typo tolerance out of the box, so someone searching for a tool whose name they half remember still finds it. A misspelled query that would return nothing from a naive database lookup returns the right result here. For a directory that is not a nice to have, it is the entire reason the site is worth visiting over a search engine.

The architecture follows from that priority. Postgres is the source of truth for every tool, its description, its category, and its alternatives. Meilisearch is the search index built from that data, tuned for the front end query path. SvelteKit serves the pages and talks to the index. The split matters because it keeps each piece doing one job well. Postgres handles durability and relationships. Meilisearch handles the thing users actually do all day, which is type and expect an answer in milliseconds. When you let your primary database moonlight as your search engine, you usually end up with slow queries and a worse experience, and you rewrite it under pressure later anyway.

The lesson is to find the one interaction your product lives or dies on, then build the rest of the stack in service of it. For a directory that interaction is search. Name yours, then refuse to treat it as a feature you will get to.

Why Original Content Is The Moat

Search is the core experience, but search alone does not defend a directory. Anyone can scrape a list of tools and slap a search box on it. What makes the thing hard to copy is the content underneath, and that is where I spent the real effort.

Every tool on Tool Index has a long, original description written specifically for that entry. Not a marketing blurb lifted from the vendor, not two sentences of filler. A real explainer of what the tool does, who it is for, and how it compares. On top of that, each entry carries a curated set of alternatives, so a visitor who lands on one tool has somewhere useful to go next. That web of descriptions and alternatives is the asset. It is what search engines index, what gives a visitor a reason to stay, and what a competitor cannot reproduce in a weekend.

This is the part solo builders skip because it is slow and it does not feel like engineering. It is tempting to ship a thin catalog of names and URLs and call the data layer done. But a thin directory has no defensibility and no reason to exist next to a generic search engine. The content is the product. The code is the delivery mechanism.

So the honest split of effort on a content product like this is roughly inverted from what it feels like it should be. The interesting engineering, the search index, the page rendering, the sitemap generation, is a smaller share of the total work than the unglamorous job of producing depth on every single entry. I made peace with that early. If you are planning a directory, a knowledge base, or any catalog product, budget for the content as the main line item, not as the thing you backfill after launch.

Ship The Smallest Thing That Is Actually Useful

The trap with a content product is that the catalog feels infinite, so you keep delaying launch until it is "complete". It is never complete. I avoided that by drawing a hard line, ship the smallest version that is genuinely useful, then grow the catalog from there.

Genuinely useful is the load bearing phrase. It does not mean a placeholder. It means a coherent slice where the search works, the descriptions are real and long-form, the categories make sense, and the alternatives connect entries into something a visitor can actually browse. A smaller catalog where every entry is excellent beats a huge catalog of stubs every time, because the stubs poison trust. One thin entry teaches a visitor that the whole site is thin, and they leave.

So the first version was deliberately narrow on breadth and uncompromising on depth. The search had to be instant and typo tolerant from day one. Each tool that made the cut had its full description and its alternatives. Anything that could not meet that bar simply was not in the first release. Then, with a real product live and the pipeline proven, growing from a starter catalog toward roughly 197 tools became a matter of repeating a process I already trusted, rather than a launch blocker.

That ordering is the whole discipline. Prove the experience on a small, excellent slice, then scale the part that scales. The catalog is the easy thing to grow once the hard things, the search quality and the content bar, are nailed down. If you try to grow the catalog before the experience is right, you just multiply a mediocre experience.

How The Pieces Fit On A Small Cluster

None of this needs heavy infrastructure, and I want to be clear about that because solo builders often over provision out of anxiety. Tool Index runs on a small k3s cluster. SvelteKit on the front, Meilisearch as the search service, Postgres as the data store. That is a modest footprint for a product with hundreds of indexed URLs and instant search.

The reason it stays small is the separation of concerns I described earlier. Because Meilisearch owns search, Postgres is not getting hammered with full text queries on every keystroke, so it stays cheap and calm. Because the content is static long-form text rather than something computed per request, the pages render fast and cache well. A generated sitemap with hundreds of URLs and basic analytics rounds it out without adding moving parts, and the paid tier rides on an embedded checkout that grants access from a verified webhook rather than a billing platform bolted onto the side. The architecture is boring on purpose, and boring is what a solo operator can actually maintain alongside everything else.

The takeaway here is that picking the right specialized tool for your core interaction lets the rest of your stack stay simple and small. I did not need a sprawling system. I needed one excellent search engine, one reliable database, and a framework to glue them together.

What I Would Tell Another Solo Builder

If you are about to build a content product alone, the order of operations is the whole game. Search comes first, the content is the moat, and you ship the smallest excellent slice before you grow the catalog. The mistake I see most often is running that order backwards, treating search as a late feature and content as filler while chasing catalog size the experience has not earned yet. Get the order right and a one person team can ship a directory that holds up instead of a pile of links nobody can navigate.

I build things like this for clients, full-stack apps, AI agents, and automation pipelines, usually shipped faster than expected because I work with AI tooling every day. If you want something built, book a call.