Vendor decision

Provider claims from memory go wrong in predictable ways:

• terms can restrict the intended use of an API
• a benchmark can measure the wrong path
• estimates from memory drift, sometimes by several times
• a vendor's minimum data retention can exceed what the privacy policy promises

This skill makes each claim come from a live source and puts the decision-maker's choice on one page.

Step 1: Map the field

List every realistic option before comparing any of them. The user should never have to ask "what about X?" about an option that was missing.

• Direct providers: the obvious ones, plus options native to the project's stack (for a Flutter or Dart app, Dart-native backends such as Serverpod), EU or self-hosted options when data location matters, and "build it ourselves".
• Competitors of the provider a feature depends on. If the feature needs data from one platform, also map the other platforms users actually keep that data on, including the operating system's own data store. Say which user segments each covers, for example users who reach that data only through a third-party app.
• Gatekeepers: whoever controls access even when the provider is willing.
  • platform rules: App Store and Google Play review guidelines, and platform data-access rules
  • API terms and developer agreements, including display, storage, AI-training, and competition clauses
  • partner-program approvals and rate-limit tiers
  • regulators, for example data-protection rules for sensitive data, or sector regulators Record which clause gates what, with a link.
• Competing products: apps already doing the same job. Note how they solved it, because it shows which integrations are realistic.

Step 2: Verify on live sources

For each option, fetch the live page and quote the clause or number with its URL and the date you read it.

• Terms: what the data may be used for, whether it may be shown to other users, storage limits, AI use, attribution, and termination.
• Price: the listed price, what triggers usage charges, the free tier, the renewal price, the minimum commitment, any minimum prepaid top-up, and whether prepaid or included credit expires, resets each cycle or can be refunded. For a hosted wrapper over another API, find its markup over the underlying price, and check the README and the founder's posts when the pricing page omits it.
• Percentage fees with a free band: find out whether the percentage applies to all of the metered amount once the free limit is crossed or only to the part above it, and what the meter counts (gross revenue before store commission, or only revenue a product helped generate). Example: Qonversion's pricing page says that past $7,000 a month it charges 0.8% of tracked revenue "not just the amount above $7K", and Superwall's blog says "Once you cross $10K MAR, we take a 1% fee on total MAR" (both read 2026-11-05). RevenueCat's pricing page says "Then pay 1% of what you track" and "once you hit $2,500 in MTR" without saying which, and its FAQ answer was not readable, so treat the cliff as unverified until the answer is read. Compute the fee at the revenue just below and just above the limit before comparing providers.
• Vendor benchmarks: convert each percentage back to a count before comparing. A lead of one or two items on a sample of 30 is a tie. Record who ran it, the sample size, whether the inputs are public, and whether the cost figure is per valid result or per call. Example: treg's recruiter page (read 2026-10-23) reports 80% against 77% for the best single vendor on 30 candidates, which is 24 against 23 and was run by the vendor itself.
• Third-party comparison calculators and "X vs Y" pages: read the footer for who built it and what that person sells, open the inline cost function or the stated formula, and list every input the tool leaves out. Example: the calculator at sic.pricepush.app (read 2026-11-05) says it is "Built by the founder of PricePush, and it promotes his products", ranks four vendors by their published prices, leaves Purchasely out because it publishes none, shows "Native DIY" as the author's own hosting estimate of $15 to $120 a month, and excludes migration cost although its author's post says migration "sometimes" costs more than years of fees. Use such a tool to find the pricing pages to read and never as the price evidence itself.
• Limits: rate limits, quotas, and features only in paid tiers. Also check whether a free tier ends at an eligibility threshold, and how long the migration window is after it ends. Example: Apple's Private Cloud Compute has no cloud API cost for developers in the App Store Small Business Program who hold the PCC entitlement and stay below 2 million first-time downloads, has daily usage limits, and gives developers 6 months to migrate after losing eligibility (developer.apple.com/private-cloud-compute/, read 2026-10-22).
• Vendor benchmark footnotes: read the chart's footnote before the headline. Check the number of tasks and tries, who ran it, what the cost counts (model tokens only, or also build and hosting), whether the tested system used pre-built artifacts, and whether every comparator reports every metric. Example: Pomerado's launch chart (30 tasks, one try each, vendor-run) compares "Codex calling Pomerado's pre-minted tools", counts only model tokens at list price, and shows no cost for two named comparators, so "10-1000x cheaper" rests on one baseline, $13.63 per task, and one task is 3.3 accuracy points. Quote only the ratio the printed figures support, such as 8.4x for $13.63 against $1.62.
• Runtime limits: deploy or bundle size, memory, CPU time, and request duration, from the provider's main limits page and its changelog. Size these against the planned growth, not today's code, because a limit hit later splits the system along the limit instead of along the design.
• Data: the region where data is stored and processed, retention (the minimum and whether it can be shortened), whether a data processing agreement (DPA, the GDPR contract with a processor) exists, whether data is used for training, and sub-processors.
• Self-hosted "free" claims: list each feature with the paid plan or third-party key it needs, and whether the platform wants a payment method on file even on its free tier. Record whether the software sends telemetry by default and how to turn it off. Compare the claimed setup time with the README. Example: a tweet said Minilytics deploys "in 2 minutes", its README says "about 10 minutes", needs a Cloudflare account and Node, covers about 10k pageviews per day on the free plan, and updates by git pull and redeploy (read 2026-10-26). Also check how old the repository is and who commits to it, because a days-old repo with one contributor account has no update track record (inference). Also list what the operator runs and owns: the database and its version, the update path, any default login, backups, and who gets the data if the server dies. Price the hosted tier of the same product as the alternative, so the decision compares a VPS you maintain with a plan you pay for. Example: Umami is MIT, needs PostgreSQL 12.14 or newer, updates by pulling the Docker image and recreating it, and creates an admin login with password umami on first setup. Its cloud pricing page lists Hobby at $0 (100K events a month, 1 website, 6 months retention) and Pro at $20 a month (1 million events, up to 20 websites, 2 years), while self-hosted data is kept until you delete it (umami.is pages and README, read 2026-11-04).
• "Open source" claims: read the LICENSE file itself, because the repository badge can be NOASSERTION or a standard name with added terms. Record any clause that limits hosting, resale or commercial use. Example: superdesigndev/treg (read 2026-10-23) is Apache-2.0 plus a ban on offering it as a hosted service to third parties, so it is source-available, not open source. Also list what the open source repository does not contain. Example: Pomerado (read 2026-10-26) is MIT with a LICENSE file, but its README says hosting, saved logins, the managed browser fleet for bot protection and automatic repair of broken integrations are in the paid Pomerado Cloud, and building an integration needs an OpenAI API key. The launch thread's "self-healing" and stealth claims therefore describe the hosted product and not the repo. Versions 0.1.2 and earlier were AGPL-3.0-only, so check which version a claim was made about.
• Inputs and outputs: what the API accepts, such as text only or images, and in what formats.

