Everything here is held to the same list From a two-week fix to a full rebuild.
There is no price list, and there is a section below explaining what decides the number instead.
Before any of this means anything: the published checks apply to every engagement on this page, from a two-week fix to a full rebuild. They're published, they include the two this site can't demonstrate, and they're the thing to hold me to if you hire me.
What none of this has is a price list, and there's a section further down explaining what decides the number instead. That's deliberate, and it isn't evasion — it's that a range wide enough to be honest tells you nothing you can use.
The Build
A custom Shopify theme, built from your design — or from a redesign we do first if the current one is the problem.
What makes it different from a customised premium theme is where the decisions get made. A premium theme is built for ten thousand stores, and every customisation is a modification to something designed around someone else's assumptions. Six months in, the modifications are load-bearing, and the next platform update breaks one of them. That's the failure I get called about most: not a bad theme, a good theme carrying eight months of edits it was never built to hold.
Built custom, the sections are yours. Performance and conversion decisions are made during the build — what loads when, what defers, what renders server-side — rather than retrofitted after launch when every fix is a modification to a modification.
What it involves: a discovery pass on your customers and conversion goals, then staged delivery — structure, development, testing — with your review at each stage. The published checks before it ships. A handoff document and a defined first month after.
When it's the wrong call: if your store is doing fine on a premium theme and the problem is one specific thing, a rebuild is the expensive way to fix it. That is what the section below is for.
Performance work
A speed audit and the implementation that follows it. Most stores have three or four things costing them seconds, and they're rarely the ones people expect — it's more often an app nobody audits and a hero image nobody sized than it is the theme.
The honest part about how this is priced: most of it is scoped and fixed like anything else. Some of it genuinely isn't — occasionally I can't tell how deep a problem goes until I'm in the code, and pretending otherwise would mean padding the estimate to cover the case where it's bad. When that happens I say so and we work hourly for that part, with a ceiling agreed before I start.
That's an exception, not the default. If a developer's default is hourly, the meter is the constraint on how carefully the work gets done.
CRO and UX improvements
Fixing the things on the path to checkout that are costing you sales — usually mechanical rather than persuasive. A size guide that opens over the buy button on mobile. A cart that loses its state on back-navigation. A search that returns nothing for the word your customers actually use.
What this isn't: a testing programme. I'm not going to run six weeks of A/B tests on a store that doesn't have the traffic to resolve them — most stores this size get more from fixing what's broken than from optimising what works. If you have the traffic for real testing, that's a different engagement and worth saying so.
White-label, for agencies
You bring the project, I handle the technical implementation, and your client never knows I exist unless you want them to. I work under your name, in your process, in your tooling — and I don't contact your client, during or after.
The rate is standing rather than quoted per project, because you can't price a client proposal against a number you have to ask me for.
The terms, the rate's shape, and what happens if I'm not here →
One problem, fixed and measured
Most people don't arrive with a project. They arrive with one thing that's costing them money — a checkout step that fails on some devices, a collection page that takes eleven seconds, a section that broke in an update. Small fixes is that: one named problem, diagnosed, fixed, and measured before and after.
Two to three weeks. Fixed scope, fixed price, and a before-and-after measurement on the thing you hired me to change — so the question "did that work" has an answer rather than an impression. The published checks apply to it exactly as they apply to a full build.
The price is fixed before we start and it doesn't move — that's the whole point of the shape. What it is depends on the problem, which is why it's quoted after the diagnosis rather than listed here.
It isn't a cheaper way to get a rebuild, and it isn't a trial. It's bounded because the problem is bounded — if what you have is six problems, this is the wrong shape and I'll say so rather than sell you three of these in a row. It also isn't available as a thing you can just buy: it's scoped against a specific diagnosed problem, which means either an audit first or a conversation where you already know exactly what's broken.
If you don't know which problem it is yet → If you already know →
Ongoing work
Two things exist and neither is a package yet: store health monitoring — performance and the checks re-run on a cadence, with a monthly note on what moved — and ongoing CRO work for stores with enough traffic to justify it.
I've done both informally and I've never packaged either, so I'm not going to put a price and a feature list on them and pretend they're products. If ongoing work is what you want, it's a conversation, and it usually follows a build rather than starting one.
Technical SEO
The part of SEO that lives in the theme: structured data that validates, canonical tags that point where they should, a crawlable structure, pages that don't block themselves, and the speed work that search engines have made a ranking input.
What this is not: keyword strategy, content, or link building. If you have an SEO consultant, this is the half of their audit that comes back as "the developer needs to implement this" — and implementing it properly is a theme job, not a plugin.
What I won't tell you is what it will do to your rankings. Nobody honest will. What I can tell you is whether the technical layer is doing the wrong thing, and fix it if it is.
Landing pages
A page built to convert one campaign — a launch, a paid channel, a specific product push — on your existing theme rather than bolted alongside it.
The distinction that matters: most landing pages on Shopify are built in a page-builder app, which means a second rendering system loading on top of your theme, its own scripts, and a page that doesn't inherit your speed work or your design system. It converts until it's the slowest page you own, and it's usually the one you're paying to send traffic to.
Built into the theme, it's a section set like any other — same performance budget, same checks, and it survives the next theme update because it isn't a separate thing.
When it's the wrong call: if you need twenty variants this quarter and nobody technical to make them, a page-builder is genuinely the right tool and I'd rather say that than sell you a bottleneck.
What decides the number
What a Shopify build costs is decided by scope, not by hours: how many templates, how much of the design is settled before development starts, how much has to be migrated from the existing store, and how much of what's there is worth keeping. A quote that arrives before someone has looked at your store is a quote for a store they haven't seen — which is why the number comes after the audit rather than from a page.
Scope, not hours, is a deliberate choice and it changes what you're buying. Hourly billing makes speed my problem and thoroughness yours — the checks are the first thing to go when the meter is the constraint. Fixed against a defined scope, they're included by definition, and finishing faster is my gain rather than your loss.
What actually moves the number, in the order it usually matters: how many distinct templates the store needs; whether the design exists or has to be worked out during the build; whether products, content and URLs have to be migrated; how much custom logic sits between the customer and the checkout; and how much of the existing theme is worth keeping rather than replacing.
On the comparison to the cheap end, which is the real question: a $500 theme install and a build are different products, and the gap doesn't show up in a screenshot. It shows up eight months later, when an update breaks a section nobody can find. That's not an argument against premium themes — plenty of stores should be on one, and if yours is doing fine, the honest answer is to leave it alone.
The staged-payment structure means you're never far ahead of the work — deposit, milestones, final on launch. Terms are below.
Why there's no range on this page. I could publish one wide enough to be true, and it would be wide enough to be useless — the honest span across the work on this page is large enough that it would tell you nothing about your store. What tells you something is the audit: $299, credited against the work if you go ahead. Send me the store →
The terms
These aren't negotiated per project — they're how I work, and they're here so you can hold me to them.
- Staged payment
- Deposit, milestones, the rest on launch. You're never far ahead of the work.
- Two rounds of revisions, defined
- Beyond that is a scope change, said out loud rather than absorbed quietly and resented.
- A warranty period
- If something breaks because of my code, I fix it at no charge inside a warranty period of one month after launch — on the work as built, not on new requests — .
- You own everything
- The code, the repo, the deployment. No proprietary platform, no licence that ends if we stop working together.
- A defined first month
- What's covered after launch, what isn't, in writing before you start.
Questions about the work
Why aren't there any prices on this page?
Because the honest range is too wide to help you. A build can be a template migration with three custom sections or a full rebuild with bespoke logic on every conversion path, and one number covering both tells you nothing about which one you need. The audit is $299 and it comes off the work if you go ahead — that's the fastest route to a real number, and it's a real number rather than a range.
Can you give me a ballpark on a call?
Yes, once I know what the store is. What I won't do is give you one before that, because a ballpark from a stranger who hasn't seen your store is a number that will change, and the version you remember is the first one.
How long does a build take?
Six to eight weeks is typical for a full build, two to three for a fix, and the variable is usually not development — it's how long content and assets take to arrive. I'll tell you what I need and when I need it before we start, because that's the part that moves timelines.
Do you work with agencies?
Yes, white-label, and there's a page for it. For agencies →
What if I only need one thing fixed?
That's the most common way people arrive, and it's a defined engagement rather than a favour. It's scoped against a diagnosed problem — so either the audit first, or a conversation if you already know exactly what's broken.
What happens if we don't work well together?
Staged payments mean you can stop at a milestone, and you own everything up to that point. I'd rather that than a contract that traps us both — and in the cases where it's happened, it's usually been visible by the end of the first stage.