Questions to Ask Before Hiring an E-commerce Developer

An e-commerce developer builds the part of your business that takes the money. Unlike a brochure site, a store touches payments, inventory, tax, shipping, customer accounts and the analytics you use to decide what to stock next, and a mistake in any of them costs sales on the day it happens. The questions to ask an ecommerce developer before you hire one are therefore less about taste and more about how they handle risk: how they scope, how they test, who does the work, what you own at the end, and what happens when something breaks at eleven at night during a promotion.

This guide is for store owners, e-commerce managers and marketing leads comparing developers or agencies for a new build, a replatform or a significant rebuild. It is organized the way a good interview is: by theme, with each question explained. For every question you will find why it is worth asking, what a good answer sounds like, and what a bad one sounds like, so you can tell the difference in the room rather than after the contract is signed.

Most weak hires are not the result of bad developers. They come from a buyer and a supplier who never tested each other's assumptions about scope, content, integrations and ownership. The questions below are designed to surface those assumptions early.

Why the choice matters, and the seven questions to ask first

Changing developer halfway through a store build is expensive and slow. The new team has to learn someone else's code, often has to redo work it cannot vouch for, and inherits every undocumented decision. Choosing well the first time is the single biggest lever you have on the cost and timing of the project.

If you only have time for a short call, these seven questions do most of the work:

1. Which platform would you recommend for us, and what would make you recommend a different one?
2. How many unique templates do you think this store needs?
3. Which of our integrations worry you most, and why?
4. Who exactly will write the code, and will they be on our calls?
5. How do you test checkout before launch?
6. What will we own when the project ends, and where will it live?
7. What happens in the first month after launch if something breaks?

A developer who answers all seven specifically, with trade-offs and without hedging, is worth a longer conversation. The sections below expand each of them and add the questions that separate a good shortlist from a final choice.

Fit and process: does this developer work the way your project needs?

These questions test whether the developer understands your kind of store and has a process that will survive contact with your real content, systems and approvals.

Which platform would you recommend for us, and why not the alternatives?

Why ask it: Platform choice sets the cost of everything that follows, from apps and hosting to who can maintain the store later. A developer who only works on one platform may recommend it regardless of fit. You want to hear the reasoning, not just the answer.

A good answer sounds like: They ask about your catalog size, order volume, integrations, in-house skills and growth plans before answering. They name at least one alternative and explain when it would be the better choice. They are candid about what their recommended platform does badly. For background on the trade-offs, read choosing an e-commerce platform: what actually works.

A bad answer sounds like: An immediate answer before they know anything about your business, or a claim that one platform is right for everyone. Also be wary of recommending a custom or headless build for a store that has no clear need for one.

Have you built stores with a model like ours?

Why ask it: A subscription business, a B2B wholesale store with price lists, a store selling bookable services and a fashion brand with deep variants all have different technical problems. Relevant experience shortens discovery and reduces surprises.

A good answer sounds like: Specific examples of similar problems they have solved, with the difficult part explained: how they handled tiered pricing, variant limits, appointment slots or account approvals. If your model is B2B, they should mention quotes, credit terms and customer-specific price lists without prompting.

A bad answer sounds like: A portfolio of attractive homepages with no discussion of the mechanics behind them, or "we can build anything" in place of evidence that they have built this.

What does your process look like from discovery to launch, and where does it usually slip?

Why ask it: Every developer has a process slide. What matters is whether they know where projects actually go wrong. The honest answer tells you whether they plan for reality.

A good answer sounds like: A clear sequence with rough durations and an admission of where time is lost. A typical shape is discovery (1–2 weeks), content and structure (2–4 weeks, and this is the one that slips), design (3–6 weeks), build (4–12 weeks depending on template count) and testing and launch (1–3 weeks, plus the redirect map). A good developer tells you that content and structure is where schedules go wrong and asks what you have ready.

A bad answer sounds like: A fixed launch date promised in the first meeting before scope is known, or a process that jumps from design straight to launch with no testing phase or redirect plan.

How many unique templates will this store need?

Why ask it: Cost and build time follow the number of distinct layouts, not the number of pages. A fifty-page site with six templates is a much smaller job than a twelve-page site with eleven. Asking this forces the developer to think about your store concretely.

