Findaly — decision-first directory

The problem was never access to software.

People already know where to look. Google is full of lists. Marketplaces are crowded. Social feeds are full of recommendations. If anything, discovery is oversupplied.

The real friction appears after discovery.

Once someone lands on a category like “CRM” or “AI writing tools,” the differences between products blur. Feature lists converge. Landing pages use the same language. Reviews are either shallow, outdated, or clearly influenced by incentives.

People don’t leave these sites feeling informed. They leave feeling uncertain.

Through my own experience and by watching how founders and builders actually search, a pattern became obvious. Most searches weren’t exploratory. They were comparative. “X alternatives.” “X vs Y.” “Best X for Y.”

These are not browsing queries. They are decision queries.

Most directories, however, are not designed for decisions. They are designed for exposure, monetisation, or content volume. Tools are treated as inventory, not as choices someone is actively weighing.

Findaly started with a question that reframed the problem entirely.

What would a software directory look like if it treated software as decisions instead of listings?

From the beginning, I avoided defining success in terms of traffic or features. Those would come later, if the foundation was sound.

Instead, success was defined by how the product felt at the moment of use.

A Findaly page should reduce cognitive load, not add to it.

It should make differences clearer, not louder.

It should feel neutral, even when monetisation eventually exists.

If someone left without clicking anything, but felt more confident about their choice, the product had done its job.

That framing immediately ruled out large classes of features. Reviews, ratings, and user comments all introduce noise early. Aggressive CTAs erode trust. Rankings create artificial certainty where nuance is needed.

The product needed to feel like infrastructure, not content.

There was no formal research phase, but the thinking was deliberate.

One insight surfaced again and again: most people don’t want “the best tool.” They want the best tool for them. That distinction sounds small, but it changes everything.

Another insight was that opinions age badly. Features change. Pricing shifts. Reviews rot. Structured facts, on the other hand, remain useful longer and can be recomposed in different contexts.

But the most important realization was this:

Software directories fail not because they lack information, but because they fail to structure it around decisions.

Once that clicked, the product stopped being a content problem and became a systems problem.

The MVP was intentionally narrow and, in some ways, austere.

I did not build accounts, comments, ratings, or community features. I did not build dashboards, notifications, or personalization. I didn’t even try to cover every category of software.

Instead, I focused on a small number of page types that map directly to real intent.

Tool pages act as entity hubs.

Alternatives pages capture switching intent.

Comparison pages surface differences cleanly.

Use-case pages contextualize fit.

Everything else was deferred.

This restraint was not about speed. It was about protecting the clarity of the system. Each additional feature risked shifting the product toward persuasion or noise.

Findaly is built around a small set of core entities: tools, categories, use cases, and integrations.

Tools are the center of gravity. Everything else exists to frame them.

Rather than a strict hierarchy, the site forms a graph. A tool links to its alternatives. Alternatives link to comparisons. Comparisons link back to tools and outward to use cases. There are no dead ends.

This structure serves users and search engines in the same way. It allows people to move through decisions naturally, and it allows topical authority to emerge without manual curation.

The architecture resembles Wikipedia more than a blog. Pages are not endpoints. They are nodes.

Alternatives pages are where Findaly earns its place.

Someone searching for alternatives to a tool is already motivated. They are questioning their current option or validating a shortlist. They don’t need hype. They need orientation.

Instead of presenting a flat list, alternatives are framed around why people leave and what different options are actually better at. Tools are grouped by use case rather than popularity.

This shifts the question from “Which tool is best?” to “Which tool fits my situation?”

That reframing does most of the work.

Comparison pages are generated from shared schema and deliberately avoid conclusions.

There is no “winner,” no score, no recommendation. Just structured differences presented side by side.

This was a conscious decision. Declaring winners feels helpful, but it often hides tradeoffs. By resisting that impulse, the product stays aligned with its core promise of neutrality.

The comparison exists to support judgment, not replace it.

Use-case pages handle a different kind of intent. These are users who already know their context and want to see tools filtered through it.

The key decision here was restraint. Not every combination deserves a page. Only use cases where context meaningfully changes the answer are included.

This keeps the site focused and avoids thin, repetitive content. From an SEO perspective, it trades breadth for depth. From a product perspective, it maintains credibility.

Internal linking is not an SEO afterthought in Findaly. It is part of the product.

Every page connects outward in predictable ways: to its category, to alternatives, to comparisons, to relevant use cases. These rules are deterministic, not editorial.

This creates momentum. Users don’t need to decide where to go next. The system gently guides them through the decision space.

It also makes the product maintainable. As new tools are added, the graph strengthens automatically.

Findaly is built with Next.js, React, TypeScript, Tailwind CSS, Prisma, and PostgreSQL, and deployed on Vercel.

The stack was chosen to support programmatic page generation, strong typing, and rapid iteration as a solo builder. Much of the complexity lives in the data model and routing logic rather than in the UI.

That mirrors the product philosophy. The hard work happens underneath.

The biggest challenge was restraint.

It was tempting to add features that would make the product feel more familiar or more impressive. Reviews, AI summaries, rankings, and monetisation hooks all came up repeatedly.

Each time, the question was the same: does this reduce or increase cognitive load?

If the answer wasn’t clearly “reduce,” it didn’t ship.

Another challenge was designing neutrality without emptiness. The product still needed to feel intentional, not vague. That required careful copy, ordering logic, and deciding what not to say.