Every operator with a stack has the same inbox. A vendor you already pay launches something new, the demo is good, and the first tier is free. The honest answer to "should we add it" is almost never found in the feature list, because the feature list is the vendor's argument, not yours. In August 2026 we ran one of these through the ladder we use for our own stack. The tool was Firehose, which Ahrefs introduced as a new standalone product in its June 2026 feature roundup[1] and which turns its web crawler into a push feed: tell it what to watch, and it sends you every newly crawled page that matches. We scored ten things we could do with it. Seven are dead. The one that would have brought in money died on the terms of service, with the technology never getting a vote. The ladder is the point of this note; the tool is the worked example.
The result, stated plainly.
A new tool earns a slot in the stack by passing five rungs, in order. One, the gap check: does it do something nothing we run already does. Two, the terms: do they permit the use that would pay for it. Three, score every use, then let the reasoning kill. Four, test the riskiest assumption on the free tier. Five, spend, under a ceiling the vendor enforces. At rung one, Firehose showed one genuine gap (Stream: real-time matching across the whole web) and one feature we already had (URL Watch: scheduled change detection on named pages, which an n8n workflow we run does for nothing). Of ten uses, three survived as one internal feed. The best billable use, a brand-monitoring add-on for clients, died on three clauses, and the two other billable uses died with it. Spend to date is zero, and it stays zero until a free test says the feed is worth wiring.
The ladder: gap first, features last.
The order matters more than any single rung. Most tool evaluations start where the vendor wants them to start, at the feature list, and work down to price. Ours starts with a question the vendor cannot answer, because it is about our stack and not their product: what, specifically, can this do that nothing we already run can do? Only a feature that survives that question gets evaluated at all. The rest of the ladder follows from that first answer, and the figure below is the whole of it.
Step one: what the stack cannot already do.
Firehose has two modes. Stream matches every page the crawler picks up against rules you write (a keyword, a site, a language, a page type, how trusted the source is) and delivers the match as it is crawled. URL Watch takes a list of pages you already know about and checks them on a schedule, down to five-minute intervals on the top plans, reporting what changed. The vendor presents them as two halves of one product. The gap check split them.
Stream is a real gap. Nothing we run does whole-web mention detection as pages appear: DataForSEO, our search-data provider, answers questions we ask it, on demand; our monitoring workflows watch the properties we own. A push feed from a crawler that sees pages we have never heard of is a different capability, and we did not have it. URL Watch is not a gap. We already run a workflow in n8n, our automation platform, that fetches a named page on a schedule, compares it to the last copy, and notifies someone when it changes. It is a few nodes. The paid feature would have been a nicer version of a thing we had. One rung in, half the product was off the table, and the half that remained had earned the right to be evaluated.
Ten uses, seven dead.
With one real gap in hand, we listed everything we could do with it, including the obvious money: a brand-monitoring add-on sold to clients, a digital-PR feed of fresh unlinked mentions, a white-label monitoring service. Each of the ten was scored on our six-part rubric (fit with what we sell, feasibility, cost, time to signal, defensibility, risk) out of seventy.[3] Then the reasoning went through the list, and the reasoning is what killed. The scores are below so you can see where the two disagree.
Three things survived, and they are really one thing: a machine feed into automations we already run. Our content pipeline today only sees sources we hand it; a feed of newly published pages that match a few dozen rules would give it an outside view. Prospecting signals for our outbound work (new job postings and new service pages from the trades we sell to) ride on the same feed with a few more rules. Alerts on mentions of our own brands ride on it too, because our brands generate too few mentions to justify a monitor of their own. One feed, a handful of rules, and the pay-as-you-go tier at five dollars per thousand matches, prepaid, which at our volumes is a few dollars a month. That is the whole surviving business case, and it is internal.
The terms decided it, not the tech.
The billable uses were the reason to look at the tool in the first place. A client pays a monthly retainer; a brand-monitoring add-on is a natural line on it; the tool does the monitoring. Technically it would work tomorrow. It died on three clauses, none of which has anything to do with whether the crawler is good. We read them twice, two months apart, and they had not moved.[1]
| the clause | a billable use (sold to clients) | an internal feed (our own automations) |
|---|---|---|
| No competing product. You may not use the service "to develop a product or service which competes with us". | dead A white-label monitoring service is exactly the product the clause describes. A monitoring-informed retainer is closer to defensible, but "closer to defensible" is not a footing for revenue. | clear A feed into our own pipeline competes with nobody. |
| Beta, as is. The service is "wholly beta", provided "as is" and "as available", and the vendor may "modify, amend, update, or fully or partially suspend or discontinue" it "at any time and for any reason... with or without notice". | dead A client promise with no service level, on a product the vendor can switch off tonight, is exposure dressed as a product line. | acceptable If the feed stops, an automation loses an input. Nobody is owed anything. |
| Who may use your account. Authorised users are those "authorised by you to use Firehose Services under your Account and/or on your behalf, including your employees, affiliates, personnel, agents, contractors or consultants". Serving paying clients from one account is neither permitted nor forbidden in writing. | dead until confirmed "Neither permitted nor forbidden" is a question for the vendor, in writing, before a single client is invoiced. Until the answer exists, the use does not. | clear Our own staff, on our own behalf, is the case the clause describes. |
The demand check came second. Before killing the billable uses we checked whether there was an inbound market to lose: one keyword query, Canada, August 2026. "Veille médiatique" came back at about 50 searches a month; "media monitoring" at about 90 and declining, with a cost per click of about a hundred dollars, which is an enterprise advertiser's budget and not a small business's.[2] That is an enterprise category with no small-business search demand behind it. The terms killed the idea; the demand check confirmed nobody would have been waiting for it.
We have written this shape up before. Our note on the n8n licence found that what a tool permits commercially decides the question before the technology is evaluated, and the boundary there (internal business purposes, yes; providing it to others for money, no) is the same boundary these three clauses draw. The rule is the same for both: read the terms at rung two, before anyone is attached to the idea that dies there.
The free workflow beat the paid feature.
The second-highest score on the map is the one that looks easiest to buy. Watching a competitor's pricing page, a supplier's terms, a regulator's guidance page: the paid feature does it on a ten-minute interval, with a clean interface, for thirty-nine dollars a month on the smallest paid plan. It scored 51 out of 70 because it is trivially easy and free to try, and it died for exactly that reason. Easy to test is not a reason to adopt. We already had the capability, and the comparison is not close.
| URL Watch (vendor feature) | n8n diff workflow (ours) | |
|---|---|---|
| what it does | checks a list of pages on a schedule, shows what changed | fetches a page on a schedule, compares it to the last copy, notifies on change |
| fastest check | 3 hours on Free; 10 minutes on Starter; 5 minutes on Advanced and Business | whatever the schedule node says; hourly is plenty for a pricing page |
| pages watched | 5 on Free; 50 on Starter; 250 on Advanced; 1,000 on Business | one list in a data table; add a row |
| cost per month | $0 / $39 / $89 / $299 by plan | $0 extra on a platform already paid for and running |
| where it lives | the vendor's dashboard and account | in our own automation platform, next to the workflows that act on the alert |
| if the vendor stops | the feature stops; it is a beta the terms say can be discontinued without notice | nothing stops; the fetch is ours |
| what it cannot do | neither watches pages you do not know about; that is the Stream mode, and the only thing that cleared the gap check | |
This is the concrete form of a rule we apply everywhere: before paying for a feature, ask whether a workflow in a platform you already run replicates it, and how much of the difference you would ever use. A five-minute check on a pricing page is not a capability any of our automations needs. The extra fifty minutes an hourly check can lag behind a ten-minute one are worth nothing to us. The paid feature wins on every row that does not matter and loses on the two that do: cost, and what happens when it goes away.
The free test is the gate, and it is still shut.
Everything that survived rests on one assumption nobody can verify from the vendor's site: that the crawler behind the feed actually covers the small francophone Quebec web, the regional weeklies, the trade publications and the contractor sites our automations would need to see, with useful depth and a lag short enough to beat how we find things today. Crawlers follow link authority. Big sites get crawled constantly; a weekly in Charlevoix or a roofer's blog in Rimouski may get visited rarely, and nothing published says how rarely. If the francophone Quebec web is a crawl desert for this crawler, every use on the map dies together, including any future revival of the billable ones.
The test costs nothing. The free tier gives one monitor, two hundred matches a month and no card on file. On 2026-08-06 we set it up: a tap with four rules, a roster of fifteen known Quebec sources (four national dailies as calibration, three trade publications, five regional weeklies, three contractor sites) plus job boards and our own brand names, quality filtering off so the test measured the crawler and not the vendor's filter. The first match arrived within minutes of the rule going live, from a Charlevoix weekly: an author-archive page, not an article, which told us two things at once. The crawler visited one regional weekly within minutes of a rule going live, which is one data point and not a coverage result, and the scoring will have to separate article matches from site churn.
As we publish, the week's matches have not been scored. The window closed on 2026-08-13, the three checkpoints in the spec are unticked, and the verdict file is blank. That is a lapse in follow-through on our side, and it is also the clearest demonstration of the ladder working: the gate sits in front of the spend, so when the test stalled, the spend stalled with it. Nothing was wired. The pay-as-you-go balance was never funded. A stack that evaluated tools in the other order, features first and a card on file at signup, would have been two months into a subscription by now, waiting for the same answer.
What to do this week.
- Write the gap check before you open the feature list.
One sentence per feature: "nothing we run does this" or "this already runs in X". Answer it from your stack, not from the demo. Half of this product fell out here, and it was the half with the price tag.
target: every feature tagged gap or have, before pricing is read - Read the terms at rung two, and read for three things.
A no-competing-product clause. Beta, as-is, or discontinuable-without-notice language. Whether the use that would pay for it (serving your clients, reselling, white-labelling) is permitted in writing. "Neither permitted nor forbidden" is an email to the vendor, not a green light.
target: the billable use is explicitly permitted, or it is off the table - List every use, score them, then let the reasoning kill.
Our note on scoring before you spend covers the scoring. The addition here is the override: a high score with a dead reason (a clause, a redundancy, a wrong corpus) is dead. Write the reason next to the score so nobody re-litigates it in six months.
- Name the riskiest assumption, and test it on the free tier.
One assumption, one week, no card on file. If the free tier cannot test it, that is information about the vendor. If the test fails, everything built on the assumption dies together, and you have lost a week instead of a year.
target: a dated result before any money moves - Spend last, under a ceiling the vendor enforces.
Prefer prepaid or hard-capped tiers over subscriptions with overage billing. A meter that stops is a cost ceiling by design; a budget you promise to watch is not. Our note on rerunning the cost math is the same instinct applied to model pricing.
What this does not claim.
One tool, one evaluation, our stack. The ladder is ours and the scores are ours. A small business that does not already run an automation platform would score the page-watching feature differently, because for them it would be a gap, and thirty-nine dollars a month might be the right answer. The method travels; the verdicts do not.
Not a reading of the law. The three clauses are quoted as we read them on two dates, and "neither permitted nor forbidden" is our characterisation of a silence in the text, not a legal opinion. Anyone building a client offer on a vendor's terms should ask the vendor in writing and, for anything material, counsel.
The crawler figures are the vendor's. The vendor publishes how many pages its crawler visits and how fast. We have not verified them and we do not repeat them. The only crawl fact in this note we observed ourselves is one match from one regional weekly, minutes after a rule went live, and one match is an anecdote.
The gate is still shut. Nothing here says the surviving feed is worth wiring. The test that decides that was set up and has not been scored, so the honest status of the top pick is "candidate", two months on. If the scoring comes back poor, this note's survivors die too, and we will say so.
If a new tool has landed in your inbox and someone is already attached to it, send us the feature list and what you run today through the contact form. Running the ladder on a stack before a card goes on file is the first step of our workflow automation service.