Custom ecommerce website development: the complete guide

Most stores should not be built from scratch. Shopify, BigCommerce and their peers solve the hard, boring parts of selling online — PCI scope, tax tables, payment routing, fraud screening, uptime — and they solve them better than a first custom build will. Starting with a hosted platform is usually correct, and staying on one is correct far longer than agencies like to admit.

This article is about the point where that stops being true, and what happens next. It is written for the people who make that call: an ecommerce director watching workarounds pile up, a founder whose product does not fit a product-and-variant model, a CTO being asked whether the platform is the bottleneck.

We build both. The honest version of this decision is that custom development is not better — it is different, and it becomes cheaper only once the constraints of a hosted platform cost more than the engineering does.

What custom ecommerce development actually means

A custom ecommerce build is an application you own, running on infrastructure you choose, backed by a database whose schema you designed. It typically means:

• A storefront built as a web application — usually React with Next.js or Vue with Nuxt — rendering server-side for search engines and speed.
• A commerce layer holding products, variants, pricing, inventory, carts and orders. Either written from scratch, or an existing engine used through its API.
• A checkout you control end to end, including how payment is captured and what happens after.
• An integration layer connecting the store to the systems that actually run the business: ERP, WMS, CRM, accounting, marketing.

What it does not mean is writing a payment processor. Serious custom builds still use Stripe, Adyen or Braintree for payment, and still keep card data out of scope through hosted fields or a payment element. "Custom" describes the commerce logic, not the parts where reinventing is negligent.

The distinction that matters is who owns the model. On a hosted platform, a product is whatever the platform says a product is. In a custom build, a product is whatever your business says it is — which is either irrelevant or the entire point, depending on what you sell.

When a hosted platform stops being the right answer

The signal is rarely "we outgrew it". It is a series of small, expensive workarounds that individually look reasonable and collectively describe a system fighting its foundation.

Here are the ones that reliably predict a replatform, and what each usually means underneath.

The last two rows are the important ones. A meaningful share of "we need to go custom" conversations are actually integration problems or front-end performance problems, and both are cheaper to fix in place. Rebuilding a store to make it fast, when the real cause is eleven marketing tags in the head, replaces a fast fix with a six-month project and often lands slower.

If you take one thing from this article: diagnose before you replatform. The question is not "is our platform limiting us" — every platform limits you. It is "which specific limits are costing us money, and is engineering around them cheaper than living with them".

What you own when you build custom

The data model

This is the single strongest argument for a custom build, and the one most often left out of the pitch.

Hosted platforms model a product as a product with variants along a small number of axes. That is exactly right for a t-shirt in three colours and five sizes. It is wrong for:

• Configurable goods — where the price and the bill of materials depend on choices the customer makes, and the combinations are not enumerable.
• Made-to-measure — where every order is a unique specification.
• Rental and hire — where availability is a function of time, not stock count.
• B2B contract pricing — where the price depends on who is asking, what they committed to, and how much they have already bought this year.
• Bundles with independent stock — where selling one kit decrements six SKUs.

Each of these can be bolted onto a hosted platform. All of them are cleaner as a schema you designed. If your catalogue is one of these, the platform is not a constraint you will grow out of; it is one you started with.

The checkout

Checkout is where a custom build earns or loses its keep. Owning it means you can add a step, split a payment, apply a rule at the moment it matters, or remove a field that nobody was completing.

It also means you own the consequences. Checkout is the most conversion-sensitive surface you have — Baymard Institute maintains a rolling average across published studies putting documented cart abandonment around 70%, and a meaningful part of that is the checkout itself. Building your own is an opportunity to do better and an opportunity to do considerably worse.

The rule we work to: own the checkout logic, not the card data. Use a payment provider's hosted fields or payment element so raw card details never touch your servers. You keep control over flow, validation, pricing and post-purchase behaviour, and your PCI obligations stay near the lightest self-assessment tier rather than a full audit. Losing that distinction is how a custom build turns into a compliance project.

The integration layer

In most businesses the storefront is the smallest system it touches. Orders go to an ERP, stock comes from a WMS, customers go to a CRM, invoices go to accounting, and each of those has opinions about format and timing.

On a hosted platform you integrate through whatever the platform exposes, at whatever rate limit it enforces. In a custom build the integration layer is yours to design: you decide what is synchronous, what is queued, what is retried, and what happens when the ERP is down for maintenance at 2am on a Sunday. That is real engineering work, and it is the part most likely to be underestimated. It is also where the value usually is — see our writing on connecting a storefront to the systems behind it.

The stack decisions that matter

Once the decision is made, four choices shape everything after it. None has a single right answer, but each has a wrong one for a given situation.

For the commerce layer itself the honest split is: build it if the model is the reason you left the platform; buy it if the model is fine and the front end was the problem. A commerce API you consume — including Shopify's own Storefront API — is a legitimate answer to "we need a custom front end and a standard back end". That is headless commerce, and it is a different decision from this one.

