We built this because we kept guessing

How we got here

1. 01

   We started as an agency

   Before DynoWeb was a product it was client work. We built and maintained Shopify storefronts — themes, migrations, speed work, the occasional full rebuild. The work was good and the clients were happy, and the same conversation happened over and over regardless of who was on the other side of it.

   It went like this. A store owner would say traffic was fine but sales were not. We would look. Analytics would confirm the funnel dropped off. And then everyone would sit there, because knowing that a page converts badly tells you nothing whatsoever about which part of it to change.

2. 02

   The same wall, on every project

   What we ended up doing was guessing, professionally. We would propose a redesign, or move the reviews up, or rewrite the product copy — reasonable changes, made for reasonable-sounding reasons, with no way to know whether any of them were the actual problem.

   Then the change would ship and nobody could say whether it worked. Sales went up that month, but so did the season, and the ad spend, and the number of SKUs. Every project ended with an unfalsifiable claim. We were charging real money for work we could not prove.

   The uncomfortable part was that this was not a skills problem. We knew Shopify well. The gap was between the data we had and the decision we needed to make, and no amount of experience closed it.

3. 03

   We tried every tool we could find

   So we went looking. Heatmap tools, session replay tools, analytics suites, general-purpose behaviour products, the free ones and the expensive ones. We ran several of them in parallel across client stores for months.

   They were good, and several of them are still good — we say so plainly on our comparison pages. But they all stopped at the same place. They would show us what happened with real clarity, and then hand the finding back to us as a chart or a screenshot. Someone still had to translate that into a specific change to a specific theme file, and then someone still had to decide whether it 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 unless you wire all of that up yourself first. We wired it up. Repeatedly. For every client.

4. 04

   Eventually we built it ourselves

   The decision was less dramatic than it sounds. We had already built most of the connective tissue by hand, several times over, for different clients. Turning that into a product was mostly a matter of admitting we were going to keep doing it anyway.

   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. Everything in the product exists to close that gap. Heatmaps and replay find where. Suggestions turn where into what. Impact and attribution answer whether it worked. If a feature did not serve one of those three, it did not get built.

5. 05

   Six months of building

   It took about six months to get to something we were willing to put in front of a store. Most of that time went into things nobody sees: capturing behaviour accurately without slowing the storefront down, making the data commerce-aware rather than generic, and getting suggestions specific enough to be worth reading.

   That last one was the hard part and it is where most of the rework happened. A suggestion that says 'improve your product page' is noise. A suggestion that names the element, explains what the data showed, and comes with a change you can preview is a task. The distance between those two is most of the product.

6. 06

   We tested it on real stores

   We ran it on real merchants' storefronts with real traffic, not on demo data. Some of those stores are on our case studies page. That is where we learned that the interesting findings are almost never in the aggregate numbers — they are in a specific element, at a specific scroll depth, on a specific device.

   It is also where we learned how differently mobile and desktop shoppers behave, and how thoroughly a blended average hides that. Several of the most useful things the product does exist because a merchant showed us something we had assumed was an edge case and was not.

7. 07

   Why DynoWeb exists

   Because the gap between knowing and doing is where most store owners lose money, and almost nothing in the market was built to close it. Not because the existing tools are bad — because they were built to observe, and observing is only the first third of the job.

   We are still a small team, and we would rather be honest than impressive. That is why our comparison pages name the cases where a competitor is the better buy, why our case studies describe patterns rather than inventing percentages, and why the free plan is a real plan instead of a countdown.

Three rules that came out of the agency years

You can see all three at work in the merchant case studies and on the pricing page.