A good answer sounds like: A provisional count broken down by type: home, collection, product (perhaps two variants for simple and configurable products), cart, content page, blog article, account pages. They explain which templates could be merged to save cost and which should stay separate.

A bad answer sounds like: "It depends" with no attempt at an estimate, or a quote priced per page with no reference to templates at all.

How ready does our content need to be, and what happens if it isn't?

Why ask it: Content readiness is one of the largest drivers of timeline. A site with copy and images ready moves at roughly twice the speed of one where content is written during the build. Product data is content too: descriptions, specifications, variant names, images and alt text.

A good answer sounds like: They ask for a content inventory early, explain who is responsible for each piece, and tell you what they will do with placeholder content and when real content must arrive to hold the schedule.

A bad answer sounds like: No questions about your product data at all, or an assumption that the catalog will "just import" from the old platform without cleanup.

Which of our integrations worry you most, and why?

Why ask it: Integrations are where store projects most often overrun. A CRM, a booking system, a payment gateway, a legacy inventory feed: each one is a separate contract with somebody else's API and somebody else's outage. A developer who has read your system list should already have an opinion.

A good answer sounds like: They pick one or two integrations as the riskiest and say why: an inventory feed that only updates overnight, an ERP with a poorly documented API, a gateway that does not support a payment method you need. They propose to test those early, often with a small proof of concept during discovery, and explain what the store will do when the other system is down.

A bad answer sounds like: "Our platform connects to everything," or a plan that leaves all integration work until the end of the build.

Craft and quality: will the store be fast, accessible and correct?

A store can look finished and still lose sales to slow pages, broken filters, inaccessible checkout steps or analytics that do not match the orders in your back office. These questions test whether the developer treats quality as something to measure.

How do you test checkout and payments before launch?

Why ask it: Checkout is where every defect costs money directly. It combines payment gateways, tax, shipping rules, discount logic, inventory and email notifications, and it has to work on every device.

A good answer sounds like: A written test plan that covers each payment method, discount combinations, shipping zones, tax cases, out-of-stock behavior, failed payments, refunds and order confirmation emails, run on real phones as well as desktop. They use the gateway's test or sandbox mode, then place and refund a small live order before opening the store.

A bad answer sounds like: "We test everything" with no detail, or a plan that stops at placing one successful order.

What performance targets will you commit to, and how will you measure them?

Why ask it: Speed matters most on the pages that earn money: collection and product pages on mobile. Themes, apps and tracking scripts accumulate weight quickly.

A good answer sounds like: They name the metrics they use, such as Google's Core Web Vitals, measure on real product and collection pages rather than the homepage, and explain how they will keep third-party apps and scripts in check. Our guide to e-commerce performance covers what to measure.

A bad answer sounds like: A promise of a perfect score on a testing tool for the homepage only, or no plan for what happens to speed when your marketing team adds scripts after launch.

What accessibility standard do you build to?

Why ask it: Accessibility affects whether customers can buy from you at all, and retrofitting it is expensive. Meeting WCAG 2.1 AA from the start adds modestly to design and build. Retrofitting it later costs several times more.

A good answer sounds like: WCAG 2.1 AA named as the target, with specifics: keyboard navigation through filters and checkout, visible focus states, labeled form fields, sufficient contrast, meaningful alt text and error messages that screen readers announce. They test with a screen reader, not only an automated scanner. See a practical guide to accessibility in e-commerce.

A bad answer sounds like: "The theme is accessible" or reliance on an overlay plugin as the whole answer.

How will you set up analytics and check it is accurate?

Why ask it: If purchases, revenue and product views are not tracked correctly, every later decision about marketing and merchandising rests on bad data.

A good answer sounds like: They describe an event plan (product view, add to cart, begin checkout, purchase), explain how they will deduplicate purchases and reconcile tracked revenue with platform orders, and handle consent requirements. A practical guide to e-commerce analytics setup walks through what that plan should include.

A bad answer sounds like: "We'll install the tracking code" with no mention of events, testing or reconciliation.

Can we see a store you built that has been live for a year or more?

