What it is
Most storefronts leak revenue in two or three specific places, and the owner already knows about one of them.
A storefront diagnostic finds the others, prices each one against your actual revenue rather than a benchmark, and tells you which to fix first.
Asynchronous, and you own the document at the end.
Who it's for
- A direct-to-consumer brand doing roughly $1.5M–$30M online, where conversion is one person's job among five
- A store whose last real performance pass was a theme migration
- A brand with a subscription or strong repeat purchase, where a small conversion change compounds across every reorder
- A team that has installed apps considerably faster than it has removed them
- A store that has had less of your attention lately than it once did, when what you want is the shortest way back to knowing what's happening in it
If your store is under about $1.5M, the fee is hard to justify against what I'd find, and I'll say so on the call rather than after the invoice. If what you want is a monthly arrangement without a diagnosis first, I'm the wrong person. I'd rather look at the store, tell you what's wrong, and let you decide from there.
What you get
One document. The verdict on your numbers first, then every leak I can find, ranked.
- 1
- 2
- 3
- Claim
- Evidence
- measured · screenshot · export
- Dollars
- a range, floor shown, arithmetic in the appendix
- Fix
- Effort
- small
Every problem I can find, ordered by estimated monthly dollars. Each one tied to something specific on your store: a number I measured, an element I found, a response I recorded. If a finding could be true of any Shopify store, it doesn't ship.
Inputs, sources, the discount applied to each published benchmark, and the cap. Not a confidence score. The actual steps, so you can rerun them and disagree with a specific one. The estimates are built to land under what your own analytics will eventually show.
The second half is usually the more useful one. Most stores carry a backlog of plausible improvements worth less, together, than one thing nobody has looked at yet.
Where your shipping cost first appears in checkout, whether your cart-recovery email actually fires and what it offers, and your real abandonment by device. None of this is visible from outside, which is most of the reason the diagnostic exists.
So the work gets checked against your analytics rather than against my model.
Everything lands as a document you own, in whatever you already use. A record shaped to me rather than to you gets abandoned within a quarter.
Why the numbers are worth trusting
I publish the method because it's the part most people won't put in writing.
- The dollar figures are deliberately too low.
- Every estimate starts from a published benchmark, then gets discounted, capped, and checked for double-counting before you see it. The goal is that your own analytics come in above my number rather than below it.
- Real-visitor data and lab tests are never mixed.
- If a speed number came from people who actually visited, it says so. If it came from a synthetic run, it says that instead. Different claims, labeled differently, always.
- I don't report an absence I might have caused.
- If my own compliance rules blocked the request that would have shown a feature working, the finding is withheld rather than reported as missing. Several rules in the tool exist only to stop it overstating.
- It's a polite, identified crawl of public pages.
- One request every 10–15 seconds, a user-agent that names me and how to reach me, and
robots.txtobeyed without exception, including the parts that make my job harder. Full details for your engineering team → - No login, nothing submitted, no payment field touched.
- Enforced in code and covered by tests rather than left to good intentions. If your store declines the traffic, I back off once and stop.
What the scan can't tell me
Being precise about the limits is what makes the rest of it worth believing.
Your storefront's own robots.txt closes the checkout to automated traffic, as
it should. So from outside, before you've hired me, I cannot see:
- The step where your shipping cost first appears, and whether it surprises anyone
- Whether your abandoned-cart email actually fires, how quickly, and what it offers
- How many people reach checkout and leave, and on which device
- Your real conversion rate, average order value, and where the drop-off concentrates
Those are usually where the largest and best-documented leaks live. They're the first thing we open together, with your authorization, on day one. It's also why every dollar figure I show you before then is labeled a model rather than a measurement.
What the engagement looks like
- Access, and your real numbers You grant read access. I run the checkout walk and the cart-recovery test that can't be done from outside, and we look at your actual conversion and abandonment figures together.
- The work Full scan, code-level review of what it surfaces, and every finding priced against your real revenue instead of a modeled band. Asynchronous, no standing meetings.
- The handover Ranked leaks with dollar estimates and arithmetic, a prescribed fix order, the list of what to ignore, and the re-measure plan.
- Then it's over No retainer, no upsell sequence. If you want the fixes implemented, ask and we'll scope it separately. If you'd rather hand the document to your own developer, that's what it's written for. One thing is offered at the readout and nowhere else: a one-time re-measurement, about sixty days after you ship the fixes, that shows whether they worked. It never renews.
Price
Every module, run against a single storefront. You'll have the observed range from your own scan before the number is quoted: it's set to your store on a 15-minute call, agreed in writing before I start, and it doesn't move after. Same scope at every size. If you bought the reconciliation first, its $1,500 comes off this in full.
Why the price is on the page
The audit shouldn't have a quote attached.
You've seen the other version: free audit, scary number, proposal on the last page. This is the opposite, on purpose. The entry price is public, the number we agree on the call is fixed in writing before anything starts, and the scope is fixed. The engagement ends when the readout is delivered, and there is no retainer waiting behind it. I find where the money is leaking; I don't sell the fix, so I have no reason to inflate anything.
The guarantee is conditional, and the condition is evidence. Where my scan of your store has already run, I set a threshold in writing before you commit: if the diagnostic doesn't find at least that much in recoverable annual revenue, or corrected measurement error, you don't pay and anything paid is refunded.
Who you'd be working with
Travis Austin
Product founder · store owner · principal UX designer · design-engineer
Goodspring is new. I'd rather say that than imply a client list I don't have. What I can show you instead is a scan of your own storefront, which is the only evidence that actually matters here.
My background is ecommerce measurement at Fortune 100 retail scale — two decades across enterprise design, product, and engineering — and the discipline that comes with it: making sure the numbers can be trusted before anyone acts on them. Storefront diagnostics is where that matters most, because a wrong number quietly costs a store money on every session while looking like a business problem.
You work with me directly. There's no team to be handed to, no junior doing the analysis under someone else's name, and the person on the call is the person who did the work.
Worth 15 minutes?
Screen shared, no deck. I walk what I found on your store, you tell me which parts you already knew, and we work out what's actually worth fixing first. If we're a fit after that, good. If not, you keep the list and I'll point you at whoever fits better.