How We Built VattheBest — The Technical Story

Building a directory site sounds simple. List tools, add search, done. In practice, the data problem is harder than the engineering problem. Here's how we built VattheBest and what we learned.

The stack

Next.js 16 with App Router. Server components for everything data-heavy, client components only where we need interactivity (upvotes, search autocomplete, forms). This gives us fast initial page loads with minimal JavaScript shipped to browsers.

PostgreSQL + Prisma. We considered Supabase and MongoDB. Went with plain PostgreSQL because the data is relational (tools have categories, tags, clicks) and Prisma gives us type-safe queries without writing SQL. No regrets — the schema has evolved significantly and Prisma migrations handle it cleanly.

Tailwind CSS 4. No component library. Custom components built from scratch. This gives us full control over the design and keeps the bundle small. Every component is exactly what we need, nothing more.

AWS EC2 + RDS + Route 53. We tried Amplify first (serverless) but ran into VPC connectivity issues with RDS. Moved to EC2 with Nginx and PM2. Less elegant, more reliable. Sometimes boring technology is the right choice.

The data problem

Getting 500 tools listed was the easy part. Getting 500 tools with good data was the hard part. Our first pass had generic descriptions copied from tool homepages and template-based features. Every writing tool had the same 6 features. That's useless.

We ended up writing custom enrichment scripts — 10 batches covering all 500 tools with real descriptions, actual pricing, curated ratings, and FAQs. It took longer than building the website itself. But a directory with bad data is worse than no directory.

Search that understands intent

PostgreSQL full-text search handles exact matches well. But users don't search for tool names — they search for problems. "How to automate email" should find Mailchimp AI and Instantly, not return zero results because no tool is literally called "automate email."

We built a smart search layer that maps use cases to categories, tags, and specific tools. It's not semantic search (we don't use embeddings) — it's a curated mapping that gets the job done without the infrastructure complexity of a vector database.

What we'd do differently

Start with fewer tools, more depth. 100 deeply researched tools would have been more valuable at launch than 500 with generic data. We ended up doing the enrichment work anyway — just later.

Skip Amplify entirely. The VPC issues wasted a week. Should have gone straight to EC2.

Build the admin panel first. We built public pages first, then the admin panel. Should have been the other way around — having good admin tools from day one would have made data entry and management much faster throughout the project.

What worked well

Server components everywhere. The site is fast because most pages are server-rendered with zero client JavaScript. Upvote buttons and search are the only interactive elements on most pages.

Prisma schema as the single source of truth. The database schema drives everything — types, API responses, admin forms. Change the schema, regenerate the client, and TypeScript catches every place that needs updating.

AI-assisted development. Yes, we used AI tools to build an AI tools directory. Cursor handled most of the boilerplate — admin CRUD pages, API routes, form validation. The architecture and data modeling were done manually. AI is great at the mechanical parts of coding.

The site is open to feedback. If you use VattheBest and something's broken, missing, or could be better — the contact form goes to a real inbox and we actually read it.