Why ask it: Launch-day screenshots show design. A store that has been live for a year shows whether the build held up: whether it is still fast, whether the client could edit it, and whether it survived platform updates.

A good answer sounds like: They share live stores, explain what has changed since launch and who changed it, and are willing to put you in touch with the client.

A bad answer sounds like: Only mockups or recent launches, or portfolio links that now point to a different developer's rebuild.

Team: who will actually build your store?

The people in the sales meeting are not always the people who write the code. These questions find out who is really on your project and what happens if they leave.

Who exactly will work on our project, and in what roles?

Why ask it: Agencies often pitch with senior staff and deliver with a different team. Freelancers may subcontract. You need to know whose skills you are buying.

A good answer sounds like: Named people with roles: a project lead, the developer or developers, a designer, and whoever handles testing. They tell you how much of each person's time is committed and whether anyone is external.

A bad answer sounds like: "Our team" with no names, or reluctance to say whether the build is subcontracted.

Will the developers be on our calls?

Why ask it: Technical questions answered secondhand by an account manager tend to come back wrong or late. Direct access to the person writing the code resolves problems in minutes instead of days.

A good answer sounds like: Yes, at least for technical sessions and reviews, with a clear account manager or project lead for scheduling and decisions.

A bad answer sounds like: The developer is never available, and every question goes through a non-technical intermediary.

What happens if our lead developer leaves or is ill?

Why ask it: Store builds run for weeks or months, and people change jobs. The question tests how much knowledge is written down.

A good answer sounds like: Code in a shared repository, documented decisions, a second developer familiar with the project, and a clear handover process.

A bad answer sounds like: "That won't happen" or a single freelancer with no backup and the code on their own laptop.

Who handles design, and how do design and development work together?

Why ask it: Designs that ignore platform constraints produce either expensive custom work or a store that does not match what you approved.

A good answer sounds like: Designers who know the platform, working from real products and content, with developers reviewing designs before sign-off for feasibility and cost. Product pages should be designed around real data; product page design, done properly explains why.

A bad answer sounds like: Designs handed over as finished images with no developer review, followed by "that will cost extra" during the build.

Communication: will you know what is happening without chasing?

Most project friction comes from surprises. These questions test how the developer reports progress, surfaces problems and handles decisions.

How and how often will you report progress?

Why ask it: A regular, predictable rhythm means problems surface while they are still cheap to fix.

A good answer sounds like: A weekly written update that covers what was done, what is next, what is blocked and what decisions they need from you, plus access to a staging site you can see at any time.

A bad answer sounds like: Updates only when you ask, or progress shown only at the end of each phase.

How will you tell us when something is going wrong?

Why ask it: Every project hits problems. What matters is whether you hear about them early, with options.

A good answer sounds like: They describe raising issues as soon as they appear, with the impact on scope, schedule or budget and a recommendation. Ideally they can describe how they handled a slipping project before, without naming the client.

A bad answer sounds like: "Our projects don't go wrong," or an answer that only covers problems caused by the client.

Who on our side do you need, and how much of their time?

Why ask it: Your team's availability is as much a dependency as the developer's. Product data, content approvals, integration credentials and test orders all come from you.

A good answer sounds like: A realistic estimate of who they need (a decision-maker, someone who knows the product data, someone with access to your systems) and at which stages. They tell you what happens to the schedule if your approvals are late.

A bad answer sounds like: "We'll take care of everything," which usually means they have not thought about what they need from you.

How do you handle feedback and approvals?

Why ask it: Unstructured feedback from several people causes rework. A clear process protects both sides.

A good answer sounds like: A single consolidated feedback round per deliverable, a named approver on your side, and a written record of what was approved.

A bad answer sounds like: Unlimited revisions offered as a selling point, which often means no one owns the decisions.

Contracts and rights: what will you own, and what are you agreeing to?

The contract decides what happens when the relationship ends, which is exactly when you most need clarity. This section is practical guidance, not legal advice; have your own counsel review the contract.

What will we own at the end of the project?

Why ask it: You should own the code written for you, your content and your data, and have the access needed to move to another developer if you choose.

