InSite
A product concept for multi-store Shopify monitoring: watch what changed, then show what it did to the numbers.
Role: Concept, product design, business case
Status: Written proposal, not built
Date: January 2025
Where it came from
Running ten-plus Shopify Plus stores at once, the same failure kept repeating. Something changed on a client site, sales moved a week later, and reconstructing the connection meant logging into each store separately and guessing. The information existed. It was just scattered across theme versions, app installs, script tags, and whatever anyone happened to remember.
The tooling that exists watches one store, or watches uptime. Nothing correlated a change to its consequence across a portfolio.
What it does
InSite installs on each store through Shopify OAuth, then does three things:
- Aggregates. Themes, script tags, apps, products, and orders across every store in one dashboard, so you stop logging in one at a time.
- Logs changes. Webhooks record admin actions as they happen. A price edit, a theme modification, a new app. Each one timestamped.
- Correlates. Scheduled reports place those changes next to performance and sales data, so a drop has a candidate cause instead of a shrug.
The design also links GitHub commits to live store changes, which closes the last gap: knowing whether a dip followed a deploy or something someone did in the admin.
The business case
I costed it as a product, not a side project. Roughly $30,000 to build. Sold to other agencies at $300 to $500 per month, 20 to 50 agencies puts payback somewhere between two and six months.
Those are projections, not results. The proposal was never built. I am including it because the thinking is the point: spotting a recurring operational failure, designing a system that addresses the cause rather than the symptom, and pricing it honestly enough that someone could say yes or no.
What I would change now
The correlation claim is the weak part. Placing a change next to a sales dip is suggestive, not causal, and a report that implies otherwise will eventually be confidently wrong. If I built it today I would show the change log and the metrics together and let the operator draw the line, rather than having the tool assert it.