How to Hire an E-Commerce Developer: A Vetting Checklist

Every founder who has tried to hire an ecommerce developer through a freelance marketplace has hit the same wall: hundreds of profiles, all claiming Shopify expertise, all showing a portfolio of clean product pages that could have come from a theme demo rather than real client work. The gap between someone who can install a theme and someone who can actually build, debug and scale a store that processes real payment volume is enormous, and it rarely shows up in a portfolio screenshot. This checklist is built from the questions and tests that actually separate the two, because the cost of a bad ecommerce hire is not just wasted money, it is a broken checkout during a launch week, an unpatched security hole, or a migration that quietly tanks three months of SEO rankings.

Start before the hiring search even begins, by deciding the platform and scope, because that decision determines who you should even be talking to. A founder who has not decided between Shopify, WooCommerce, BigCommerce or a custom headless build will end up interviewing developers with completely different, incomparable skill sets and quoting wildly different numbers for what looks like the same project on paper. Shopify and WooCommerce developers, custom Node or PHP developers, and headless commerce specialists are different disciplines with limited overlap, and knowing which one the project actually needs, ideally validated with a short paid discovery call with someone platform-agnostic, saves weeks of comparing apples to oranges in a hiring process that otherwise turns into pure guesswork.

Portfolio review needs to go further than the images on a freelancer's profile page, because screenshots are trivially easy to fake or cherry-pick from a theme demo that was never actually launched to real customers. Ask for live URLs of stores the developer actually built and shipped, then go test the checkout flow yourself: add a product to cart, try a discount code, check what happens on a slow mobile connection, and look at whether the site is still actively running and presumably still generating revenue for that client. A developer who cannot produce three or four live, functioning stores with real order history behind them, only mockups and case study write-ups, has either not shipped much real production work or is not willing to have it checked, both of which are worth treating as a caution flag.

Platform-specific depth matters more than a generic full-stack label on a resume, particularly for Shopify and WooCommerce work where the ecosystem has its own quirks that only show up under real load. Ask specifically whether they write custom Liquid templates and understand Shopify's newer Hydrogen and Oxygen framework, or whether their entire workflow is installing third-party apps to solve every requirement, which stacks up app fees and page bloat fast and is a common giveaway of a developer operating at the edge of their actual technical depth. For WooCommerce, ask how they handle plugin conflicts and database performance at scale, since a store that runs fine in a demo with 200 products and zero real orders can fall over completely once it reaches 5,000 products and genuine daily order volume, if the underlying WordPress and MySQL setup was never actually built with that kind of growth in mind from the very beginning.

A small, paid test project reveals more in a week than three interviews ever will, and it is worth the modest cost even for a role that will eventually be a larger engagement. Structure a real but contained task, something like fixing a specific checkout bug, building one genuinely custom product page template, or optimizing image loading and Core Web Vitals scores on an existing site, and pay a fair rate for it rather than expecting free work. How a candidate scopes the task, asks clarifying questions before writing any code, documents what they changed and why, and communicates blockers along the way tells you more about how the full engagement will actually go than any number of polished answers in a video call interview ever could.

Understanding realistic pricing benchmarks protects against both overpaying and, just as importantly, underpaying for a level of skill the project genuinely needs. Freelance ecommerce developers on platforms sourcing heavily from Eastern Europe, South Asia and Southeast Asia commonly charge in the 25 to 50 US dollar per hour range for solid mid-level Shopify or WooCommerce work, US and UK-based freelancers and small agencies typically run 75 to 150 dollars per hour, and senior specialists in custom headless commerce, complex ERP integration, or platform migrations can reasonably charge 150 to 250 dollars per hour or more given the narrower talent pool and higher stakes of the work involved. A quote dramatically below these ranges for genuinely complex scope is a signal to look harder at the portfolio and the test project results, not a reason to celebrate a bargain, since the gap almost always reappears later as expensive rework once the real complexity of the project surfaces.

Red flags cluster around a handful of specific, checkable behaviours rather than a vague gut feeling, and it is worth treating them as near-disqualifying rather than minor concerns to be talked through. A developer who refuses to sign any contract or NDA, who insists on full payment entirely upfront before any work begins, who cannot answer basic scoping questions about the project without immediately jumping to a fixed price, or who promises an unusually fast timeline for genuinely complex scope, such as a full custom platform migration in two weeks, is showing you exactly how the rest of the engagement is likely to go. These are not personality quirks to work around after the contract is signed, they are the clearest signal available before any money changes hands.

