Every SEO platform has the same dependency at the bottom of the stack: a reliable supply of search results, for a lot of keywords, across a lot of locations, every day. And every founder building one faces the same early decision about whether that supply is something to build or something to buy.
The decision is usually framed as a cost comparison, which is the wrong frame. The right question is whether collection is part of your product, and for almost every SEO platform the honest answer is no. Customers pay for the analysis, the workflow, the reporting and the interface. Nobody has ever renewed a contract because their vendor was good at parsing result pages.
What you are actually buying
A SERP API looks like a convenience until you enumerate what running collection yourself involves.
Parsing maintenance. Result page layouts change without notice, and every change is a silent data-quality incident on your side. This is the recurring cost that surprises teams, because it never finishes and it always lands at an inconvenient time.
Geographic coverage. Localised results require requests from inside each market, which means either a residential network with country and city targeting or an API that handles it. The mechanics of why are in why accurate rank tracking requires residential proxies.
Throughput and pacing. Search engines throttle, so throughput is a function of distribution and politeness rather than of how many workers you run.
Uptime that is not yours to control. If your product promises daily updates, your collection layer inherits that promise.
Buying a SERP API converts all of that into a request and a response. Building it converts it into a team’s ongoing responsibility. Both are legitimate; the second is only correct if collection is genuinely differentiating for you, which for a platform selling insight it usually is not.
The unit economics that decide the model
Whichever way you go, the number that governs your business is cost per tracked keyword per check, because it multiplies by everything.
Work it out explicitly. A customer tracking 500 keywords, checked daily across two locations and two devices, is 2,000 checks a day, 60,000 a month, for one account. At a hundred accounts of that size you are at six million checks a month, and a fraction of a cent either way becomes a line item that decides your gross margin.
That arithmetic drives three product decisions most founders make implicitly and should make deliberately.
What your plan tiers actually meter. Keywords tracked is the natural unit to sell, but your cost is driven by checks, which is keywords multiplied by locations, devices and frequency. Plans that sell keywords while allowing unlimited locations invert your margin on exactly the customers who use the product most.
Default check frequency. Daily is the expectation, but a meaningful share of tracked keywords barely move, and adaptive frequency, checking volatile keywords more often and stable ones less, cuts cost substantially without customers noticing a difference in what matters. Identifying volatility requires the full result set, which is the argument in detecting SERP volatility.
Deduplication across tenants. Multiple customers frequently track the same keyword in the same location. One check can serve all of them if your architecture stores results keyed by keyword, location and device rather than by customer. At scale this is often the single largest cost saving available, and it is very hard to retrofit, which is why it belongs in the first schema rather than the third.
The architecture that survives growth
The shape that works is boring and worth getting right early.
Separate the collection layer from the customer layer. Collection is keyed by the measurement, meaning keyword plus location plus device plus timestamp; customers subscribe to measurements. That separation is what makes deduplication possible and makes rate limiting a global concern rather than a per-customer one.
Store the full result set, not just each customer’s position. Competitor movement is what makes a customer’s own movement interpretable, features like AI overviews change what a position is worth, and you cannot go back for last Tuesday’s SERP. Storage is cheap; a missing history is not.
Schedule with freshness tiers rather than one daily job. Enterprise accounts may need morning delivery, self-serve tiers can be spread through the day, and spreading is free throughput.
Record failures explicitly, because in a multi-tenant product a gap becomes a support ticket. A missing day that looks identical to a stable day is the fastest way to lose trust in your own numbers, and the pipeline pattern is in automating daily keyword position monitoring.
What actually breaks at scale
Four failure modes account for most of the pain founders report.
Silent degradation in one market. Collection stops working for one country and the dashboards show flat rankings rather than an error. Guard with per-market success-rate monitoring and validation that a captured page is a real result page, per detecting blocked or fake content.
Measurement drift. A change in default location, device or timing produces movement across every customer at once, and support cannot distinguish it from a real ranking event. Pin those as constants and version them, per measuring accurate keyword rankings.
Cost surprises from a single account. One enterprise customer adding thousands of keywords across twenty locations can double your collection bill in a day. Meter at the check level and alert on account-level growth.
Support burden from disagreement. Customers compare your numbers to another tool’s and open a ticket. The answer is documentation of your measurement contract, which is also the thing that makes your data defensible: state the location, device, language and personalisation model you use, because two tools measuring differently should disagree.
Where to compete instead
If collection is a cost centre, the differentiation is everywhere above it: the analysis that turns positions into insight, share-of-voice and competitor movement, integration with the rest of a customer’s stack, reporting people will actually send to a client, and the workflow that tells someone what to do next. Those are the things customers describe when they explain why they stay, and none of them is improved by owning a parser.
Build collection only if your product’s value proposition genuinely includes something a general API cannot do: unusual surfaces, proprietary post-processing at the point of capture, or a scale where the economics invert. Those cases exist. They are rarer than the instinct to build suggests.
The bottom line
For a platform whose product is insight, search data is an input rather than a differentiator, so the build-or-buy question turns on whether collection is part of what you sell. Buying converts parsing maintenance, geographic coverage, pacing and uptime into an API call; building makes them a permanent team responsibility. Either way, model cost per check rather than per keyword, because locations, devices and frequency are the multipliers that decide your margin, and design for cross-tenant deduplication in the first schema since it is the largest saving and the hardest to retrofit. Separate collection from customers, store full result sets, record failures explicitly, and document your measurement contract so disagreements with other tools are explainable rather than embarrassing.
If buying is the answer, a SERP API supplies the parsed results with the geographic coverage already handled. If building is, the collection layer underneath is residential proxies with country and city targeting, billed per GB so your unit economics stay legible.