AppCrib

We Redesigned the Front Door Before the Catalog Outgrew It

Field notes·By Carl Stein, Co-Founder & Head of Build·

When AppCrib had a dozen tools, the homepage could be a list. Every tool got a card, every card got a sentence, and you could scan the whole catalog in the time it takes a kettle to boil.

We are past thirty live tools now, with another batch moving through the pipeline behind them. Somewhere along the way the list stopped being a catalog and started being a junk drawer. Everything was technically findable and nothing was easy to find. So this summer we rebuilt the site's navigation from the ground up, and since we build in public, here is what changed and the reasoning behind it.

Toolkits Are the Unit Now

The core decision: the site no longer organizes around individual tools. It organizes around toolkits, which are small families of tools that solve neighboring problems. Color conversion. JSON tooling. Paint and coatings. Typography. Each toolkit gets its own landing page with everything in the family on it.

This sounds obvious, and it is. The interesting part was accepting what it meant for the navigation. Our first mega menu tried to be both things at once: toolkit rows and individual tool pills, names and taglines and counts, all competing in one panel. It was honest and it was unusable. Review feedback said the quiet part out loud, so the menu went on a diet.

The mega menu is now toolkits only. Bigger names, a one-line description, the newest arrivals noted, and nothing else. You pick a family, you land on the family page, and the family page does the introducing. One decision per screen. We preach single-purpose tools; the navigation finally practices it.

Counts That Don't Lie

There is a detail in this redesign we care about more than the visuals: every number in the navigation is now computed from what is actually live.

A toolkit that says it holds five tools links to five working tools. Not five entries in our registry, not three live tools plus two that are built and waiting on deployment. Deployed means you can click it right now and it works. Built means it exists in the repo and has passed its gates, and as far as the public site is concerned, it does not exist yet.

The stricter version of the same rule: a toolkit with nothing live in it does not appear at all. No menu row, no homepage card, no category page, no sitemap entry. We currently have an entire toolkit sitting fully built behind that rule, waiting for its apps to flip live, and the site simply does not mention it. The moment the first tools in it deploy, the whole surface appears on the next build: menu row, landing page, homepage card, all of it, with a count that is true.

We could have shipped the pages early with a coming-soon badge. Everyone does. But a nav full of promises is a nav you learn to distrust, and trust is the entire product when your tools handle people's data client-side. The registry drives everything from one source of truth, the build fails closed, and the marketing surface can only ever describe software that exists.

The Quieter Changes

Two smaller things shipped alongside the menu, both in the same spirit.

The visual system got an overhaul we internally described as elevation with a spine. Sections are numbered and rhythmic instead of floating in whitespace, cards sit on a consistent elevation scale instead of ad hoc shadows, and the header went solid so the menu reads as furniture rather than an overlay. None of this is novel design, it is just discipline applied late, which is usually when discipline arrives.

And the blog is getting steadier. Tool launches and field-notes posts like this one now land on a regular cadence instead of arriving in bursts whenever a build wave finishes. Same content, saner heartbeat.

What We Got Wrong the First Time

Fairness requires admitting the first version of this redesign overreached. We crammed per-tool chips into the menu because it felt informative, and it took an outside set of eyes about four seconds to identify it as noise. We also let a few decorative flourishes into tool pages that a stricter read of our own design rules would have killed, and our automated gates now do kill them, because every one of these review comments eventually becomes a check the pipeline runs without us.

That is the actual lesson of the exercise, and the reason it belongs on the build-in-public blog. The redesign was not a rebrand, it was a set of rules getting formalized: navigation shows families, numbers reflect reality, empty surfaces stay invisible, and human taste gets encoded into gates so the next forty tools inherit it automatically.

The catalog will keep growing. The front door should not have to be rebuilt every time it does.

AppCrib
Free tools for developers, designers, and everyone else.
Browse all tools