An in-house competitor price tracker costs far more to maintain than to build. The fetching bill is the smallest line, parser upkeep and match review are the largest, and one engineer's ongoing attention decides whether the system survives its second year.
Build it when your matching problem is genuinely unusual. Buy it when your matching problem is ordinary, which it usually is.
What you are actually building
Teams scope this as "a scraper". It is six systems, and the last one is the expensive one:
- A fetcher that gets pages from sites that do not want a bot, with proxies, retries and a headless browser for the sites that need one.
- A per-competitor extractor that locates price, stock, delivery and identifiers in that specific shop's markup.
- A matcher that decides which of their listings corresponds to which of your products.
- A store with history, so you can answer what a competitor charged on a Tuesday in March.
- Monitoring that catches silent failure, which is much harder than catching an outage.
- A named person who owns all of it when it breaks in the middle of a promotion.
Fetching: the one line with a clean number
Work this out from your own catalogue rather than from anyone's pricing page.
Take 8,000 SKUs and 4 competitors. Refreshed once a day, that is 8,000 multiplied by 4, so 32,000 fetches a day and about 960,000 a month. Add retries and blocked pages at a modest 20% and call it 1.15 million requests a month.
Now apply the rate your own supplier quotes you. If unblocking or proxy capacity costs you somewhere between 0.50 and 3.00 euro per 1,000 requests, depending on whether a page needs a full browser, 1.15 million requests lands between roughly 575 and 3,450 euro a month. Get both ends quoted before you plan anything, because the split between plain fetches and browser-rendered fetches moves that bill by a factor of five or six.
Refresh rate multiplies everything. Hourly instead of daily is 24 times the requests, and in most categories it changes no decision you would actually have made differently.
Parser maintenance: the line that never ends
Every competitor needs its own extractor, and every extractor breaks when the shop redesigns, runs an A/B test, adds a consent wall or changes its currency formatting.
Assume each site needs attention twice a year. Twenty competitors is 40 repairs a year, which is one every nine days on average, since 365 divided by 40 is about 9. That is before the time spent noticing.
Silent breakage is worse than loud breakage. A selector that starts reading the crossed-out price instead of the effective one keeps returning a plausible number, and your rules keep acting on it. Budget for a canary per site: one known product with a known price, checked daily, alerting when the delta crosses a threshold you set.
Matching: the line teams forget to budget
With 8,000 SKUs and 4 competitors, a complete match set is 32,000 pairs. If automated matching leaves 15% needing human eyes, that is 4,800 reviews for the first pass alone.
At 20 seconds a review, 4,800 reviews is 96,000 seconds, about 27 hours of somebody's undivided attention. New products, delistings, relaunches and competitor range changes then produce a steady trickle for as long as the system runs.
This is the line that never appears in a build estimate and never stops appearing on a payroll.
A worked total, with the assumptions on the table
Change every one of these to your own numbers before drawing a conclusion:
- 8,000 SKUs, 4 competitors, daily refresh, 20 competitor sites
- Fetching at the middle of the range above, call it 1,500 euro a month, so 18,000 euro a year
- Infrastructure, database, queue, storage and monitoring at 300 euro a month, so 3,600 euro a year
- Half an engineer, fully loaded. Take your own annual cost per engineer and call it C: this line is C divided by 2. At C = 100,000 euro that is 50,000 euro a year
- Match review at 0.2 of an analyst. At 60,000 euro fully loaded, that is 12,000 euro a year
Sum: 18,000 plus 3,600 plus 50,000 plus 12,000 is 83,600 euro a year. Of that, 62,000 euro is people, which is about 74% of the total. The build itself sits on top as a one-off, and in most teams it consumes a quarter of an engineer's year before the output is trustworthy enough to act on.
Run the same sum with your own C, your own competitor count and your own refresh rate. The comparison people usually make, a licence fee against a proxy bill, is the wrong comparison and always flatters the build.
When building in-house is the right answer
- Your competitor set is small, stable and structurally clean. Ten shops with tidy markup is a different problem from 40 shops behind bot protection.
- Your matching rules are genuinely proprietary: construction assemblies, chemical grades, pharmacy pack equivalences or B2B contract units that no general matcher encodes.
- You already run a data platform with on-call and alerting, so this is a seventh pipeline rather than a new capability.
- Contractual or regulatory constraints mean the data cannot leave your own infrastructure.
If three of those four are true, build it. If only the last one is true, ask a vendor about deployment options before you write any code.
When buying is the right answer
Buy when your matching problem is ordinary, and when the realistic alternative is half an engineer who also has three other responsibilities and no time to notice a silent parser failure during peak season.
One warning that applies to both paths. Neither a build nor a purchase tells you what price to set. A tracker tells you what other people charge. Being cheapest is not the goal, and in most catalogues the money is found by raising the prices that sat below the market, not by chasing the low ones further down.
PriceRoom exists because that judgement is only as good as the matches underneath it, and correct matches are the expensive part whichever way you decide.