Communication style and working hours overlap need honest discussion before signing anything, particularly for teams working with developers in a different time zone. Ask directly how they prefer to communicate, whether that is Slack, email, or a project management tool like Linear or Asana, how quickly they typically respond during a live incident such as a broken checkout on launch day, and whether they work from a shared staging environment with proper version control through Git, or whether changes get pushed directly to the live production site with no rollback plan if something breaks. A developer who cannot describe a clear staging-to-production workflow is one bad deployment away from taking your entire store offline during business hours with no way to quickly revert.

Post-launch support terms need to be agreed before the project starts, not negotiated after launch when leverage has shifted entirely to whoever holds the login credentials. Clarify explicitly who owns the hosting account, the domain registration, and the admin-level access to the platform itself, because a developer who insists on holding these under their own account rather than the client's is creating a dependency that can be used, intentionally or not, as leverage in a future pricing dispute. Agree upfront on what a reasonable maintenance retainer covers, whether that is simply security patching and platform updates or also includes small ongoing feature requests, and get a stated response time commitment in writing for anything classified as a critical incident like a broken checkout or a payment gateway failure.

Code and intellectual property ownership is a detail many first-time hirers never think to ask about until it becomes a problem, usually when trying to switch developers later and discovering the new developer cannot get clean access to anything. The contract should state explicitly that the client owns all custom code, themes, and configuration produced under the engagement, with no proprietary framework or licensing lock-in that only the original developer can maintain. This is particularly important with smaller agencies that build their own internal boilerplate or component library and then reuse it across every client project, since that can quietly create a dependency where only that specific agency can ever touch the codebase again without a costly rebuild.

Technical competence beyond raw coding ability is worth probing directly, because a developer who can write clean code but does not understand ecommerce-specific performance and search fundamentals will ship a site that looks fine and quietly underperforms. Ask how they approach Core Web Vitals optimization specifically for product and category pages, how they structure redirects and canonical tags during any platform change to protect existing search rankings, and whether they understand structured data markup for products, reviews and pricing, since this directly affects how a store's listings appear in search results and shopping feeds. A developer who cannot speak concretely to at least these three areas is likely to treat performance and SEO as somebody else's problem to fix after launch, which is exactly backwards for an ecommerce project where both directly affect revenue.

Security hygiene deserves explicit questions rather than an assumption that it is handled by default, because payment and customer data are involved and a breach carries real legal and financial consequences beyond just embarrassment. Ask how they handle admin access and password practices, whether they use unique credentials per project rather than a reused password across every client, whether they are aware of PCI DSS obligations relevant to how card data flows through the checkout even when a hosted payment gateway handles the actual card details, and whether they have a documented process for applying security patches promptly when the underlying platform or a plugin ships a critical fix. A vague or dismissive answer here is a genuine risk indicator, not just an area for a follow-up conversation later.

Reference checks need to go beyond the testimonials curated on a developer's own portfolio page, which are obviously selected to be positive and rarely mention anything that went wrong along the way. Ask for the direct contact of at least one past client and actually reach out, asking specifically about how the developer handled a problem or a disagreement during the project, not just whether the final result looked good. A developer with strong client relationships will not hesitate to connect you, and one who deflects or only offers written testimonials rather than a real introduction is worth a harder look before committing to a significant engagement.

Solo freelancer versus small agency versus larger firm is a genuine tradeoff worth thinking through deliberately rather than defaulting to whichever option seems cheapest on paper. A skilled solo freelancer often delivers faster and cheaper for a well-defined project, but carries real bus-factor risk if they get sick, take on too many clients at once, or simply become unresponsive mid-project with no backup covering the work. A small agency costs more per hour on average but usually has redundancy, a project manager keeping timelines honest, and a broader bench of skills for edge cases a solo developer might not have encountered before. Neither option is universally correct, and the right choice depends heavily on how much the business can realistically tolerate a single point of failure disappearing without warning at the worst possible moment, such as the week immediately before a major planned sale event.

A clear, written scope of work protects both sides and should exist before any code gets written, covering deliverables, a realistic timeline with named milestones, and an explicit process for handling change requests that come up mid-project, because they always do. Agree in advance on how additional requests outside the original scope get priced and approved, ideally with a simple written change order process rather than an awkward verbal negotiation happening after work has already quietly started on the new, unscoped item. A contract that also specifies a reasonable kill fee or notice period if either party needs to end the engagement early protects the client from being left with an unfinished, unmaintainable half-built store and protects the developer from unpaid work on a project that gets cancelled without warning partway through.

