Stop paying Clay credits for prospects you already own

Build me an app my go-to-market team opens every time we build a new prospect list, so we stop burning Clay credits on people we already own or never wanted. The design principle is that Clay separates cheap browsing from paid enrichment, and this app has to mirror that split exactly: a dedupe-and-select gate sits between the free preview and the credit-consuming run.

The main screen is a search builder. On load, call Clay's List Search Filter Fields for the selected source type (people or companies) and render the returned fields as the filter controls, so the form always matches what Clay actually accepts rather than a hardcoded guess. Let me toggle between people and company searches and stack several filters. When I hit Preview, start the search with Create a Filters-Mode Search, hold the returned search_id in view state, and page results into a table with Run a Filters-Mode Search, which is a stateful iterator you call again while has_more is true. Load one page at a time behind a Load more control instead of draining the whole search up front.

Dedupe every row against HubSpot as it lands. Check people with Search Contacts by email and companies with Search Companies by domain, batching lookups into as few search calls as possible instead of one request per row, because HubSpot search is limited to a few requests per second and caps how many filter groups a single search can carry. Any row with a match gets an "already in your CRM" badge showing the current record owner's name, resolved through List Owners, which you should fetch once per session and cache as an owner ID to name map. Rows with no match are flagged net-new.

Selection is where the spend decision happens, so make it the visual center of the screen. Every row has a checkbox. Rows matched in HubSpot are unchecked by default and visually de-emphasized; net-new rows are the ones I pick. Directly above the Enrich Selected button, show a running counter with how many rows are currently selected and how many were skipped as CRM duplicates, so the cost of a run is visible before anyone clicks.

Enrichment stays a deliberate act and never fires automatically. One Enrich Selected button runs my chosen Clay routine on just the checked rows using Run a Routine, which accepts up to 100 inline items per call, so chunk larger selections into multiple runs. Each call returns a routine_run_id and completes asynchronously. Poll Get Routine Run Results for each run until its status is terminal, and fill enriched columns into the existing table rows as results land rather than blocking the whole screen behind a spinner. Show per-row status so I can tell which rows are still running, which came back, and which failed.

Once enrichment returns, let me review the filled-in rows and approve them, then push only the approved ones into HubSpot. Send people through Batch Upsert Contacts matched on email in batches of up to 100, so re-pushing the same list never creates duplicates, and create accounts with Create Company. When the push finishes, report exactly how many records were created versus updated, and surface any rows HubSpot rejected so I can fix them.

For persistence, let me save the current filter configuration as a named filter set and reload it on a later visit, so recurring list builds start from the last one instead of being rebuilt from scratch. Also give me a small settings area where I paste the Clay routine ID that Enrich Selected should run, because routine and table IDs are not discoverable through Clay's public API and have to be copied out of the Clay workspace UI. Keep the Clay API key server-side, never in the browser.