White-label Shopify developer — for agencies

Every developer you're evaluating will tell you they're thorough. None of them will hand you the list you should be holding them to — which is why I've written one, and why it's built to be run on me as readily as on anyone else.

It's the same checks I run before any build of mine ships, rewritten for the other side of the table: what to ask, what a good answer sounds like, and what a bad one is disguised as. It is not a list of things I happen to be good at — that would be a spec sheet with a checkbox next to each of my features, and you'd spot it in thirty seconds.

Two things it's honest about up front. It's the same material that's published openly on this site — the checks, in full, no email required. The download is the format: a document you can put in front of a client or take into a shortlist conversation. And it will not tell you who to hire. It tells you what to ask, which is the part that's currently missing.

What's in the document

The checks, in the form of questions to ask. Each one rewritten from "what I verify before shipping" to "what to ask a developer, and what their answer tells you." The useful part is the second half — most of these questions get a confident answer from someone who has never run the check, and the document says what the difference sounds like.
What a good answer contains. Specifics: a number, a tool, a threshold. What a bad answer contains: a reassurance. "We follow best practices" and "we test thoroughly on all devices" are both bad answers to the performance check, and knowing that is most of the value here.
Most of them you can verify yourself, without asking anyone. The free instruments, what to point them at, and what a failing reading looks like. You can run these on a shortlist before you take a single call.
Three more you can run inside Shopify admin on any store you have access to — whether the theme is composed or hardcoded, whether your client can edit their own copy, and what every installed app is costing.
And one that genuinely needs someone who can read a theme — render-blocking Liquid, flagged as such. That one a document can't hand you, and it says so rather than pretending otherwise.
What it doesn't contain: scoring, weighting, or a total out of ten. A rubric that produces a number invites you to compare two developers on a figure you generated from a document one of them wrote. The questions are the deliverable.

The thing that actually goes wrong

The agency version of this problem isn't hiring a bad developer. It's hiring one who is fine, who ships something that looks right, and whose problems surface four months later — on your client's store, in front of your client, with your name on the engagement.

That's the sequence in the enquiry I get most often from agencies: "our last one made mistakes we didn't catch until our client found them." Not we hired someone incompetent — we couldn't see it in time. By the time it's visible, the conversation is no longer about the developer. It's about whether you knew.

The reason it happens is structural, not a hiring mistake. You're evaluating a technical discipline you don't practise, on a timeline set by a client who is already waiting, using the only evidence available — a portfolio of screenshots, which is the medium in which a badly built store and a well built one look identical.

A rubric doesn't fix that. What it does is move the check to before the engagement, where a specific question about render-blocking Liquid takes four minutes and separates the people who run that check from the people who have heard of it.

Get the document

It arrives immediately. One email, the document attached, no sequence behind it — I don't run a nurture funnel and I'm not going to start with you. If you want the occasional note when I publish something, there's a separate box for that on the notes page, and it's genuinely separate.

And the honest version of what you're paying with: the material is already on this site, in full. What the email buys is the format — the agency-facing rewrite, as a document you can take into a room.

If you place developers

White-label, by default. Your client never finds out I exist unless you want them to. I work under your name, in your process, in whatever tooling you already use — and I don't contact your client, ever, including after the engagement ends. That holds afterwards too: nothing we build together appears on this site under your name or your client's unless you've put that in writing. The work I show is anonymous by default, and it stays that way if you'd rather it did.

A standing rate, not a per-project quote. $39 per hour.

The reason it's standing rather than quoted is practical: you can't price a client proposal against a number you have to ask me for. Legibility is the point — you should be able to scope a job on a Tuesday afternoon without waiting on my reply. It's below my direct rate because consistent work is worth something, and I'd rather say that plainly than call it a favour.

What it doesn't include. I'm not a capacity buffer for work you'd rather not do — the two to three-projects limit applies to agency work identically, and I'll say no to a timeline I don't think holds. If what you need is someone who takes whatever arrives, at whatever date, the standing rate won't make that work and one of us will be annoyed by month two.

And the margin question, stated plainly: a standing rate has no spread in it. If your model needs to mark up a developer's rate to make the numbers work, this isn't structured for that. If your model is billing your own work at your own rate and buying implementation you can't do in-house, it is.

What happens if I'm not here

You already know why you're asking. Most agencies that reach me are mid-project with someone who stopped answering, and nobody can prove in advance that they won't be the next one — not me, and not the developer you had before, who presumably also seemed fine when you hired him.

So here is what's actually true, and what isn't.

What I can tell you now: I take two to three projects at a time, and right now I have room for one starting within the month. That's a claim you can test on this call rather than take on faith — ask me what I'm working on and when it ends.

What's bounded if it goes wrong: payment is staged — deposit, milestones, the rest on launch — so you're never carrying an unpaid balance for work you haven't seen. And if something breaks because of my code, I fix it inside the warranty period of one month after launch — on the work as built, not on new requests — at no charge. That's the term that matters most to you, because the failure you're actually afraid of is your client finding the bug, not you finding it.

What I can't do is promise I'll be here in week six. Nobody selling you development can, and the ones who say it most confidently are telling you the least. What I can do is make sure that if I'm not, you find out from me early and you're not out of pocket for work that didn't happen.

Who this isn't for

If you need to mark up the rate to make the engagement work — the previous section is the honest answer, and it's a no. There are developers who price to be marked up. That's a real business model, it isn't a criticism, and I'm not one of them.

If you need someone available on demand — I take two to three projects at a time and that includes yours. If your value to your client is that you can start on Monday, I will sometimes be the reason you can't.

If you want implementation without opinions — I'll tell you when I think a spec will cost your client conversions, and I'll say it to you rather than to them. Some agencies want that; some have already had the conversation with their client and don't want it reopened. Both are legitimate and it's worth knowing which you are before we start.