We built DynoWeb because we kept guessing
We ran a Shopify agency. We had the data, we had the clients, and we still could not answer the only question that paid: which specific thing should we change, and did it work?
Source: Baymard Institute — average of 50 studies, 2006–2025
How we got here
- 01
We started as a Shopify agency
Before DynoWeb was a product it was client work — themes, migrations, speed work, the occasional full rebuild. One conversation kept repeating regardless of who was on the other side of it: traffic is fine, sales are not, what should we change?
We could always show a merchant where the funnel dropped. That is the easy half. Knowing that a page converts badly tells you nothing about which part of it to change.
- 02
Every project ended in a claim nobody could check
So we guessed, professionally. Propose a redesign, move the reviews up, rewrite the product copy — reasonable changes made for reasonable-sounding reasons, none of them tied to evidence about that particular store.
Then the change shipped and nobody could say whether it worked. Sales went up that month, but so did the season, the ad spend and the SKU count. We were charging real money for work we could not prove.
It was not a skills problem. We knew Shopify. The gap sat between the data we had and the decision we had to make, and no amount of experience closed it.
- 03
First we ran the tools that already existed
Hotjar, Microsoft Clarity, Lucky Orange, Crazy Egg — free ones and expensive ones, in parallel, across client stores, for months. They were good. Several still are, which is why our comparison pages name the cases where they are the better buy.
They all stopped in the same place. Each one showed what happened with real clarity and then handed the finding back as a chart or a recording. Someone still had to turn that into a specific edit to a specific theme file, and someone still had to decide afterwards whether it had worked.
They also did not know they were looking at a store. A page-and-event data model can describe a storefront, but it cannot reason about variants, cart composition or order value until you wire that up yourself. We wired it up. For every client, every time.
- 04
Then we built the part that was missing
The design constraint was one sentence: a finding is not finished until it is a change you can approve and a number you can check. Heatmaps and session replay find where. AI suggestions turn where into what. Impact and revenue attribution answer whether it worked. A feature serving none of those three did not get built.
About six months went into the parts nobody sees: capturing behaviour without slowing the storefront down, and making the data commerce-aware rather than generic. Getting a suggestion specific enough to be worth reading took the most rework of anything. “Improve your product page” is noise. Naming the element, showing what the data said, and attaching a change you can preview is a task. Most of the product lives in the distance between those two.
- 05
We tested it on real storefronts, not demo data
Real merchants, real traffic. Some of them are on the case studies page. That is where we learned the interesting findings are almost never in the aggregate numbers — they are in one element, at one scroll depth, on one device.
It is also where we learned how differently mobile and desktop shoppers behave, and how completely a blended average hides it. Several of the most useful things the product does exist because a merchant showed us something we had filed as an edge case and was not.
Everything we could see, and everything we still had to guess
This is the list we kept running into on client projects. The left column was solved years ago. The right column is the one that decides whether a month of work made any money.
| What the tools showed us | What we still had to decide | |
|---|---|---|
| Drop-off | The step where sessions ended | Which element on that step to change first |
| Friction | A recording of a shopper hesitating | Whether the hesitation was price, sizing or shipping |
| Mobile | That mobile converted worse than desktop | Which mobile-only layout problem was costing the most |
| Result | That revenue moved after we shipped | Whether our change moved it, or the season did |
Where the other one wins: For observation on its own, the incumbents were better than anything we were going to build in-house, and on a site that is not a storefront they still are. That is why we link to them.
Three rules that came out of the agency years
- 01
A finding must arrive with a change
An insight you have to translate into a task usually never becomes one. If we cannot say what to do about something, it does not belong in the product.
- 02
Measure it or do not claim it
Every applied change is compared against its own baseline. We built Impact because we spent years unable to prove our own work, and we would rather nobody else was in that position.
- 03
Say when we are not the answer
Some stores need surveys, or live chat, or margin reporting. Our comparison pages say so, and our free plan is a real plan rather than a countdown. A comparison that never concedes anything is an advert.
The two of us
The agency was ours, so was the guessing. We are the ones you get on a call.
Stop guessing. Fix it and see the money.
That sentence is not a slogan we workshopped. It is the thing we could not do for our own clients, written down.