During the actual interview, a short list of direct questions surfaces most of what matters faster than a long resume review ever will. Ask what platform and version of that platform they most recently shipped a live store on, ask them to describe the last production bug they had to fix under time pressure and how they diagnosed it, ask how they would approach migrating an existing store's SEO rankings if that is relevant to the project, and ask them to walk through, specifically, what a typical week of communication with a client looks like on an active project. The quality, specificity and honesty of these answers, more than any credential or portfolio piece, is the strongest signal available before committing budget and, more importantly, launch-critical timelines to someone you have not worked with before.

The proposal or estimate a developer sends back after an initial scoping conversation is itself one of the most useful vetting signals available, and it is worth reading closely rather than just comparing the bottom-line number. A strong proposal breaks the project into distinct phases or deliverables, names specific assumptions it is relying on, such as which apps or plugins will be used and what happens if the client's existing product data is messier than expected, and flags risks or open questions rather than presenting a single suspiciously round number with no supporting detail. A proposal that is vague on scope but very precise on price is usually vague on purpose, leaving room to bill extra for anything not explicitly listed, while a proposal that over-specifies scope but hedges on price is often more honest about the genuine uncertainty in a project that has not been fully discovered yet.

Engagement structure, whether fixed price, hourly, or a monthly retainer, changes the incentives at play and is worth choosing deliberately rather than defaulting to whatever a developer proposes first. Fixed price works well for a clearly scoped, well-defined deliverable like a theme customization or a specific integration, but incentivizes cutting corners or padding the estimate heavily to cover unknowns, and it breaks down fast if scope changes mid-project. Hourly billing is more transparent for exploratory or open-ended work but requires real trust and a way to track progress against a rough budget ceiling, since an hourly arrangement with no cap can drift well past what was originally expected without deliberate check-ins. A monthly retainer suits ongoing maintenance and incremental feature work well, but only once the store is stable and the relationship is already proven, not as the very first engagement with someone unvetted.

A defined warranty or bug-fix period after launch protects against a developer disappearing the moment final payment clears, which is a more common problem than most first-time hirers expect. Agree explicitly, in writing, on a window, typically two to four weeks after launch, during which any bugs directly caused by the delivered work get fixed at no additional charge, distinct from new feature requests which should reasonably be billed as new scope. This single clause resolves more post-launch disputes than any other line in a typical contract, because it draws a clear, agreed-upon boundary between a genuine defect in delivered work and a new request dressed up as a bug report after the invoice has already been paid.

Accessibility and basic legal compliance competence is worth checking directly, particularly for businesses selling into markets with active accessibility litigation or clear regulatory expectations around digital storefronts. Ask whether the developer builds with keyboard navigation and screen reader compatibility in mind by default, or treats it as an afterthought only addressed if a client specifically demands it, since retrofitting accessibility onto a finished site is considerably more expensive than building it in from the first component. This matters commercially as well as ethically: a store that is difficult to navigate for a meaningful share of potential customers using assistive technology is leaving real revenue on the table, independent of any legal exposure the gap might also create in markets with active accessibility enforcement.

Where a business actually looks for candidates shapes the quality of the pool before any vetting even starts, and it is worth being deliberate about the channel rather than defaulting to whichever platform comes up first in a search. General freelance marketplaces offer volume and competitive pricing but require heavier vetting since anyone can create a profile and inflate a portfolio with template demos. Curated platforms that pre-screen technical talent charge a premium but reduce the vetting burden considerably, since much of the portfolio and skills verification has already happened before a candidate is even presented. Agency directories that collect verified client reviews tied to specific completed projects, and simple referrals from another business owner who has actually used the developer for a comparable project, remain two of the more reliable sources precisely because the accountability trail is harder to fake than a marketplace profile with paid-for reviews.

Weigh all of this together rather than treating any single factor as disqualifying on its own, since even strong developers will have one or two answers that are not perfect. A developer with a slightly higher rate but a verified live portfolio, a clear staging-to-production workflow, and a reference who genuinely vouches for their communication under real pressure is a meaningfully safer bet than a cheaper option with a vague scope, no signed contract, and a portfolio that quietly turns out to be nothing more than unmodified theme demos once anyone actually clicks through and checks. The checklist above is not about finding a mythical perfect candidate, it is about converting a decision that is normally made almost entirely on gut feeling and a polished profile photo into one backed by verifiable evidence, which is exactly the kind of decision an ecommerce business, dependent on that developer for real revenue, cannot afford to get wrong. Run through the live portfolio check, the small paid test project, and one honest reference call before signing anything larger, and treat any resistance to those three simple steps as the most reliable piece of information available before a single dollar of the real project budget is committed to someone whose actual working style you have not yet seen firsthand.