Why you shouldn’t build your own ad screenshot product (if you must, use our API)
What nine years of capturing proof-of-placement screenshots taught us about building it yourself
Landon Bennett
You can build an ad screenshot tool in a week. We know, because we did back in 2017. A headless browser, an ad tag, a URL, a capture. In 2026 an AI coding tool will write some of it for you over a hackathon, and the first demo will look cool.
Nine years later, we’re still working on the problem every week. The prototype was never the hard part. The hard part is everything that comes after it, and that’s where most internal tools quietly die.
1. There’s no such thing as “just a screenshot”
The first surprise for teams that have tried to build in-house is that there’s no single definition of a good proof-of-placement screenshot. Every advertiser, agency and publisher has its own requirements, and they change by campaign: what has to be in the frame, which creatives and how many, which pages count, what’s brand safe, and how it all gets delivered.
Each requirement is small. Together they are a product. An internal tool usually supports the one client that prompted it, then breaks on the second, third and fourth.
2. The web doesn’t want to be screenshotted
Once you know what the client wants, you still have to get the right ad onto the right page and capture it. Publisher sites aren’t built for that. Ad formats keep changing. Pages are slow, crowded with pop-ups and increasingly defensive. Over the past six months we’ve watched more publishers add bot detection, likely in response to the rise in AI agent traffic.
None of these problems stays fixed once you’ve fixed it. An in-house tool usually finds out the hard way: a sudden drop in success rate and a pile of support tickets.
3. Quality is the real product
A screenshot that misses the client’s requirements, lands next to the wrong content or shows the wrong creative is worse than no screenshot. Someone has to check every one before it reaches an advertiser.
We check every screenshot automatically via agent validation, and anything that doesn’t pass goes to a human-in-the-loop for review in real time (with our own set of proprietary tools). That’s how we deliver 99% of requested screenshots. When a homegrown tool gets it wrong, there’s no backup. The fix is usually multiple team members (with $80-$150k salaries) doing it by hand, on a deadline. The exact thing you set out to avoid.
4. AI isn’t the product. Nine years of edge cases are.
Over the past year we infused our capture system with AI. It now handles far more of the long tail on its own, and our capture success rate and quality improved by an order of magnitude.
But the AI isn’t the moat. It runs on nine years of ad ops requirements, tools we’ve built along the way, and data from millions of site loads that tells us where to improve next. That’s the part a weekend build can’t copy. Customers who don’t want LLMs involved for data security reasons can turn it off.
5. The maintenance tax nobody puts in the business case
The build-vs-buy spreadsheet usually compares a subscription to a few weeks of engineering time. The real cost of building is the years after launch.
What you’ll own | Why it never ends |
Browser and rendering quirks | Browsers, ad servers and creative frameworks update constantly |
New and changing ad formats | Every client brings formats you haven’t supported yet |
Publisher site changes | Layouts, pop-ups and bot defenses change without notice |
Client-specific requirements | Every client wants something slightly different |
Device and geo coverage | Clients keep asking for newer devices and more markets |
Quality review | Someone has to check the output before it goes to an advertiser |
Infrastructure and on-call | Captures run at all hours, and failures land on whoever built it |
The people who end up owning this are usually an engineer who’d rather be on your core product (what happens when they leave?) and an ad ops team filing tickets against a tool nobody has time to fix.
6. If you build anyway, build on our API
Sometimes building is the right call. You want screenshots inside your own platform, in your own workflow, under your own brand. In that case, build the parts that are unique to you, like your interface, your workflow and your campaign data, and let us handle the capture and everything that keeps it working.
The Ad Reform API is a REST API for sending requests, plus webhooks that deliver results as soon as they’re ready. Ad platforms like Teads already use it to offer screenshots inside their own products. Our ad preview tech is available through the API too. If your team builds with AI coding tools, point them at the docs. You get the speed of building without rediscovering nine years of edge cases.
FAQ
Can’t we just use a headless browser and an AI coding tool? You can, and you’ll have a prototype quickly. The cost shows up shortly after: new ad formats, sites that change, client-specific requirements, bot detection and quality review. That ongoing work is what Ad Reform does all day, and we still have plenty to do after nine years.
How does Ad Reform use AI? AI handles most of the work of getting each screenshot right, and every result is checked before delivery, with our team reviewing anything that doesn’t pass. You can turn LLM use off for data security reasons.
Can we embed Ad Reform screenshots in our own platform? Yes. The API lets you request screenshots programmatically and receive results by webhook.
Which ad platforms do you integrate with? Google Ad Manager, DV360, CM360, The Trade Desk, AdButler and Xandr. See integrations.
Thinking about building it yourself?
Talk to us first. Send us the hardest screenshot your team deals with and we’ll show you how we’d capture it, or read the API docs and see how much of the build you can skip.
