ecommerce-by-techstack

Ecommerce by Tech Stack

Overview

This skill produces a CSV of online stores that match a platform, a category and a tech stack, each with a validated email and a size tier, plus a report that shows the filters, the test pull, the tier bands, any Tech Stack Search intersection, the funnel and the cost.

It prevents three common failures with ecommerce lists:

1. Pulling every Shopify store and filtering locally. Store Leads bills $0.0039 per lead returned; the visits, sales and employee band filters run server-side, so stores outside the band are never returned or billed. Filter in the call.
2. Paying for the same page twice. Without offset, repeat calls with the same filters return the same first page. Page with offset or the returned nextOffset.
3. Targeting on "has Klaviyo" and nothing else. A store with Klaviyo and $8,000 a month in sales cannot pay a $3,000 retainer. Tier by estimated sales or traffic so the offer and the store size match.

When to Use

• "Give me Shopify apparel stores that use Klaviyo and have an email, as a CSV."
• "Find subscription brands on Recharge doing over $100k a month."
• "WooCommerce stores in Germany with a phone number."
• "Shopify stores on Gorgias with an Instagram presence."
• "Stores that use Klaviyo but not Attentive" (exclusion).

Use a different skill when:

Prerequisites

Authoritative Foundations

Details and the routing table: references/framework-notes.md.

Workflow

1. Turn the offer into a tier floor

Ask what the offer costs per month and the affordability ratio the user wants: the store's estimated monthly sales as a multiple of the offer's monthly price. No published benchmark sets this ratio, so it is the user's input; set it from the sales of current clients. At the worked example's 20x, a $2,500 a month retainer implies a $50,000 a month sales floor for the core tier. Write the tiers as non-overlapping bands of minEstimatedMonthlySales and maxEstimatedMonthlySales (or visits, or employees). Band presets are in references/tiering-and-tech-intersection.md.

2. Pick a recipe and build the filters

Start from references/filter-recipes.md (recipes by seller type and by app). Always set emails: true for an email list and phones: true for a call list. Use apps only with platform: "shopify"; for other platforms use technologies. Every parameter, its type and its behavior is in references/store-leads-parameter-guide.md.

3. Probe values with a 25-row test

The catalog documents platform and category as case-insensitive strings and apps and technologies as strings, with no list of allowed values. Run the draft with totalLeads: 25 ($0.0975). Read the returned category, apps and technologies columns, and copy the exact app or technology name you see into the filter. A 25-row result under 25 rows means the universe for those filters is that small; widen.

4. Size each tier and confirm the cost

There is no count endpoint for Store Leads. Plan each tier's totalLeads from the target, plus headroom for validation and dedupe losses: use the loss share from the user's last comparable pull, or validate the 25 probe emails ($0.04) and use that share, then replace it with the first tier's actual loss. Cost ceiling = sum of totalLeads x $0.0039, plus $4.99 per Tech Stack Search technology, plus validation at $0.00169 per email. Run check_wallet, show the table and wait for a go-ahead.

5. Pull each tier with offset paging

One run per tier, same filters, different band. For a tier larger than one run, page: offset: 0, then the nextOffset the response returns (or the previous offset plus totalLeads). If a run is cancelled, restart with resumeFromLead. Set fileName per tier so list_runs and the dashboard show it.

6. Intersect or exclude with Tech Stack Search

Store Leads takes one apps and one technologies string per call, and has no "not installed" filter. For a second required technology, or to exclude stores using a competitor, run scrape_builtwith once per technology ($4.99 flat), normalize the returned domains, and join on domain:

Procedure and domain normalization: references/tiering-and-tech-intersection.md sections 5 and 6.

7. Normalize, dedupe, suppress, validate

Normalize domains and emails per references/list-quality-standard.md. Drop platform-host domains (*.myshopify.com when a custom domain exists). Dedupe on domain, then on email (one brand can run several storefronts with one inbox). Apply suppression. Validate every email with validate_emails. Store emails are often role addresses (hello@, team@); keep them, with is_role set, and never pitch a support@ address, which reaches the helpdesk queue.

Then open 20 random rows and record one line: store live (the domain opens a working storefront), category fit, qualifying app visible on the site, sales band plausible for what the site shows, each as "N of 20". Two or more misses on one check means a filter value is wrong: re-probe and re-pull rather than deleting rows.

8. Add named contacts where the founder no longer reads the inbox

Small stores (E3, T3 and T4) are founder-run: the role inbox is enough. From T2 up, add up to 2 named people per store with the title ladder in references/tiering-and-tech-intersection.md section 7: on Growth, the Lead Database by companyDomain costs nothing extra; on Starter, Website Finder with jobTitle: "Founder" ($0.0499 per contact found) on T1 and T2. Validate every named email. Send the named contact first; the role inbox waits in a hold file.

9. Deliver, hand off, refresh