A good answer sounds like: Ownership of custom code transfers to you on payment, with clear exceptions for their pre-existing tools or libraries, which are licensed to you on terms that let you keep using them. All accounts (platform, domain, hosting, payment gateway, analytics, app subscriptions) are registered in your name.

A bad answer sounds like: The developer owns the code and licenses it back to you, or key accounts are registered to the agency.

Where will the code live, and will we have access?

Why ask it: If the code sits only in the developer's accounts, you cannot move without their cooperation.

A good answer sounds like: A repository you own, or one transferred to you at launch, with deployment instructions documented.

A bad answer sounds like: No version control, or access offered only on request after the final invoice.

How do you handle changes to scope?

Why ask it: Scope changes are normal. Uncontrolled ones are how budgets double.

A good answer sounds like: A written change process: each change described, estimated and approved before work begins, with its effect on schedule stated. They explain what counts as a change and what is included.

A bad answer sounds like: "We're flexible" with no written process, or the opposite: charging for every small clarification.

What are the acceptance criteria for launch?

Why ask it: Without agreed criteria, "finished" becomes an argument.

A good answer sounds like: A written list of what must work at launch, tied to the test plan: payment methods, integrations, templates, accessibility target, performance targets and redirects.

A bad answer sounds like: Launch defined as the date the developer finishes, rather than the point at which agreed criteria are met.

Pricing: how is the work priced, and what drives the number?

Prices vary widely between developers, and a lower quote is often a narrower scope rather than a better deal. The questions below help you compare like with like. For a fuller breakdown, see how much an e-commerce website costs.

For reference, typical US market ranges for web design and development are: a small marketing site at $6,000 – $20,000 (five to fifteen pages, a handful of templates, a CMS you can actually use, accessible and fast); a business site with systems at $20,000 – $75,000 (custom templates, real integrations, structured content, a migration, and a testing pass that deserves the name); and a large or complex build at $75,000+ (multi-language, complex integrations, design systems, or anything where the site is the product rather than a brochure for it). A store with a payment gateway, an inventory feed and a migration from an old platform has most of the features of the middle category, and a store that is itself the business can fall into the last.

Is this a fixed price, and against what scope?

Why ask it: A fixed price is only as good as the scope it is fixed against. Two quotes with the same total can describe very different stores.

A good answer sounds like: A price tied to a written scope with a named number of templates, named integrations, a stated accessibility target and a defined migration. They explain what would change the price.

A bad answer sounds like: A single number with a one-paragraph scope, or an hourly estimate with no cap and no breakdown.

Which parts of our project drive the cost most?

Why ask it: A developer who can explain their own estimate understands your project. The main drivers are well known: the number of unique templates, content readiness, integrations, the accessibility target, migration, and who maintains the store afterward.

A good answer sounds like: They point to your specific drivers. For example: each integration (a CRM, a booking system, a payment gateway, a legacy inventory feed) is a separate contract with somebody else's API and somebody else's outage; moving a thousand existing pages while preserving their URLs and formatting is its own project with its own risks. They suggest where you could reduce scope without harming the result.

A bad answer sounds like: "It's just what stores cost," or no ability to say what would make the number smaller.

What is not included in this quote?

Why ask it: Exclusions are where surprise invoices come from: apps, platform subscriptions, product photography, copywriting, data cleanup, hosting, ongoing support.

A good answer sounds like: A written list of exclusions and third-party costs you will pay directly, with estimates or ranges where they can give them.

A bad answer sounds like: Silence on exclusions, or a discovery that data migration is "extra" after the contract is signed.

Will we be able to edit the store ourselves, and does that change the price?

Why ask it: Building something you can edit safely costs more up front than building something only the developer can change. It is almost always the cheaper of the two over three years.

A good answer sounds like: They explain which parts your team can edit without code (products, collections, content blocks, promotions) and which require a developer, and they include training and documentation.

A bad answer sounds like: Every content change requires a support ticket, or editing freedom so loose that your team can break the layout.

Aftercare: what happens after launch?

The first weeks after launch are when problems appear under real traffic and real orders. These questions establish who is responsible and how quickly they respond.

What support do you provide in the first month after launch?

Why ask it: Launch is when real customers find the edge cases the test plan missed.

