The script that got blamed
Before Raptify, my team built an entire A/B testing platform for Shopify stores. Once in a while, a store felt slow and sometimes we'd catch the blame. Rare, but never cheap: proving a negative with no data is miserable.
Before Raptify was a product, our team was the third party.
My company, RoushTech, built an A/B testing platform for Shopify stores, end to end: the backend, the dashboard, and the script that embeds itself on every storefront that installs it. For that last piece, one of the platform's founders handed us the brief early in development: push the envelope on low-impact tracking.
Fast was the whole point
You give RoushTech an open door like that, we'll take it. Zech Sloan, the engineer on my team who led the embedded script (amongst many other complex parts of the system), is one of the best engineers I've ever worked with, and what he built was impressive: a script benchmarked until it was nearly imperceptible, making its decisions in the browser in a blink and then getting out of the way. We measured it obsessively, because a tool that exists to lift conversion has no business costing page speed, and speed is conversion.
I was proud of that work. I still am.
We still got the call
And once in a while, a merchant's site felt slow, and suspicion landed on us anyway.
It was rare. A handful of stores, out of everyone running the script. But it cost us real time and money, and the reason it happened at all is worth understanding. It was not because the evidence pointed our way; there was no evidence, that was the whole problem. It usually came down to the last platform someone remembered installing.
Here is what those conversations had in common: nobody had data. No scan history, no logs. If we were lucky, the site had been checked by hand once, months earlier. Usually it had never been checked at all. Sure, the site felt "slow," but when did it start? Was it really us?
So proving it was not us meant reconstructing a crime scene. Pull the page apart. Benchmark our own script again, for the hundredth time. Inventory everything else running on the storefront and eliminate suspects one at a time. We always found the real cause in the end (not us). It was never fun, never quick, never cheap. A few incidents a year was all it took to burn days of senior engineering time on questions that should have taken one glance at one chart.
The chart nobody had
Because that is all it needed to be: a chart. The same pages, measured daily under the same conditions, every result kept, with every tool on the page named and dated. With that in hand, "is it the new script?" stops being an investigation and becomes a lookup. Either the trend moved on the day the script arrived, or it did not. Innocence or guilt in one glance, for us and for every other vendor on the page.
I went looking for a platform I could simply point merchants at, and what I found made nobody happy: expensive, lacking features and visibility, usually feeling cheap. Nothing we could put our name behind as something we'd want people to use.
Born of a need
So, like most of my projects, Raptify started as something I needed myself: every page that matters, scanned daily under identical conditions, graded, trended, and inventoried, so that when something changes, the chart says what changed and when.
Notice that this cuts both ways, and I like it that way. A monitoring platform built by a former third-party vendor keeps vendors honest, mine included. If a script is dragging a storefront down, the trend line says so, no matter whose name is on the invoice. And if it is not, nobody burns a week proving it.
If your site feels slow and you are about to blame the last thing you installed, get the chart first. Start with a free scan. Your next vendor conversation will be shorter, whichever way it points.