Fixed scope
Fixed price
against a written scope
- Written scope and acceptance criteria up front
- Fixed price against that scope
- Staged delivery with review points
- Change requests priced separately, never absorbed silently
Shopify tech audit and consulting
A written, evidence-backed read on what is actually wrong with your store — theme code, app stack, data model, performance, accessibility and SEO — with findings ranked by what they cost you, not by how easy they are to fix.
An audit you can act on without us
Most audits are a sales document with a findings section attached. Ours is a deliverable: numbered findings, the evidence behind each one, the estimated cost of leaving it, and enough detail for any competent developer to fix it.
Ranked by revenue, not by severity theatre
A list of eighty issues sorted by CSS lint severity helps nobody. We rank by estimated impact on revenue and risk, so the first five items are the ones worth doing this month.
Where we cannot estimate impact honestly we say so and mark it as such, rather than inventing a percentage to make the report look decisive.
What the audit covers
You can take it to anyone
The report names files, lines, queries and apps. It does not require us to interpret it, and it does not end with a proposal you have to accept to get value from the work.
Plenty of clients take the audit, fix half of it in-house, and come back for the half that needs specialist time. That is a good outcome.
Talk to us
What we measure with
Real data from your store, not a synthetic run against a homepage.
Field data
Chrome UX Report and your own analytics — what real visitors experienced, not a lab score from one run on a fast connection.
Lab profiling
Per-template traces to attribute cost to specific scripts, images and queries rather than to the theme in general.
App stack analysis
Every installed app inventoried with what it injects, what it costs on first paint, whether anything else already does the same job, and whether it is still maintained. Removing apps is the most common recommendation we make.
Code review
Theme Liquid, sections and JavaScript read for N+1 collection queries, unbounded loops, blocking scripts, dead code and anything that will not survive the next Shopify API version.
Data model review
Product types, options, metafields and collection logic — the layer that quietly caps what merchandising and search can do.
Accessibility & SEO
Keyboard paths, contrast against real backgrounds, heading order, structured data, canonicals and crawlable filter states.
What the audit covers
Six workstreams. You can commission all of them or only the ones you suspect.
Performance
Core Web Vitals by template against field data, with cost attributed to specific assets, scripts and apps.
App stack
What each app costs, what overlaps, what is abandoned, and what could be replaced by theme code you already own.
Findings you can hand to a developer
Every finding names the file, the line, the query or the app, includes the trace or screenshot that proves it, and carries an effort estimate. No item reads "improve performance" — that is not a finding, it is a wish.
- File and line
- Evidence attached
- Effort estimated
Ranked by what it costs you
Sorted by estimated revenue impact and risk against effort, so the top of the list is what to do this month. Where impact cannot be estimated honestly, it is marked unestimated rather than given an invented number.
- Revenue impact
- Risk
- Effort
Data model & scalability
Where the current taxonomy and metafield schema will stop you, and what it would take to fix before it becomes urgent.
Accessibility & SEO
Keyboard and screen-reader paths, contrast measured on real grounds, structured data, canonicals and filtered-URL handling.
Audit first, or just start fixing?
Sometimes the fix is obvious and an audit is a delay. Here is roughly where the line falls.
| Start fixing immediately | Audit first | |
|---|---|---|
| You know exactly what is wrong | Faster | Unnecessary overhead |
| Symptoms but no cause | Guesswork, often expensive | Finds the actual cause |
| Several vendors blaming each other | Stalls | Independent evidence |
| Considering a rebuild | Risk of rebuilding the same problems | Tells you if a rebuild is needed |
| Inherited a store | Unknown unknowns | Maps what you actually own |
| Board or investor scrutiny | Hard to evidence | A document you can circulate |
| Budget is tight | All budget to fixes | Some budget to diagnosis |
| Best when | The problem is narrow and known | The problem is broad or contested |
How we work
How an audit runs
7 stages. Open any one of them.
Setup
Read-only, scoped.
A collaborator account with the access we need and nothing more, plus analytics and Search Console. We tell you exactly what each permission is for.
Data collection
Field first, lab second.
Real-user data by template, then lab traces to attribute cost. Field data decides what matters; lab data explains why.
Code and stack
Reading, not scanning.
Theme Liquid, JavaScript, app inventory, data model and integrations, read by a developer rather than summarised by a tool.
Reproduce every finding
No finding ships unproven.
Each issue reproduced and evidenced before it goes in the report. Anything we cannot reproduce is dropped, not softened into a maybe.
Prioritisation
By cost, not by category.
Estimated revenue impact and risk against effort, with unestimated items marked honestly rather than padded with a number.
Report and walkthrough
A document plus a conversation.
The written report, then a session with your team to work through it and answer questions. The report stands alone if you never speak to us again.
Optional follow-through
Only if you want it.
We can implement the findings, or hand them to your team, or sit in on their planning. No part of the audit’s value depends on choosing us.
Ways to engage
Three shapes, depending on how well defined the work is. Every one starts with a scoped written proposal — no work begins on a verbal estimate.
Retainer
Monthly
block of hours
- A block of hours each month
- Prioritized by you, replanned as often as you like
- The same developers month to month
- Reporting on what the hours went to
Time & materials
Tracked time
billed as used
- Billed against tracked time
- Suits discovery, R&D and migrations
- Estimate per ticket before it starts
- Stop or change direction at any point
Rates are quoted against a written scope rather than published as a tier, because the same service costs very different amounts on a five-template store and a five-hundred-template one.
Context
The categories we build for
The audit is the same. Which findings turn out to matter is almost entirely a function of the category and the catalogue.
Fashion & Apparel
Beauty & Cosmetics
Food & Beverage
Jewelry & Luxury
Home & Outdoor
Electronics
Health & Supplements
Subscription
Sports & Fitness
Multi-region
Marketplace & Multi-store
Questions about tech audits
A Shopify tech audit is a written, evidence-backed review of what is actually wrong with your store — theme code, app stack, data model, performance, accessibility and SEO — with findings ranked by what they cost you rather than by how easy they are to fix. Every finding names the file, line, query or app, carries the evidence that proves it, and includes an effort estimate.
A Shopify collaborator account with theme and app read access, plus analytics and Search Console. Read-only is enough for the audit itself, and we list exactly what each permission is used for before you grant anything.
Yes — that is the point. Findings name the file, line, query or app and carry the trace or screenshot that proves them, so any competent Shopify developer can work from the report without talking to us.
No. Plenty of clients fix most of the findings in-house and come back only for the parts that need specialist time. An audit that only has value if you buy the follow-on work is a sales document, not an audit.
Automated scans find what tools can detect — image sizes, missing alt text, obvious render blocking. They cannot tell you that two Shopify apps do the same job, that your option structure will cap search, or that a section runs an N+1 query on a 400-product collection. Those need a developer reading code.
Yes. For an app we look at API version currency, deprecation exposure, compliance webhooks, billing correctness and data retention — the four areas that account for most of what we find wrong in inherited apps.
Only if the evidence says so, and we will show you the evidence. More often the answer is a targeted set of fixes, because a rebuild that carries the same data model and app stack forward reproduces the same problems at higher cost.
It scales with store complexity and how many of the six workstreams you commission — performance, app stack, code, data model, accessibility and SEO. We scope first and quote against a written scope.
Annually is reasonable for a store under active development, or whenever something has changed materially — a replatform, a significant app addition, or a traffic drop nobody can explain.
Something is wrong and nobody can say what
That is the situation an audit is for. Tell us the symptoms and we will tell you what we would look at first.