How we unified seven tools into one hub with an audience filter

AskBaily shipped seven free tools across roughly ten waves before Wave 205 — the contractor-check, the lead-spend audit, the exposure checker, the permit-timeline estimator, the migration-from-Angi calculator, and two more. Each tool lived at its own URL with its own hand-rolled topbar and footer. Wave 205 collapsed the collection into one hub at /tools with a two-state audience filter and a topic taxonomy shared across all entries. The refactor took one commit, and it is the kind of refactor that pays back every time a new tool ships.

The two-state audience filter

Every tool in the hub is tagged with its primary audience: homeowner, contractor, or both. The /tools index defaults to showing everything; a two-state toggle at the top of the page filters down to one audience. The state is URL-backed (/tools?audience=contractor) so a link from a /for-pros page can deep-link directly to the contractor-facing subset without showing homeowner tools first.

The filter is not cosmetic. It is the structural choice that lets us ship tools aimed at both sides of the marketplace without forcing either audience to wade through irrelevant entries. The lead-spend audit is a contractor tool; showing it to a homeowner confuses the hub's message. The permit-timeline estimator is a homeowner tool; showing it to a contractor wastes their attention. The filter is the thing that lets us pick the right primary audience per tool and trust the user to pick their own lane.

Topic grouping, shared across tools

Within each audience filter, tools are grouped by topic: Licensing, Pricing, Migration, Permits, Scope. The taxonomy lives in lib/tools/registry.ts alongside the tool entries themselves, so adding a new tool means picking a topic from the existing set (or proposing a new topic, which triggers a design conversation). This keeps the hub coherent as the tool count grows. Seven tools on a flat list is tolerable; 20 on a flat list is cognitive overload.

The grouping is also load-bearing for the hub's CollectionPage schema. Each topic group becomes an ItemList nested under the CollectionPage, which in turn nests the tool entries as WebApplication nodes with their own URLs, names, and descriptions. The hub is addressable from AI engines as a single citable resource even though the underlying tools live at individual URLs.

Why unify instead of leave them alone

Because stranded tools cannot compound. A tool at /contractor-check with its own topbar, footer, and meta tags is an island. A homeowner who arrives via a search citation for "how to verify a contractor's license" lands there, uses the tool, and either bounces or has to manually navigate back to the main site to find anything else. The hub changes that. The same homeowner now lands on /tools/contractor-check with breadcrumbs back to /tools, and from /tools they see the other tools that might be relevant to their journey.

The homeowner's next click from the hub is no longer a guess. It is informed by which tools the hub surfaces for their audience filter. The permit-timeline estimator, the scope-clarifier, the migration-from-Angi guide — all of them become visible in one place because the hub exists.

The shape of a tool entry

Each entry in the registry has the same shape: slug, title, description, audience (homeowner, contractor, or both), topic (one of the five), the canonical URL, and a small icon component. The audience and topic are discriminators the filter and grouping code read. The icon is a small SVG that renders next to the title on the index card. No tool entry has more than 12 lines of TypeScript, which is by design: adding a new tool should be cheap.

The registry enforces slug uniqueness and URL canonicality at module load. A duplicate slug would crash the build, which is the right behavior — it means an engineer tried to ship a tool whose URL collides with an existing one. Better to fail at build than to ship a dead route.

What the refactor preserved

All seven original tool URLs still resolve. Wave 205 did not move any tool to a new URL. The hub is an index that links to the existing endpoints; the endpoints themselves are untouched. Every backlink to the original tool URLs remains valid. Every SEO signal those pages built up remains attached to them. The hub is the additional discovery surface; it does not invalidate the existing rail.

This is the kind of refactor choice that looks boring and is not. Moving seven tools to new URLs to fit a naming convention would have cost us every external backlink, every cached search result, and every bookmark. The refactor is worth it only because it preserves the existing rail and adds an indexing layer on top.

What Angi and Thumbtack cannot copy

They can build a tools hub. They have. The difference is what goes in the hub. Ours contains tools that reveal information asymmetry: the exposure checker surfaces how many contractors Angi sent a given homeowner's data to. The lead-spend audit compares a contractor's Angi spend to AskBaily's flat-fee projection. The migration-from-Angi guide lays out the step-by-step to transfer a contractor's brand and reviews off Angi.

Those tools belong in our hub because our business model benefits when homeowners and contractors understand the category better. Those tools do not belong in Angi's hub because Angi's business model benefits when the opposite is true. The hub is the organizing surface; the tools that fill it are the competitive wedge.

The maintenance posture

One registry file. One schema primitive. One audience filter. One topic taxonomy. When the eighth tool ships, it adds 12 lines to the registry and inherits everything else. The hub is the pattern, not the content. The content will keep growing as long as the rail is worth riding.