One CSV with a tier column, a hold file for catch-all and unknown, and the report from templates/output-template.md. Sequencer handoff: one campaign per tier, custom variables store_name, category, the qualifying app, any uses_<tech> or unhappy_with_<app> flag and the contact's first name (a role inbox reads "Hi {{store_name}} team"). Re-validate any row whose email_validated_at is older than 30 days before it sends; next month, continue each tier from its saved nextOffset and refresh the technology flags. Run scripts/check-output.py.

ScraperCity Implementation

Tools and prices (from references/scrapercity-catalog.md)

Store Leads call with every filter family

{
  "platform": "shopify",
  "category": "apparel",
  "apps": "Klaviyo",
  "countryCode": "US",
  "state": "California",
  "emails": true,
  "phones": false,
  "instagram": true,
  "tiktok": true,
  "planExclude": ["Shopify Plus"],
  "minEstimatedMonthlySales": 50000,
  "maxEstimatedMonthlySales": 249999,
  "minEstimatedMonthlyVisits": 20000,
  "minEmployeeCount": 2,
  "maxEmployeeCount": 50,
  "totalLeads": 500,
  "offset": 0,
  "fileName": "shopify-apparel-klaviyo-ca-t2"
}

Not every call needs every filter; each one narrows the result. technologies takes a technology name string for non-Shopify platforms (for example "platform": "woocommerce", "technologies": "Klaviyo"). city, facebook, youtube, linkedin, twitter and pinterest work the same way as their siblings above. Aliases: visitsMin, visitsMax, salesMin, salesMax, employeesMin, employeesMax.

CLI: npx scrapercity store-leads takes platform, country, category, city, technologies, apps, total-leads, name and the emails, phones, instagram, facebook, tiktok, youtube and linkedin switches in package 1.0.17. The band filters, state, planExclude, offset, twitter and pinterest are MCP and REST only: POST https://app.scrapercity.com/api/v1/scrape/store-leads with the JSON body above.

Tech Stack Search call

{"technology": "Recharge", "fileName": "techstack-recharge-20261013"}

Returns the domains detected using that technology, for $4.99 per technology. The list covers all websites, not only stores, so always join it to a Store Leads pull.

Worked cost estimate

Shopify apparel stores in the US using Klaviyo with an email, three sales tiers, target about 1,150 send-ready, Recharge flagged.

Show the ceiling first (requested 1,625 leads x $0.0039 = $6.34, plus $4.99, plus up to 1,625 x $0.00169 = $2.75 validation, $14.08) and wait for a go-ahead.

Errors

Output Format

1. stores-[segment]-[date].csv: domain, store_name, platform, category, apps, technologies, country, state, city, est_monthly_visits, est_monthly_sales, employees, social flags, email, is_role, email_status, email_validated_at, tier, uses_<tech> and unhappy_with_<app> flags, review_note, source = store_leads, source_detail, pulled_at. Valid emails only.
2. stores-[segment]-[date]-contacts.csv: one row per named person (domain as the join key, first_name, last_name, title, email, email_status, contact_source), so a store with two contacts stays one store row.
3. stores-[segment]-[date]-hold.csv: catch-all and unknown, plus role inboxes held behind a named contact.
4. Report from templates/output-template.md: target, filters, value probe, tier bands, Tech Stack Search and review flags, funnel, validation, named contacts, cost, sample rows with the QA line, next steps with the sequencer handoff.

What the reader receives is the deliverable only: product names (Store Leads, Tech Stack Search, Email Validator, Website Finder, Lead Database), never tool ids, internal file paths or reference section numbers; filter parameter names appear only in the Filters Used table, where the user needs them to rerun the pull; another skill is named only in a handoff line; no tables of checks that were not run (one "Not checked:" line instead); no repeated identical rows; no legal commentary.

Quality Check

• Every filter name exists in the scrape_store_leads schema, and emails: true is set for an email list.
• apps appears only with platform: "shopify".
• A 25-row probe ran and the app and category values match what the data returned.
• Tier bands do not overlap and each tier was pulled with server-side band filters.
• Every multi-page tier used offset or nextOffset; no page was bought twice.
• Tech Stack Search lists were joined on normalized domains and each technology cost $4.99.
• Main CSV is 100% email_status = valid; 0 duplicate domains; suppression applied.
• Funnel adds up and the tier counts sum to the send-ready total.
• The QA line reads "N of 20" for store live, category fit, app visible and band plausible, with no check under 18 of 20.
• Tiers from T2 up show named-contact coverage (stores with a named valid email) and the method used; T3 and lower may run on role inboxes.
• The report names products, not tool ids or file paths, and carries no legal commentary.
• scripts/check-output.py report.md prints PASS.

Common Pitfalls

Execution Artifacts

Related Skills

• icp-list-builder for people-first lists at ecommerce companies.
• decision-maker-finder for founders and marketing leads at the store domains.
• tam-builder to size every store in a category before choosing tiers.
• cold-email-list and email-list-cleaner to carry the file to a sequencer.
• cold-email-copywriting for tier-specific copy that cites the installed app.
• scrapercity-api for REST loops over many tiers or countries.