Most visual change detection tools are open source. Several install with a single command. On paper, building your own looks like the sensible alternative to paying for a subscription.
This post is about what that decision actually costs. The short answer: the cost is not in the setup. It is paid over the eighteen months after it.
Why "build it ourselves" looks appealing
Four reasons, and all four are legitimate:
1. No monthly cost. You are not paying a subscription.
2. The data stays with you. Screenshots and page content live on your own infrastructure. For client data, that is a real advantage.
3. You build what you need. If you need a check no off-the-shelf tool offers, you add it.
4. No external dependency. If a vendor shuts down or raises prices fivefold, your own infrastructure does not change.
All four are true. The problem is that the cost outside those four is invisible when you make the decision.
Cost 1: Storing the images
This is the item that surprises people on the first invoice.
Every site, every scan, downloads a screenshot. Thirty sites, once a day, for two years: twenty-two thousand images.
Do that arithmetic. Screenshots look small — a PNG is 100–300 KB. But twenty-two thousand of them at an average of 200 KB is 4 GB. Over two years. Add five more sites and it is past 5 GB.
What that costs:
- Storage. Money on cloud storage, or disk on your own server.
- Backups. A backup you do not take is not an archive. Backups cost the same again.
- A retention policy. How long do you keep them? A directory that grows without limit fills the disk one day, and on that day the whole system stops — not just the archive.
This is the cost that "free" systems forget most often.
Cost 2: Browser infrastructure
Taking a screenshot means running a browser.
One browser instance is memory. Two hundred concurrent scans is two hundred browsers. As the queue grows, so does the requirement. Six months into a pilot you need:
- A browser pool
- Queue management
- Timeouts and retries
- Re-queueing work when a browser dies
None of that is monitoring. It is queueing — and queue software is more work than monitoring software.
Cost 3: Setting the threshold correctly
This is the most expensive item and the least discussed.
Comparison finds every difference between two moments. The clock changed. The counter changed. The ad rotated. The system reports all of them as changes.
Getting the threshold right requires:
- Running the system for at least two weeks to see what it actually reports
- Sorting the output into important / unimportant but frequent / unimportant and rare
- Setting the threshold to keep only the first group
- Repeating the two weeks
During those two weeks, no client hears anything. Because the system does not yet know what to tell them.
Losing two weeks is visible on day one. Losing it is invisible in month six, and by then the team has muted it. Alert fatigue is that cycle in full.
Cost 4: Dynamic content
The difference between monitoring a static page and a dynamic one is a difference in workload, not in difficulty.
Clocks, counters, stock levels, personalised content, third-party ads — all of it needs masking or thresholding. And every mask has to be updated when the page changes.
With your own infrastructure that is your responsibility. With an off-the-shelf tool it is too, but at least there is an interface for setting the threshold.
On its own that is a day of work, and it is the subject of false alarms on dynamic pages.
Cost 5: The things nobody mentions
The most expensive item is the one you never see.
A system you built carries the vulnerabilities of the code you wrote. The code that takes screenshots launches a browser; that browser carries its own.
This is precisely backwards from the "I control my server" argument: owning the server means more patch responsibility, more attack surface, and more components to keep an eye on.
In practice: the system stops quietly, nobody notices, and six months later someone asks "is the monitoring even running?" and the answer is: probably, nobody was looking.
Cost 6: Vendor risk
This is the one place where building your own is genuinely right.
A vendor shutting down, raising prices, or removing a feature is possible. You cannot predict any of it.
The honest answer here: you have bought that risk instead. So you avoid the monthly payment and take on maintenance debt. Both are real; which is cheaper depends on the size of your team and how many sites you monitor.
The comparison
The table below shows how to calculate it, not the results. Put your own numbers in.
| Item | Your own infrastructure | Subscription |
|---|---|---|
| Initial setup | High | None |
| Image storage | Your cost | Included |
| Browser infrastructure | Your cost | Included |
| Threshold tuning | 2+ weeks of your time | Usually ready |
| Adding a site | Configure and test | Usually a few minutes |
| Maintenance and updates | Continuous | The vendor's |
| Data control | Total | Usually total — but ask |
Look at the last row. On a subscription it reads "usually total — but ask". The reason is that for an agency handling client data, this is not a bargaining point. It is a question to ask and a written answer to get.
When building it yourself is the right call
Being honest, there are a few real cases:
- Client data is a legal constraint. If where the data lives is written into the contract, your options narrow.
- Auditability is mandatory. Some sectors genuinely benefit from running your own.
- The team is large and technical. If your core team can operate this kind of system, the arithmetic changes.
- Your needs are non-standard. There is a specific check no product offers.
And when it is not:
- A requirement shorter than twelve months
- No team that will inherit the maintenance
- A system started because it was "cheaper" and then nobody looked after it
- Deciding before you have set a threshold once
Summary
Building your own visual monitoring means image storage, a browser pool, queue software, threshold tuning and continuous maintenance. The initial build is the smallest part of that.
The price of not paying monthly is not money. It is time and attention — and most teams discover it in month six, by which point undoing it means shutting down the system you built as well.
For the technical side of the comparison, see what visual regression testing is; for the monitoring side, the multi-client guide; for choosing a tool, the seven questions.