On the database, our default is PostgreSQL, for a reason specific to commerce: ecommerce data is deeply relational and correctness matters more than flexibility. Orders reference customers, lines reference variants, stock movements reference both, and every one of those relationships is a place a document store lets you write something inconsistent at 3am under load. Constraints and foreign keys are cheaper than reconciliation.

What custom development does not automatically buy you

Three claims get made for custom builds that are not true by default, and it is worth being blunt about them.

What a custom build genuinely gives you

• A data model that matches how you actually sell
• Checkout and pricing logic with no platform veto
• Integration design you control, including failure behaviour
• No per-transaction platform fee, and no app subscriptions
• The ability to ship a change without waiting for a vendor roadmap

What it does not give you for free

• Speed. A custom storefront is fast only if someone makes it fast. It is entirely possible to ship something slower than the theme it replaced.
• SEO. You inherit responsibility for rendering, canonicals, structured data, sitemaps and redirects — all of which the platform was quietly handling.
• Less work. You have taken on hosting, monitoring, dependency upgrades, security patching and on-call. That work does not disappear; it moves to you.
• Security by default. Platform-managed fraud screening, rate limiting and bot mitigation now need explicit answers.

The performance point deserves emphasis because it is the most common disappointment. A framework does not make a site fast; disciplined engineering does. Custom builds ship slowly when they render everything on the client, fetch waterfalls of data, and load the same marketing scripts that were slowing the old theme down. We write about the measurable side of this in Core Web Vitals for ecommerce.

How a custom build is delivered

The sequence below is roughly how we run these, and more importantly the order in which risk gets retired. If a proposal you are reading does not front-load the data model and the integrations, it is optimistic.

1. Model the catalogue first — Before any interface work, write down what a product, a variant, a price and an order are in your business. Every later decision inherits from this, and it is the cheapest thing to change now and the most expensive to change later.
2. Prove the hardest integration — Pick the integration most likely to be a problem — usually the ERP or the stock feed — and build a working slice of it early. Integrations fail on other people's constraints, and you want to find those in week two rather than week twenty.
3. Build checkout before catalogue browsing — Checkout is the highest-risk, highest-value path. Building it early means it gets the most iterations, and browsing is the easier half to finish under pressure.
4. Set the performance budget before the first page ships — Decide the acceptable numbers up front and measure every build against them. A budget agreed at the start is a constraint; one introduced at the end is an argument.
5. Plan the URL map and redirects with the content, not after launch — Every URL that changes needs a permanent redirect on day one. This is the single most common cause of traffic loss at launch, and it is entirely preventable.
6. Migrate data twice — Run a full rehearsal migration into a staging environment, check it properly, then run it again for real. The rehearsal is where you discover the twelve years of malformed records nobody remembered.
7. Launch behind a real rollback — Keep the old store serving until the new one has proven itself, and be able to switch back within minutes. A launch you cannot reverse is a launch you will defend rather than fix.

What drives the cost and the timeline

We do not publish a price for this work, and it is worth explaining why rather than being coy about it: the range for a custom ecommerce build is wide enough that any number we printed would either be a floor nobody is actually quoted or a figure the proposal contradicts. What is useful is knowing which variables move it, so you can estimate the shape of your own project before talking to anyone.

The main drivers, roughly in order of impact:

1. Catalogue complexity. How many dimensions a product has, whether pricing is computed, and whether availability is a simple count.
2. Integration count and quality. Two well-documented REST APIs are a fraction of the work of one undocumented SOAP endpoint owned by a vendor who answers weekly.
3. Migration scope. Ten thousand products with clean data is a smaller job than two thousand with fifteen years of manual corrections.
4. Checkout requirements. A standard flow with a mainstream provider, versus split payments, deposits, quotes or purchase orders.
5. Content and merchandising needs. Whether marketing needs to build landing pages without a developer — which is a CMS project inside the commerce project.
6. Internationalisation. Currencies, tax rules, languages and per-market catalogues each multiply testing surface.

A useful exercise before any conversation with an agency: write down your answers to those six. It converts a vague brief into a scoped one, and it will change the proposals you get back more than anything else you could do.

If you want a second opinion on whether custom is the right answer for your situation, tell us what you are working with — the useful version of that conversation usually ends with "stay where you are and fix these three things", and we would rather say that early than late.

Key takeaways

• Hosted platforms are the right default. Custom becomes cheaper only when platform constraints cost more than the engineering.
• The strongest reason to build custom is a data model the platform cannot express — not speed, and not design.
• Own the checkout logic; do not own the card data. That distinction keeps PCI scope manageable.
• Custom does not make a site fast, findable or lower-maintenance by default. Each is now your responsibility.
• Front-load the data model and the hardest integration. Both are where projects actually fail.
• Diagnose before replatforming — performance and integration problems are usually cheaper to fix in place.