Custom ecommerce development, the four things that are genuinely custom and the quote questions that tell a build from a theme

Custom ecommerce development is worth buying when a hosted platform cannot express how you sell, and it is a bad purchase when the real problem is a theme. The honest test is to name the thing your store has to do that the platform refuses, in one sentence, before you take a single quote. If you cannot name it, you are buying a redesign with a developer's price tag. Google Keyword Planner shows 210 searches a month in the United States for this group of phrasings, read on 31 October 2026 against the United States geo target, counted as the maximum of the group rather than the sum.

The four areas where a platform actually runs out

Pricing logic. Contract pricing per customer, quantity breaks that differ by account, unit of measure conversions, and quotes that have to be approved before checkout. Hosted platforms handle some of this on their higher tiers and none of it cleanly at the entry level. This is the most common legitimate reason for a custom build and it is almost always a business to business reason.

Product configuration. If the thing in the basket is assembled rather than picked, with dependent options, exclusions and a price that is computed rather than looked up, you are building a configurator. Configurators are software, not content.

Fulfilment and inventory reality. Multiple warehouses with different cut-off times, partial shipments, serialised stock, or made-to-order lead times that have to show on the product page. The checkout is easy. Telling the truth about availability is the build.

Integration depth. One ERP that owns the customer record and refuses to be the follower in a sync. If your system of record is not the store, a lot of custom work is really integration work, and it should be priced and tested as such.

If your answer is none of those four, the cheaper and faster route is a platform plus a custom theme plus two or three apps, and the money you save goes into product data and photography, which move revenue sooner than architecture does.

What the quote is really for

A custom ecommerce quote covers far more than the storefront a stakeholder is picturing. Ask for the number broken into these lines, and treat a single lump sum as a reason to keep asking.

• Discovery and the data model, including what the product record has to hold
• Storefront build, by template rather than by page
• Checkout and payments, naming the provider and who holds the merchant account
• Catalogue and order integration, named system by named system
• Search and merchandising, which is a separate component in most custom builds
• Migration of products, customers, orders and URLs
• Testing, including a load test at your real peak
• Hosting, monitoring and the first year of patching

The last line is where custom builds go wrong financially. A hosted platform charges you a fee and absorbs security patching, PCI scope and uptime. A custom build moves all three onto you, and a quote that omits the retainer has not quoted the project. Ask what the monthly cost looks like in year two, with nobody adding features.

The five clauses that decide whether you own it

One, intellectual property assigns to you on payment, including anything the team wrote for you that sits in a shared internal library. Two, the repository lives in your organisation's account from the first commit, not migrated at handover. Three, infrastructure runs in accounts you own, with the agency added as a user. Four, the handover deliverable is named in the contract and includes a runbook, an environment setup that a new developer can follow, and the test suite. Five, a defined support window after launch at a stated rate, so the people who wrote it are available when the first real peak arrives.

These five are cheap to ask for before a contract and close to impossible to retrofit afterwards. The pattern to watch for is a studio that is genuinely good at building and quietly structured so that leaving is expensive. The same question applies to hosting, which is why what changes when one supplier holds both the build and the hosting is worth reading before you sign.

Three things to settle before the build, not during

The URL map. Every existing product, category and content URL maps to a destination, with a redirect, before anything is built. A replatform that loses its URL structure loses the demand that was already arriving, and the recovery takes months. This is the single most expensive mistake in the category.

The product data contract. Decide what a complete product record contains, field by field, and who fills each field. Custom builds fail on empty fields far more often than on architecture.

What the store renders on the server. If the price, the stock state and the product description only exist after JavaScript runs, then anything that reads the HTML without executing scripts sees a shell. That includes some crawlers, some aggregators, some marketplace feeds and the fetchers behind assistant answers. Put the facts in the first response and treat client-side enhancement as enhancement.

How to judge two very different quotes

Normalise them before you compare. Put both on the same template count, the same integration list and the same migration scope, then ask each team to price the same change request: add a second warehouse with its own cut-off time. The spread on that one change tells you more about the architecture than the proposal does, because a team with a clean data model quotes it small and a team that hardcoded the first warehouse quotes it large or goes quiet.

Then ask for two references with a store still running three years later, and ask those references one question: who maintains it now. The answer separates a build that was handed over from a build that was kept.

Questions buyers ask about custom ecommerce development

Is headless the same thing as custom

No. Headless describes where the storefront code runs relative to the commerce engine. You can run a headless storefront on a hosted platform and keep the platform's checkout, patching and PCI scope, which is often the best of both. Decide custom against hosted first, then decide headless.

How long does a custom store take

Ask instead what the first revenue-carrying milestone is. A build that cannot take an order until month nine is a different risk from one that launches a narrow catalogue in month three and widens. Phase it so something is live and earning before the budget is half spent.

Can we start on a platform and go custom later

Yes, and it is usually the right order. Keep the product data clean and the URLs sensible from the start, because those two are what a later migration either inherits or breaks.

Who should own the payment integration

You hold the merchant account and the payment provider relationship. The developer integrates. Any structure where the agency sits between you and the money is a structure to decline.

What is a fair way to pay for this

Milestones tied to demonstrable function, not to calendar dates, with a retention held until the handover deliverables listed in the contract have actually arrived. Time and materials works only with a team you have already worked with.

The shortlist that happens before your store does

A custom build is a bet that your store will be the place a shopper decides. Increasingly the deciding happens earlier, in an answer somebody gets when they ask an assistant which supplier handles their case, and that answer is assembled from text rather than from your checkout. AI Knows Us measures whether those answers reach your name and which pages they pull from, and the useful version of that measurement is taken before a replatform rather than after, because the pages worth keeping are the ones already doing the work.