playbook-tech-on-website

Playbook: Technology On Website

All rules here are best practice, not law. Override any of them when the campaign calls for it; note the best practice once and move on.

1. Trigger and scope

Use when: the offer only makes sense to companies running a specific piece of software on their site — a Shopify app, a Klaviyo migration, a HubSpot implementation, a WordPress maintenance offer. Works in both directions: discovery ("build me a list of every company on Shopify") and enrichment ("here are 4,000 domains, which run Klaviyo").

Do not use when: you want the software a company sells, or mail-infrastructure targeting.

Default output: tech_confirmed, tech_stack_verified (JSON array), tech_evidence, tech_checked_at. Abstain = false / [] / "". On request only: tech_on_website_line, 110 chars.

The sentence is opt-in. The job is the verdict: does this company run the technology, and how do we know. That is what a list gets gated on, and for most campaigns it is the entire deliverable. Write the clause only when the brief explicitly asks. Never let an unrequested sentence be the reason a row costs a model call.

The thing that makes this playbook necessary

A technographic database tells you what a crawler saw at some unstated point in the past, and it is wrong often enough to embarrass you.

In the graded test, 4 of the 10 companies a provider returned from its own Shopify filter were not on Shopify. Two were not ecommerce at all.

The homepage verifier is not a quality step. It is the gate. Nothing reaches copy without it. Plan for roughly 60% of a provider-sourced list to survive verification, so pull 1.7x what you need.

2. Run it: tandem discovery, then the gate

The two discovery lanes run IN TANDEM and the result is a union. Not a waterfall, not a choice.

Measured: two providers' first pages returned 74 domains and 60 domains with zero overlap. Whichever single provider you pick, you leave most of the market on the table.