A property-investment platform was paying a third-party service to fetch listing data. It worked, in the sense that data arrived — but nobody could see what was happening inside it, and the bill kept climbing.
What we found
Structured logging across every stage made the invisible visible, and it was worse than anyone expected:
Over half the daily work was being silently abandoned. Jobs were timing out mid-run and quietly dropping what they hadn't finished.
One dead link had consumed a month's API budget by re-fetching itself every five minutes, forever, with no retry cap.
An image-analysis agent was firing three AI calls every two minutes, around the clock, against a dataset that barely changed.
What we built
Rather than pay for more capacity, the work was re-architected: a purpose-built scraper using Python, residential proxies and real browser sessions replaced the paid service, and the enrichment step moved from a synchronous request that always timed out to a paced background worker that doesn't.
A platform that does several things at once is hard to explain on one page. The usual answer is a wall of static screenshots, and the usual result is that people stop scrolling before the product has been explained at all.
What was built
A single scrolling page, around eight thousand pixels tall, that introduces the product in sequence rather than all at once. The central section steps through listen, understand and act as a cross-fading sequence, so one idea lands before the next arrives. Supporting sections use inline video and illustrated SVG rather than screenshots.
The engineering decision
Sixty animated elements, and no animation library. The scroll reveals, the cross-fading sequence and the rotating diagram are hand-written CSS transitions driven by an intersection observer, in roughly eight kilobytes of inline script. The common alternative is to load a general-purpose animation framework and use a fraction of it: a typical scroll-animation bundle costs every visitor fifty to seventy kilobytes before a single element has moved.
The trade is real: hand-written motion takes longer to build and there is no library documentation to fall back on. It is worth it on a page whose entire job is to hold attention, because the thing you are asking the reader to wait for is the page itself.
Stated plainly. StaffCircle is where Caius works part-time, not a ProductConsult client. No engagement or scroll-depth figure is claimed here, because none was measured. The page is public, so the build can be judged directly: staffcircle.com.
Testing cold-email copy the usual way is slow and wasteful: you split traffic evenly, wait weeks for significance, and spend half your sending volume on the variant you already suspect is worse.
What we built
A system that treats every message variant as a competing option and continuously shifts sending toward whichever is earning genuine replies. It never stops adjusting, so there's no moment where someone has to declare a winner.
Signal filtering
It scores engagement by how fast it arrives. Corporate inbox scanners open and click within milliseconds of delivery, which is enough to poison any naive open-rate measurement. Anything arriving at machine speed scores zero, so the system optimises for real human interest rather than inflated numbers.
217%
more positive replies
19%
on a 10,000-lead campaign
14.2%
for a separate business
Each measured against an equal-split baseline. The 217% is our own acquisition campaign; the 19% was a campaign at StaffCircle, where Caius works part-time. Stated plainly so you can weigh them accordingly.
