Hiring a Shopify Development Agency Without Guessing

Evaluating a development agency is hard because the work is invisible to the buyer. You can see the storefront and not the code, and the difference between the two only becomes apparent when something needs changing eighteen months later.

Portfolios do not help much with this. They show that something was built and launched. They say nothing about whether it still works, what it cost to maintain, or what it left behind in someone's theme.

Ask about the work that is two years old

The most revealing question available, and it is rarely asked.

Anyone can launch something. The interesting question is what happened afterwards: does it still run, has it needed emergency work, did it survive the platform changes that have happened since.

Shopify ships continuously and retires API versions on a published schedule. Legacy Scripts stopped running on 30 June 2026, checkout extensibility replaced checkout.liquid, and Horizon changed what themes can express. An agency that has been building for several years has lived through all of that, and how they handled it is a better signal than anything in a case study.

Ask specifically whether their older work needed rescuing, and what they did about it.

The technical questions that separate agencies

Six, and the answers are informative even if you cannot fully evaluate them.

"How do you handle storefront rendering for apps?" The answer should be theme app extensions. An agency still injecting code into theme files is building something merchants cannot cleanly remove.

"How do you handle API deprecations?" There should be a process — an inventory, a schedule, someone assigned. "We deal with it when it comes up" means you will deal with it when it breaks.

"How would you implement custom discount logic?" Shopify Functions. If they suggest cart manipulation, that behaviour will be bypassed by accelerated checkouts.

"What do you leave behind on uninstall or handover?" Ideally nothing you did not ask for. Theme debris is the most common complaint merchants have about inherited work.

"How do you test?" Not necessarily an elaborate answer, but there should be one, particularly for anything touching money.

"What documentation do we get?" The answer determines whether the next developer can pick it up or has to reverse-engineer it.

Ask what they would tell you not to build

The single most useful question in the whole conversation.

An agency with no answer is selling scope. One that says "you do not need headless", "a theme can do that", or "this app already exists and costs less than we would" is exercising judgement, and judgement is the thing you are actually buying.

The same applies to the brief you arrive with. If you ask for a custom build and the honest answer is that a configured theme would serve you better, you want to hear that before the estimate rather than after the invoice.

An agency that agrees with everything you propose is either unusually lucky in its clients or is not thinking hard about the brief in front of it.

Settle ownership and handover first

The commercial questions that determine whether you end up with an asset or a dependency.

The last item is the one merchants forget. A build that requires the agency for every small change is a build that has converted a one-off cost into a permanent one. Ask explicitly what your team will be able to do unaided.

These are easy conversations at the start and awkward ones at the end. Having them early costs an hour and prevents the most common form of agency regret.

Agency, freelancer or in-house

There is no universally right answer, and the trade-offs are reasonably clear.

A freelancer is frequently better value for a defined, contained piece of work, and you get direct access to the person doing it. The risk is availability later — the developer who built your integration may not be reachable when it needs upgrading.

An agency makes sense where continuity matters, where several disciplines are involved, or where the work is ongoing. You are partly paying for the fact that someone will still be there. The risk is paying for overhead the project does not need.

In-house suits stores with continuous development needs and enough work to justify the hire. Below that threshold it is expensive capacity sitting idle.

A common and sensible arrangement is an agency or freelancer for defined projects, with enough internal capability to handle routine changes and to evaluate what is being delivered.

Scoping the first engagement well

How you structure the first piece of work matters as much as who you pick, because it determines how much you learn before committing further.

Start with something contained. A defined project with a clear end — an audit, one integration, one template — tells you how an agency works at a fraction of the risk of a large build. You learn their communication, their estimating accuracy and their code quality on something you can walk away from.

Watch how they handle the first surprise. Every project meets something unexpected. The response to that is far more informative than the proposal: do they raise it early with options, or do they absorb it silently and mention it when the deadline slips?

Check the estimate against the outcome. Not to punish an overrun — estimates are estimates — but because how an agency communicates about one tells you what a larger project will be like.

Ask to see the code, even if you cannot fully evaluate it. Have someone who can look at it, or at minimum check that it exists in a repository you have access to, is documented, and is not one enormous undifferentiated file.

Notice who you actually talk to. If the person in the sales conversation disappears after signing, that is the pattern for the whole relationship.

The point of a small first engagement is that its real deliverable is information about the agency. A merchant who commits a large budget to an unknown team on the strength of a portfolio is buying on the least reliable evidence available.

Briefing them properly

The buyer controls more of the outcome than most merchants realise, and a poor brief produces a poor result from a good agency.

Describe the problem, not the solution. "Our mobile product pages lose people before the buy box" gives an agency something to solve. "Build us a custom theme" gives them an instruction that may be the wrong one.

Say what must not change. URLs, the integrations you depend on, the things your team can currently edit themselves. Agencies cannot protect what they do not know matters.

Name a decision-maker. Development projects stall on unresolved opinion more often than on technical difficulty.

Be honest about your capacity. If nobody internally can maintain what is built, that should shape what gets built.

Warning signs

Patterns that correlate with disappointment.

No questions about your business. An agency that produces a quote without first understanding what you sell is quoting from a template rather than from your situation.

Estimates with no maintenance component. Anything custom needs maintaining, and an estimate that ignores it is describing half the cost.

Reluctance to discuss handover. If ownership and documentation are awkward topics at the start, they will be worse later.

Recommending the most expensive option by default. Headless when a theme would do, custom when an app exists.

No examples of older work still running. Either they have not been doing this long, or the older work is not something they particularly want to discuss — and both are worth knowing before you commit.

Unwillingness to talk to your existing developer. If you have one, an agency that treats them as a threat rather than a source of context is prioritising the relationship over the outcome.

For the technical decisions this often involves, see Shopify development. The theme-versus-custom question is covered in storefront and design.