When a source cannot be found, say "unverified" and name what would verify it. Never present an assumption as a fact. Never ask the user to look something up that a fetch could answer.

Step 3: Cost by kind and scale

Break the cost down, per option, at three or more user counts (for example a small, a medium, and a large monthly user count):

• fixed monthly cost
• usage cost, with the unit and the assumption behind it
• one-off build hours, including porting existing code, with the basis for the estimate
• upkeep hours per month
• legal and compliance work, such as DPAs, policy changes, and security reviews
• exit cost: what leaving would take

Give best, typical, and worst cases where the uncertainty is real. State the evidence for every estimate, and say which figures are guesses.

Step 4: Measure what the decision depends on

When performance matters, measure the path the decision depends on, not the easiest path to measure. Latency to a CDN edge serving public data says nothing about authenticated writes to the primary database. If you chart anything, chart that metric, and label the chart with what it does not show.

Step 5: Recommend

End with one recommendation, covering:

• the concrete flow the user or the team gets
• the monthly cost range
• the harm it avoids
• what would make you switch, as a staged plan with triggers (for example, "move <component> to X past <N> monthly users")

If a gatekeeper blocks the preferred option, say so first and give the best route around it. Put the choice on an answer sheet (see answer-sheet) when it is one of several open decisions.

Output

• the field map: providers, competitors, gatekeepers, and competing products
• the evidence table, with the claim, source URL, date read, and quote
• the cost table by kind and scale
• measurements, if any
• the recommendation and switch triggers
• unverified items and what would verify them

Pitfalls

• A first estimate stated confidently gets anchored on. Give ranges until they are verified.
• An earlier approval does not survive new evidence. If a gatekeeper clause invalidates an approved design, say so plainly and bring it back for a decision.
• Correct your own earlier wrong claims explicitly, naming what was wrong.