An ecommerce web developer builds and maintains the machine that takes money: the catalogue, the cart, the checkout, and the connections to payments, tax, shipping and inventory. That is a materially different job from building a brochure site, and the difference tends to surface months later in migration bills rather than on the first invoice. Most buyers start from the wrong evidence. They hire on portfolio screenshots, which say almost nothing about how a store behaves under load, how cleanly a product feed publishes, or whether the theme a developer prefers will still be maintainable when the catalogue triples. This page sets out what the work contains, what genuinely moves the price, and the questions that turn a pile of quotes into a comparable shortlist.
What the job actually contains
Strip away the visual design and an ecommerce build is mostly plumbing. Someone has to decide the platform, model the products (variants, bundles, kits, subscriptions), wire the payment gateway and the tax engine, connect shipping rates, and keep inventory honest between the storefront and whatever system the warehouse runs on. Then the same store has to expose a clean product feed so the catalogue can appear in search and shopping surfaces, and it has to keep doing that after every theme change. Google's own ecommerce documentation treats this as the core of the discipline rather than an add-on: how product data is structured, how a site is crawled at catalogue scale, and how pagination and faceted navigation are handled all sit inside the build, not after it. A developer who describes the project purely in terms of pages and templates has scoped the visible half.
What moves the price, and what does not
Four things drive an ecommerce quote up: catalogue complexity, checkout customisation, the number of third party systems that must talk to each other, and migration of existing orders and customers. A store with 60 simple products on a standard checkout is a small job at almost any agency. A store with configurable products, tiered trade pricing, an ERP integration and eight years of order history to move is a large one, regardless of how similar the two look on screen. What moves price far less than buyers expect is the visual design itself, because most builds start from a commercial theme and adapt it. If a quote is dominated by design hours and thin on integration and data migration hours, the risk has not been priced, it has been deferred to you. Ask each candidate to break the estimate into build, integrations, data migration and post launch support, and compare those four lines rather than the total.
Speed, structured data and the search consequences of a build
An ecommerce build decides in advance how much search traffic is available to you later, which is why the choice of developer and the later choice among ecommerce SEO companies are really one decision taken in two stages. Two build artefacts matter most. The first is product structured data: Google documents the required and recommended properties for product markup, including price, availability and review information, and a developer who emits it correctly at template level gives you rich results across the whole catalogue for free. The second is page speed, measured by the Core Web Vitals metrics that web.dev documents, which are heavily influenced by theme choice, image handling and the number of third party scripts a developer allows into the head. Both are cheap during a build and expensive to retrofit. Put both in the specification in writing.
How to vet a shortlist without technical staff
You do not need to read code to separate a professional from a hobbyist. Ask four questions. Who owns the repository and the accounts, and will the code be handed over in a version control system you control? Is there a staging environment, or do changes go straight to the live store? What is the documented rollback if a release breaks checkout on a Friday afternoon? And what happens after launch: is support a retainer, an hourly rate, or nothing at all? Then ask for two references from stores of similar catalogue size and call them, asking specifically about the six months after launch rather than the build. The developers who look identical in a pitch diverge sharply in that period, and the reference call is the only place that difference is visible before you have paid for it.
Questions people ask about ecommerce web developer
Should I hire a freelancer, an agency or a platform partner?
It depends on the failure you can least afford. A freelancer is cheaper and often better technically, but a single person is a single point of failure and cannot cover a launch week outage plus a holiday. An agency costs more and buys continuity, documented process and someone to escalate to. A certified platform partner buys direct access to the platform vendor, which matters mainly when your build depends on features that are still changing. Decide which of those three risks would actually hurt your business, then buy against it.
How long should an ecommerce build take?
For a straightforward catalogue on a hosted platform with no unusual integrations, six to ten weeks is a realistic range from kickoff to launch, most of which is content, product data and testing rather than development. Complex integrations, custom checkout logic or a migration with years of order history routinely double that. Treat any quote promising a complex store in two weeks as a scoping failure rather than a bargain.
Do I own the site the developer builds?
Only if the contract says so. Ask explicitly for assignment of intellectual property in the custom code, and insist that hosting, domain, payment gateway and analytics accounts are created in your name with the developer added as a user. This is the single most common source of pain when a relationship ends, and it costs nothing to fix at the start and a great deal to fix afterwards.
What ongoing budget should I plan for after launch?
Plan for a monthly line covering platform fees, app or extension subscriptions, security and dependency updates, and a small block of development time for the things you will inevitably want changed. A store is an operating system for a business, not a one off purchase, and the sites that decay fastest are the ones whose owners budgeted for a build and nothing after it.