How to Choose a Shopify Partner
Date
Category
Writer
Choosing an ecommerce partner is a decision whose consequences show up 6–12 months later. By then the contract is signed, the project is running, and switching is expensive.
This guide is written from the buyer's side. It contains the questions a good partner answers gladly and a poor one deflects — including the parts where the right answer is "don't buy".
We have built ecommerce solutions for more than a hundred Nordic brands. Most of what follows is something we learned because it once went wrong.
Part 1 — What you are actually buying
Most failed partnerships fail because the buyer and the supplier bought and sold different things. Decide this before you send a single request for proposal.
A one-off project. A new store or a platform migration with a beginning and an end. You are buying delivery. Success means the store is live on schedule and the data arrived intact.
Ongoing development. The store exists and the goal is to grow revenue. You are buying capability, not a project. Success is measured in revenue and margin, not in features shipped.
Both, in sequence. The most common and the hardest. One thing decides it: whether the same team continues. A migration builds up understanding of how your product data, your integrations and your customers actually behave. If the team changes when the project ends, that understanding disappears exactly when you start needing it.
Ask by name who continues into the maintenance phase, and in what configuration.
Part 2 — Price, scope and timeline
What "quality" actually costs
Let's say this plainly, because it saves everyone time: a well-built Shopify store delivered by a capable partner costs upwards of €25,000 when it is properly planned. This applies to SMB and mid-market brands with a real catalogue, integrations, and a business to protect.
Below that, what you get is typically a standard theme with minor changes, no integrations and no data migration. That is a perfectly sensible solution in many situations — but it is a different product, and this guide is not about it.
If your budget is well below that line, don't spend time running an agency tender. Part 6 covers what to do instead.
The four parts a price is made of
Project prices are quoted as a single number, but they are built from four components whose proportions vary enormously. Ask for every proposal broken down this way — that is the only thing that makes them comparable.
Design and UX. Usually the smallest share in a redesign, the largest when the brand identity is new.
Build. Theme development and functionality. This is the part most proposals talk about.
Integrations. Almost always the part that blows the budget. ERP, POS, logistics, invoicing, PIM. The cost does not depend on how many integrations there are, but on whether there is a documented API on the other end.
Data migration and cleanup. Systematically underestimated. The cost is not in moving the data — it is in the fact that old data does not fit the new structure as it stands.
Three questions that reveal the quality of a proposal:
What share of the price is integrations, and what is that estimate based on?
What happens if the ERP's API turns out to be more limited than expected?
What in this proposal is fixed and what is an estimate?
If an agency quotes a price without seeing your current system landscape, the price is built on assumptions. Assumptions get corrected through change orders.
A mark of a good proposal: every line item is marked either included or chargeable separately, and there is an explicit list at the end of what is not included. A proposal without that distinction moves the boundary-drawing into a mid-project negotiation — and you will have less leverage then than you do now.
Standard theme or custom build
This decision drives cost more than any other single choice.
A standard theme as the foundation is the right answer for most SMB and mid-market brands. It is faster, cheaper to maintain, and it keeps up with platform updates. Customisation is then targeted at the places where the business genuinely differs — a product configurator, a B2B ordering view, a sizing tool.
A fully custom or headless build is justified when content management, multi-market selling or performance demand it — but it costs more to build, considerably more to maintain, and it ties you to your partner more tightly.
Ask: Why are you proposing this approach for us, and what will it cost to maintain over three years? A partner who proposes headless without grounding it in the business is selling themselves an interesting project.
Timeline
A straightforward redesign on a standard theme moves in weeks. A platform migration with integrations moves in months. A complex, multi-market or subscription-based migration can easily take more than six months.
An unrealistic timeline in a proposal is not good news. It means either the scope has been misunderstood, or testing and QA have been priced out.
Part 3 — Twelve criteria
1. Depth of platform expertise
Agencies split into two kinds: many platforms, or one.
A partner focused on a single platform knows in advance what works, what needs a workaround and what is best left undone. A multi-platform agency figures that out during your project — and you pay for that learning.
Ask: How many builds on this platform in the last two years? Fewer than ten is few.
A test question that reveals whether they are current: We have products with hundreds of variants. How do you handle that?
Shopify's variant limit was 100 per product for years. It has been raised to 2,048. If a partner still answers "you'll need an app for that" or "the product has to be split up", they are working from outdated knowledge. The right answer talks about how the theme, search and filtering hold up with thousands of variants — that is the real constraint now, not the platform limit.
2. Who actually does the work
The person in the sales meeting is rarely the person who writes the code. That is normal. What is not normal is not being told who does.
Subcontracting is not automatically bad, but it adds a layer, and layers leak under pressure. Ask where the work is done, in what time zone, and who you talk to when something breaks.
Insist on: meeting the project's technical lead before you sign. If that meeting is not arranged, you have learned something important.
3. Evidence of revenue, not of launches
The length of a reference list tells you how good their sales is, not how good their delivery is. What matters is what happened to those stores after launch.
Ask: Do you have a client whose revenue grew measurably as a result of your work — and how was that verified?
A good answer includes a number, a time period, and an honest note about which part of the growth came from something other than the agency's work. Seasonality, ad budget changes and catalogue expansion all matter, and a partner who doesn't mention them either doesn't know or isn't saying.
Watch out for this: "conversion rate went up 30%." Conversion rate rises automatically when low-quality traffic falls away — with no revenue growth at all. Always ask what happened to the money.
4. Conversion optimisation and statistical reality
This is where the most unworkable things get sold.
A/B testing requires sample size. At a 2% conversion rate, 95% confidence and 80% power, you need:
To detect a 10% improvement (2.0% → 2.2%): roughly 161,000 sessions
To detect a 20% improvement (2.0% → 2.4%): roughly 42,000 sessions
To detect a 30% improvement (2.0% → 2.6%): roughly 20,000 sessions
A store with 5,000 sessions a month needs more than two and a half years to verify a single 10% improvement. Even a 30% jump takes four months — and 30% improvements are not found in button colours.
Most SMB ecommerce stores sit in exactly this range.
Two things follow. First: if a partner promises continuous A/B testing to a store with a few thousand sessions a month, they either don't know the maths or are counting on you not knowing it. Tests get run, "winners" get declared, and not one result is distinguishable from chance.
Second: low volume does not mean conversion can't be improved. It means the method is different.
Ask: What is a sufficient sample size for our store — and what do you do if we don't have it?
An honest answer acknowledges the constraint and describes the alternative: fixing what is broken without testing it (if a payment method fails on mobile, you don't need a test), qualitative evidence such as session recordings and heatmaps, segment analysis, and large structural changes instead of small ones. Plus extended before-and-after measurement periods, with the limitations stated out loud.
If the answer is "we just test and see", that is billable activity without verifiable results.
5. Performance
Shopify handles the server side, so speed is not a hosting question. It is the sum of three things: theme code, images and apps.
Apps are by far the biggest cause of a slow Shopify store. Every installed app adds scripts, and they accumulate unnoticed: reviews, chat, upsells, size recommendations, cookie banners, analytics. Ten apps is a normal count, and each one costs milliseconds.
The metrics are Core Web Vitals — LCP, INP and CLS. Shopify's own speed score in the admin is indicative, not a target.
Ask: What are the store's Core Web Vitals now, what is the target at launch, and what happens when we install three more apps?
An advanced requirement: ask for a performance budget written into the contract — a measurable level achieved at launch, and an agreement on how it is maintained. Without it, speed erodes over the first year and nobody is accountable.
Watch out for: promises of perfect scores. A content-rich commerce site running chat, reviews and ad tracking will not hit full marks. A partner who promises that either isn't planning to install them, or doesn't know what they're promising.
6. Testing and quality assurance
This is the line item that gets cut first when the price is negotiated. It is also the one whose absence only becomes visible at launch.
Require a written QA report before launch. It needs to cover:
Every payment method you actually offer, with a real test transaction. In the Nordics that means cards, mobile wallets, bank transfers and buy-now-pay-later options. One broken payment method on one device shows up in no report — it shows up only as lost revenue.
Real devices, not just a resized browser window. At minimum iOS and Android, and the browsers your customers actually use.
Every shipping method and pickup point flow, all the way through.
Discount and campaign logic, including stacked discounts.
Tax and any multi-market selling, verified with real orders.
Order flow into the ERP, verified with an actual test order rather than assumed.
Ask: Who signs off on QA, and what is the warranty period after launch? If fixing post-launch defects isn't agreed, those become change orders at exactly the moment you have the least leverage.
7. B2B capability, if you sell to businesses
If you sell both to consumers and to businesses, this narrows the field fast.
Shopify's B2B features are Plus-tier: company profiles, customer-specific price lists, payment terms and order limits. They work well when the pricing logic is straightforward.
They do not solve the following without additional work: line-item negotiated pricing, multi-step quote and approval workflows, complex discount rules calculated in the ERP, and situations where a customer's credit limit and open invoices determine what they are allowed to order.
Ask: Where are prices calculated — in Shopify or in the ERP? And what happens if a price changes in the ERP while a customer has the product in their cart?
This question separates an agency that has built a real reseller portal from one that has read the feature list. The right answer talks about sync frequency, caching and conflict handling — not about the fact that "Shopify supports B2B".
8. Migration: what does not come across
Migration conversations usually cover what transfers. The risks are in what doesn't.
Customer passwords do not transfer. They are stored hashed and cannot be moved between systems. By default every returning customer has to set a new password — and some of them won't.
There are ways to handle this. Shopify Multipass enables login continuity on Plus, and the transition can also be managed with a guided reset campaign before launch. Ask what your partner proposes — the answer tells you whether they have done migrations with returning customers.
Stored card tokens usually do not transfer between payment providers. If your business has subscriptions or recurring billing, this is the single biggest risk in the whole project: at worst every subscriber has to re-enter their card. Ask about this before you decide to change payment provider at the same time.
Order history transfers only partially. Historical orders cannot be recreated in Shopify as they were. Ask whether history moves onto the customer record, into a separate archive, or not at all — and what that means for customer service and lifetime value calculations.
Search visibility rests on redirects. Every old URL needs a destination. Some won't have an obvious one, and you have to decide where those point. Expect a dip in visibility for a few weeks after launch — that part is normal. What is not normal is nobody having agreed who monitors the recovery and who fixes it if it doesn't recover.
Product data modelling is done once. Metafields and metaobjects determine what the store can do for years afterwards. Badly modelled product data doesn't show up at launch — it shows up two years later, when every new feature needs a workaround. Ask to see the data model before the build starts.
Require dry runs. A complex data migration is run through a test environment several times before the real one. If a partner doesn't mention dry runs, ask why.
9. Measurement and analytics
Ecommerce numbers never match each other. Shopify, GA4 and ad platforms count different things over different attribution windows, and consent management removes part of the picture. A partner needs to explain why, not claim the discrepancy is a bug.
In 2026 there is a specific and urgent question attached to this.
Shopify removed support for checkout.liquid and additional scripts: for Plus stores in August 2025, and for all other stores on 26 August 2026. Shopify Scripts stopped working on 30 June 2026.
In stores where the migration wasn't done in time, conversion tracking may have broken with nothing visibly wrong in the store. Orders go through, customers notice nothing — but Google Ads and Meta conversion data, thank-you page upsells and loyalty triggers may have quietly stopped working.
Ask: Has our checkout been migrated, and how have you verified that conversion tracking works since?
Right now this is the single best question for separating a current partner from the rest. If the answer is vague, ask to see conversion counts before and after the migration date.
10. Integrations by name
"We have experience with ERP integrations" is not enough. The effort depends on the system, its version, and whether an API exists or has to be built.
Ask by name: Have you integrated this exact system, in this version? Who maintains the integration after launch, and what happens when the other end updates?
Ask too what happens with undocumented integrations. There are always some — someone built something once, and that person no longer works there.
11. Contract model and change management
A fixed price protects the buyer from overruns but pushes the supplier toward delivering the agreed minimum. Time and materials protects the supplier and moves the risk to you. Neither is wrong; what's wrong is a model that doesn't match the nature of the work.
The combination that works best: a fixed price for a well-defined scope, plus a documented change process.
Ask: How is a change request handled? Who prices it, in what timeframe, and can I decline? If the change process isn't described, it becomes the project's biggest source of friction.
For ongoing development, ask what the monthly model includes, what happens in a month with less work, and what the notice period is. More than three months' notice is a bad sign for the buyer.
Three contract clauses worth reading yourself. Standard IT service terms contain three clauses that surprise buyers most often — and neither side usually raises them during negotiation.
Intellectual property. Under standard terms, rights to the work product typically vest in the supplier, and the client receives a licence: the right to use and modify the result in their own operations, but not to sell or transfer it onward. This is not automatically a bad clause — it is the industry norm — but it is a different thing from ownership. Read the clause and know which one you are buying.
Acceptance. A common clause: if you don't raise an objection within an agreed window, often seven days, the work is deemed accepted. Make sure someone is available during delivery week and knows what to check.
Warranty expiry. The warranty is typically six months, but it usually lapses if you have a third party make changes to the work. If your own developer fixes something small after launch, the warranty may have gone with it.
12. Who owns the result
This is covered in more detail in the next part, but at the evaluation stage one question is enough: how is a transition to another partner handled if the relationship ends?
The quality of that answer tells you more than most others. A partner who has made themselves easy to replace is trusting that nobody will want to.
Part 4 — What you should actually receive
The criteria tell you who to choose. This part tells you what has to come out. Agree these in the contract rather than assuming them.
From discovery. A written requirements specification and scope confirmation. A technical audit of the current state. Sitemap and structure. A timeline with milestones.
From design. Wireframes before finished visuals. Mobile and desktop separately — mobile first, because that's where the revenue is. A documented style guide, not just finished screens; without it you cannot produce new pages yourselves or with a different partner.
From build. A working staging environment you have access to — not screenshots. Custom code owned by you. Apps and integrations on accounts in your name, not the agency's. Documentation of custom functionality.
Before launch. A written QA report. A performance baseline. A launch checklist.
At handover — this is where most problems originate:
Owner-level Shopify access within your own organisation. This is the single most important item on this list. If the store was created under the agency's Shopify organisation, you have a problem you will only discover when you want to change partners.
Source code in a repository you control.
Credentials and ownership of every third-party service.
Training recorded, not just delivered once in a meeting.
A written agreement covering post-launch support and the warranty period.
Part 5 — Red flags
A quote with no questions. If an agency prices the work without understanding your business and your systems, the price is built on assumptions.
A solution before the problem. If a specific technical approach is proposed in the first meeting, before anyone has looked at the current state, they are selling what they know how to build.
No staging environment. If work is shown as screenshots rather than an environment you can open yourself, you won't see what you're buying until it's in production.
QA isn't a separate line item. Then it has either been priced out, or it happens in a rush on the final evening.
A vague answer about rights. There is one correct answer to "whose Shopify organisation will the store be created under". If you don't get it directly, ask again.
Everything is possible. An experienced partner tells you what is expensive, what is risky and what should wait for phase two.
A conversion promise in percentages. "We'll raise conversion by 30%" before anyone has seen the data is sales talk.
No failures at all. Ask about a project that went wrong and what they learned. An agency without one is either young or not telling you.
Part 6 — When you don't need a partner
Not every situation calls for an agency. These are the cases where our advice is not to buy.
You don't know yet whether the product sells. If you're launching your first store, a standard theme and your own work will do. The cost of an agency project is better spent on the product and on marketing at that stage. Come back when you have repeat revenue.
Your budget is well under €25,000. Then the right answer is a standard theme, possibly some light design help with the look, and spending the money on traffic. An agency tender at this size produces either disappointment or an overrun.
The problem is lack of traffic. If few people visit the store, improving the store won't help. Optimising conversion on a small number is a small thing. Fix what's broken first.
Your internal team is capable but overloaded. Then you're buying the wrong thing. Extra capacity solves it more cheaply than an agency partnership.
The organisation isn't ready. An ecommerce project requires decisions about product data, pricing, logistics and customer service. If nobody owns those, the project stalls waiting for decisions while the invoice runs. This is the most common reason a good agency and a good client produce a bad project.
Part 7 — Checklist for your RFP
Copy these as they are.
Expertise and team
How many builds on this platform in the last two years?
Is the work done in-house or subcontracted — where, and who do I communicate with?
Who is the project's technical lead and can I meet them before signing?
Who continues into the maintenance phase?
Evidence
Name a client whose revenue grew as a result of your work — how was it verified, and which part of the growth came from something else?
Tell me about a project that went wrong and what you learned.
Scope and price
What share of the proposal is integrations and what is that estimate based on?
Why are you proposing a standard theme or a custom build for us specifically, and what does that choice cost to maintain over three years?
What in the proposal is fixed and what is an estimate?
Technical
Have you integrated this exact ERP, in this version?
Has the checkout been migrated off the legacy model, and how have you verified conversion tracking works since?
What does not transfer in the migration — passwords, payment tokens, order history — and what do you propose for each?
How many dry runs of the data migration happen before the real one?
How are old URLs and search visibility handled, and who monitors recovery after launch?
Can I see the product data model before the build starts?
Performance and quality
What are the Core Web Vitals now, what is the target at launch, and how is that level maintained as apps are added?
What does the QA report cover, and is every payment method tested with a real order on real devices?
Who signs off on QA and what is the warranty period after launch?
Conversion and measurement
Where does conversion optimisation start with you?
What is a sufficient sample size for our store — and what do you do if we don't have it?
How do you report results, and does the report show margin?
B2B
Where are prices calculated — in Shopify or in the ERP — and what happens if a price changes mid-transaction?
Have you built a reseller portal where credit limits and open invoices affect what can be ordered?
Ownership and handover
Whose Shopify organisation will the store be created under?
Where does the source code live and who controls it?
Do the IP rights to the work product belong to us, or do we receive a licence — and what does that licence cover?
What is the acceptance period, what is the warranty period, and in what situations does the warranty lapse?
What is delivered at handover — style guide, documentation, training, credentials?
How is a change request handled and who prices it?
How is a transition to another partner handled if the relationship ends?
In summary
The best partner is not the one who promises the most, but the one who asks the most before promising anything.
Three things separate a working partnership from the rest. The work is based on measured data rather than opinion — and the partner says so directly when there isn't enough data to draw conclusions. The people doing the work are identifiable individuals, not an anonymous resource. And results are reported in business numbers, not visitor counts.
If you have two finalists and one of them tells you what will be hard, choose that one.
Brancoy is a Helsinki-based Shopify and Shopify Plus partner. We have built ecommerce solutions for more than a hundred Nordic brands — platform migrations, conversion optimisation and B2B commerce. We're happy to talk through your partner selection even if you end up choosing someone else.
Latest Articles.
Thoughts, ideas, and perspectives on design, simplicity, and creative process.
The Shopify Migration Guide for 2025 — powered by AI
A practical guide to modern Shopify migrations.
