They just switched a tool.
BuiltWith, Wappalyzer, and SimilarTech show when a company adds or removes a specific tool. A migration moment is the highest-intent window in B2B, and most vendors do not watch it.
7-minute read · 1 anatomy table · 1 sequence template · 1 worked example
A stack change is a decision, not a guess.
Most intent data is statistical. A vendor like Bombora or 6sense tells you a company has been researching your category, with some confidence interval based on aggregated browsing behavior. The confidence is real but the action is still ambiguous: the company might be evaluating, might be hiring an analyst, might be writing a blog post about the space.
A stack change is the opposite. When BuiltWith shows that a target company removed Segment last Thursday, that company actually removed Segment last Thursday. The DOM change is observable. There is no probability attached. They are mid-migration, they need a replacement, and they are losing functionality every day until they pick one.
That definitional certainty makes stack-change triggers the steepest-converting intent signal in B2B. The remove event is the most urgent: it implies the buyer has either picked an alternative and is mid-implementation, or has not yet picked and is actively shopping. The add event is slightly less urgent but creates a downstream gap: companies that add a platform usually want complementary tools within 6 to 10 weeks of the install.
The play is underused for two reasons. First, the data is not free. BuiltWith and SimilarTech price into the mid hundreds monthly. Second, the data is noisy at the edges, and unfiltered fire-hose outreach burns reputation before the play produces meetings. Both are solvable, but they screen out the casual attempt.
The rest of this page is the anatomy of the signals worth acting on, the add-vs-remove sequence design, the composite case study of a CDP that ran their entire net-new motion off Segment installs, and how we would run the play with you.
The right event at the right time.
Add and remove events have different conversion shapes, different windows, and different right-frame pitches. The table below is the matrix we use to calibrate the play. Get the event type and the pitch frame matched, and the conversion holds.
| Event | Window | Right pitch frame | Conversion |
|---|---|---|---|
| Remove of competitor (your category) | 0 to 14 days | Replacement pitch, evaluation help | 1 in 5 |
| Remove of adjacent tool (you complement) | 0 to 21 days | Compensating complement | 1 in 8 |
| Add of platform you integrate with | 14 to 45 days | Complementary tool installed now | 1 in 7 |
| Add of analytics or tag manager | 14 to 30 days | Destination or use-case enabler | 1 in 8 |
| Multiple removes in 30 days | 0 to 30 days | Stack-consolidation pitch | 1 in 5 |
| Repeated add-remove of same category | Skip | Buyer is unstable, signal noise | Skip |
The strongest case on the table is the multiple-removes-in-30-days pattern. A company that has removed two or three tools in a single month is almost always running a deliberate stack consolidation, and the buyer is unusually open to "we replace three of those with one" pitches. Sales cycles on this cohort compress further than any other variant.
The trap is the repeated add-remove of the same category. BuiltWith will sometimes show a tool toggling on and off because the company is testing or running an evaluation. The signal looks active but the conversion is below cold-list baseline because the buyer is unstable.
Different events, different sequences.
Add events and remove events do not share a sequence. The remove sequence is urgent and short because the buyer is actively replacing. The add sequence is slower and complement-framed because the buyer is implementing the new tool and not yet looking for adjacents. Below are both shapes.
The non-obvious thing about the remove sequence is the explicit out in touch one. Telling the buyer "if you have already picked a replacement, ignore this" reads as confident rather than desperate, and it actually increases reply rate. The buyer feels less pitched and more invited.
The add sequence is deliberately slower because complementary buying happens after the implementation is operational. Compressing the touches makes you look pushy at exactly the wrong moment. Wait the 14 days, then go.
The CDP that ran every new logo off one signal.
Composite drawn from CDP and customer-data-platform startups running stack-trigger outbound as the primary motion. Specifics anonymized; the arc is consistent with what the play produces against the right platform-trigger match.
The team was a Series A customer-data platform pitching themselves as the destination for Segment and RudderStack customers. They had been running standard outbound to ICP-fit accounts and producing 4 percent reply rates, with deals slow because the buyer was rarely in active CDP-shopping mode.
They subscribed to BuiltWith's new-install alerts for Segment specifically, filtered to US B2B SaaS companies above 5M ARR, and started running the add-event 3-touch sequence to every install within 14 to 21 days of detection. They did not turn off the other outbound; the Segment trigger was an additive layer.
The reply rate on the Segment-add cohort came in at 17 percent on touch one, with 1 in 6 replies converting to a paid pilot inside 60 days. Average pilot-to-paid conversion was 50 percent, and average ACV came in at 1.4x their non-trigger cohort because the buyer was further along the decision curve.
By month nine, the Segment-trigger layer was producing more new logos than their original ABM motion at a tenth of the sender volume. They shut off the ABM motion in month 11. The team grew from 1.1M to 3.8M ARR over the following 18 months running exclusively on stack-trigger pipeline, adding RudderStack and one additional CDP source as additional triggers as they scaled.
The data is the entry cost. The filter is the work.
BuiltWith is not hard to subscribe to. What separates teams that make the play work from teams that abandon it is the discipline of filtering, the per-event-type sequence design, and the per-prospect handling rhythm. Four pieces, repeated weekly, indefinitely:
BuiltWith + SimilarTech feed, filtered
Daily pull of add and remove events for your competitor or complementary-tool list. Filtered to your ICP company-size band. Deduplicated, scored by event type.
Event-type-specific sequences
Remove sequence and add sequence both standing up in your sender. Routing logic so each event triggers the right shape. Day-tuned to the event date, not a generic cadence.
Per-event enrichment
Buyer identification, verified email, current stack from BuiltWith. The personalization is the event itself plus the surrounding stack context.
Quarterly competitor list refresh
The named competitor or platform list decays as the category shifts. We refresh the watch list quarterly and rotate underperforming triggers out.
The sizing call is short. You tell us your named competitors or complementary platforms, we tell you the typical event volume against your ICP and the per-event conversion math, and you decide whether the BuiltWith cost is worth the volume.
Tell us your competitors. We will tell you the event volume.
We will pull a sample month of BuiltWith add and remove events for your named competitors or platforms, send you the list, and walk through the conversion math on the right sequence frame. If the volume justifies the data cost, we can talk about running it.
Book the sizing call →Free for founders. The sample event list is yours either way.