A good answer sounds like: A defined warranty or support period for defects in the agreed scope, with response times stated in writing, and a named person to contact.

A bad answer sounds like: Support that ends the moment the final invoice is paid, or response times described as "as soon as we can."

How do you handle urgent problems, such as checkout failing during a sale?

Why ask it: A broken checkout during a promotion loses revenue by the minute. You need to know who answers and how quickly.

A good answer sounds like: A documented escalation route for critical issues, with a clear definition of what counts as critical and what hours are covered. They explain what monitoring they set up so they know before your customers tell you.

A bad answer sounds like: An email address and a general promise, with no distinction between critical and routine issues.

What ongoing work do you recommend, and how is it priced?

Why ask it: Stores need platform updates, app reviews, performance checks and new features. Retained support is common; the question is whether its scope is clear.

A good answer sounds like: A clear offer, such as a developer on your stack for an agreed share of each month, priced by the hour or by a monthly allocation, with a report of what was done. Our own retained engineering starts from $145 per hour, and can start within 2 weeks.

A bad answer sounds like: Vague "maintenance packages" with no statement of what is included, or pressure to sign a long retainer before launch.

What documentation will we receive at handover?

Why ask it: Documentation is what lets you change developer, onboard staff or recover from a problem without the original team.

A good answer sounds like: An editing guide for your team, a technical note covering themes, apps, integrations, custom code and deployment, a list of every account and who owns it, and the redirect map.

A bad answer sounds like: "It's all in the code," or documentation promised but not listed in the contract.

Scoring e-commerce developers side by side: an illustrative example

After the interviews, a simple weighted scorecard makes the comparison explicit and keeps the decision from resting on whoever presented best. The example below is illustrative. The store, the suppliers and the scores are invented to show the method; they are not client data.

The illustrative store sells around 1,200 products, needs an estimated seven unique templates, connects to three outside systems (a payment gateway, an inventory feed from a warehouse system, and an email platform), and is moving from an older platform with around 900 existing URLs that need redirects. Product descriptions exist but need cleanup.

The buyer weights each theme by how much it matters to this project: fit and process, craft and quality, and contracts and rights each carry a weight of 3, because the integrations and migration are the main risks; team and aftercare carry 2; communication and pricing carry 1, because the budget is set and all three suppliers communicated well. Each supplier is scored from 1 to 5 on each theme, and the score is multiplied by the weight.

In this illustration, Supplier C had the most attractive price but scored poorly on contracts (it wanted to keep the theme and license it back) and on aftercare (no defined support after launch). Supplier A was strong and pleasant to work with but vague about who would build the inventory integration. Supplier B scored highest because it counted templates, flagged the inventory feed as the riskiest integration, planned the 900 redirects as a distinct workstream and put every account in the buyer's name.

Two practical notes on using a scorecard. First, agree the weights before the interviews, so they reflect the project rather than a favorite supplier. Second, write one sentence of evidence next to each score. A score of 2 on contracts should point to the clause that caused it, which also gives you something specific to negotiate if you still prefer that supplier.

Questions for specific kinds of stores

Some stores have problems that general questions will not uncover. Add these where they apply.

• Large catalogs. Ask how they will structure filters and collection pages, and how filtered URLs will be handled for search engines. A practical guide to faceted navigation and filtering covers the decisions involved.
• Headless or composable builds. Ask why a headless architecture is justified for your store, what it will cost to run and maintain, and who on your side can support it. A practical guide to headless commerce explains when it pays off.
• Replatforming. Ask how they will migrate customers, orders and passwords (or handle password resets), how they will preserve URLs, and how they will compare traffic and conversion before and after the switch.
• Stores selling in several countries. Ask about currencies, tax display, language versions and how shipping rules will be managed.
• Stores with heavy promotions. Ask how discount combinations are tested and how the store will behave under a traffic spike.

If you are still deciding whether a studio or a freelancer suits your project, our overview of e-commerce development explains how we scope, build and support stores, and the e-commerce development articles go deeper on individual decisions.

Every question to ask an ecommerce developer, on one page

Use this as an interview sheet. Not every question will apply to every project, but a developer who cannot answer most of them clearly has told you something important.