Custom ecommerce website development.

Most stores should not be custom-built. A hosted platform handles payments, PCI scope, hosting and updates for a fraction of what engineering the same thing costs, and part of our job on the first call is working out whether you are in that case. We lose contracts saying so, and we would still rather say it than build something that was never going to pay for itself.

This page is about the other case: when the platform itself is the constraint, and the answer is software rather than configuration. If you are looking for Shopify work specifically, that is Shopify development and customization and it is a different page.

What custom ecommerce development actually means

Custom means your store is an application your company owns, not a tenancy on someone else's. There is a repository, a database schema, a deployment pipeline and a test suite. Behaviour that a hosted platform would express as an app subscription or a workaround is expressed here as code, and it does what your business does rather than what the closest available setting allows.

Concretely, a build in this category is usually four things assembled together: a storefront in Next.js, React or Vue.js; a commerce API in Node.js or Laravel that holds the catalogue, cart, pricing rules, orders and accounts; a PostgreSQL schema modelling how you actually sell; and an admin console your team works in daily. Payments go to Stripe, PayPal or a local gateway. None of it is licensed back to you.

When a hosted platform stops being enough

Nobody commissions custom software because they want custom software. In ten years the trigger is almost always one of five things, and the first two rarely justify the build on their own.

• The catalogue has outgrown the platform's model. Configurable and made-to-order products, deep variant matrices, kits and bundles, products priced by weight or dimension, or the same item sold under different terms to different accounts.
• Pricing is a business rule, not a number. Contract prices per account, tiered and volume breaks, credit limits, quotes that become orders, approval chains. When the platform cannot express it, someone maintains the difference in a spreadsheet and the spreadsheet becomes the system of record.
• Fulfilment does not look like parcels. Delivery slots with capacity, substitutions, split shipments from multiple locations, weight-adjusted invoicing after picking, multi-vendor payouts.
• The app stack is now the cost centre. A dozen subscriptions approximating three features, each injecting script into every page, and a monthly bill that grows with order volume rather than with value delivered.
• Nobody will touch the code. Years of small edits by different hands leave a codebase where every change is a gamble, so development stops — the risk of shipping exceeds the value of the change.

Two or three of those together is a strong signal. One on its own is usually cheaper to solve where you are, and we will tell you when that is the case.

Hosted platform, or custom build?

The honest way to frame this is not "which is better" but "what are you buying, and what are you giving up". We build both, so the comparison below costs us nothing either way.

Hosted platform against a custom build, on the differences that decide a project

Consideration	Hosted platform	Custom build
Time to first sale	Fastest available	Longer — the platform is being written, not configured
Business rules	What the platform and its apps support	Whatever the business actually does
Checkout control	Limited, and tier-dependent	Complete, including the steps and their order
Ongoing cost shape	Subscriptions and per-order fees that scale with volume	Hosting and engineering, which scale with change
PCI scope	Largely handled for you	Reduced by tokenised gateways, but yours to hold
Ownership	Your data; their platform	Repository, schema and pipeline are yours
Who can maintain it	A large pool of platform specialists	Any competent team in that framework — which is why the framework choice matters

A hybrid is often the right answer and is worth asking about explicitly: a hosted storefront in front, a custom system holding the logic behind it, with the two kept in step over an API. It is less satisfying than a clean rebuild and frequently the cheaper, lower-risk route.

The stack, and how the choice gets made

We are opinionated about engineering standards and deliberately not opinionated about frameworks. The stack is decided in discovery against your operation and your team, not chosen because it is the one we are fastest in.

Next.js and React

The default where organic search matters. Server rendering, streaming and route-level caching are built into the framework rather than bolted onto it, which is the difference between a fast catalogue page and a fast catalogue page you have to keep defending. React's hiring pool is the largest of any front end, so handover is rarely the constraint.

Vue.js

The better answer when your own team already writes Vue. A stack nobody internal can extend is a liability whatever its benchmarks say, and the gap between a well-built Vue storefront and a well-built React one is far smaller than the gap between a codebase your developers own and one they are afraid of. Vue's single-file components also tend to keep merchandising work readable for people who are not primarily front-end engineers.

Node.js

For commerce APIs that are event-driven or high-concurrency, and for teams who want one language across the stack. Sharing types and validation schemas between the storefront and the API removes an entire category of bug — the one where the front end and the back end disagree about what an order looks like — and it makes contract changes a compile error rather than a support ticket.

Laravel

The fastest route to a rich admin, queues, scheduled jobs and a mature ecosystem for tax, invoicing, permissions and multi-tenancy. Where a project's weight sits in back-office workflow rather than in storefront interactivity, Laravel usually gets there with less bespoke code — which means less to maintain. The Servana ordering platform is a Laravel build for exactly that reason: contract pricing, credit limits and an internal order-entry mode for the sales team were the product.

PostgreSQL and Redis

Postgres holds the catalogue, orders and pricing rules, with constraints and indexes doing the work rather than application code hoping for the best. Redis carries caching, sessions, rate limiting and background queues. Both are boring, well understood and unlikely to become somebody else's commercial decision.

Choosing the back end: Laravel against Node.js

If this describes the project	Usually
Back-office workflow, invoicing and permissions are the bulk of the work	Laravel
Real-time inventory, high request concurrency, event-driven integrations	Node.js
Your in-house team is PHP	Laravel
Your in-house team is TypeScript, and shares code with the storefront	Node.js
A large existing Laravel or Node system already runs part of the business	Match it — a second runtime is a permanent tax

Owning the checkout

Checkout is the single strongest argument for building custom, because on a hosted platform it is the part you are least allowed to change and the part where money is lost. Owning it means deciding how many steps there are, what appears on each, when shipping and duty are calculated, which payment methods are shown to whom, and what happens when a payment fails.

What we have measured moving the number is rarely the thing clients expect. Trust badges, progress indicators and button reordering have repeatedly done nothing. Showing landed cost — duty and tax included — before the final step has repeatedly done a great deal, because the abandonment it prevents is caused by a surprise rather than by hesitation. So we instrument the funnel first and change the thing the data points at, with the sample size agreed before a test starts rather than after the result looks encouraging.

Integrations, which is where the effort actually goes

On most custom builds the storefront is the visible part and the smaller one. The work is in the systems the store has to agree with: an ERP that owns stock and pricing, a 3PL or warehouse that owns fulfilment, an accounting system that owns invoices, a tax engine, a PIM, a CRM, and whatever internal tool somebody built years ago that nobody is allowed to switch off.

These are written as explicit, testable interfaces with retries, idempotency and reconciliation, not as a nightly script that assumes everything worked. The question we ask about each one is what happens when it is down for an hour, because that is the scenario that decides whether your operations team trusts the system.

Replatforming without losing your rankings

This is where migrations go wrong, and the damage is not always visible for a quarter. Every migration we run starts with a complete URL map: each legacy path is either preserved or given a permanent redirect, and the map is reviewed against the pages that actually earn traffic rather than against a crawl alone.

Structured data is rebuilt before launch, not after. Canonicals, pagination and internal linking are rebuilt with it, because a store that redirects perfectly and then orphans half its categories has still lost the rankings. Customers, order history and subscription state come across alongside the catalogue. The cutover is rehearsed against a clone of production, so launch day is a repeat rather than an attempt.

Where the search side of that matters as much as the engineering, it is worth reading ecommerce SEO and digital marketing as well — the two are usually scoped together on a replatform.

Custom is not automatically fast

A bespoke build removes the app scripts and the theme bloat, and then hands you every other way to be slow: unbounded queries, images served at the wrong size, a client bundle that grows with each release, a third-party tag manager loading ahead of content.

So performance is a written deliverable rather than an aspiration. Rendering strategy is decided per route, query budgets are set and enforced, and we measure against field data rather than a lab score, because the number that matters is the one your customers get on their actual phones. On the Kavara storefront, a Next.js build over a 3,000-SKU catalogue, collection pages render in under a second at the 75th percentile and paid CPA fell 19% in the first quarter.

Security, PCI and what you are taking on

Owning the platform means owning its security, and the honest version of that is worth hearing before you commit rather than after. What it does not mean is handling card data. We integrate payment providers through hosted fields or hosted checkout, so the card number is captured inside the provider's own iframe and the application only ever sees a token — which keeps most merchants in the lightest PCI self-assessment category rather than a full audit.

Everything else is ordinary engineering discipline applied consistently: parameterised queries, server-side authorisation on every write, rate limiting on anything unauthenticated, a content security policy, dependency monitoring, and audit trails on the actions that move money or change prices. It is the same standard we hold our own products to.

Industries we build for

Fashion and apparel, where variant depth, sizing and returns decide whether the catalogue works. Health and beauty, where refills, bundles and subscriptions decide whether customers come back. Food and grocery, where delivery slots, substitutions and weight-based pricing break most storefronts outright — the reason Fastmart exists as a platform of our own. B2B and wholesale, where contract pricing, quotes, credit limits and account-based ordering are the whole job, and where Servana moved 82% of order volume off WhatsApp within two quarters.

Where the logic behind the store is larger than the store itself, the work shades into custom software development, and we scope it the same way. Where it needs an app in front of it, that is mobile app development.

What it costs, and how long it takes

We do not publish a price list, and the reason is not coyness. Two stores with the same product count can differ by a factor of five in effort depending on how many systems have to be integrated, how much of the catalogue model is bespoke, whether an existing store is being migrated, and how much of the business logic has to be built rather than configured.

What you get instead: a free consultation with a senior engineer, a written scope that names the risks we can see, and a proposal against it. If you are replatforming, the audit that informs it is free as well. Nothing about that process obliges you to proceed, and the audit is yours whether you do or not.

Why brands choose Coder71

Ten years, over a thousand ecommerce projects, and clients across the United States, Canada, the United Kingdom, Australia, Europe and the Middle East. A senior engineer overlaps your working hours wherever you are, you get repository access and a staging link from the first sprint, and the engineers who build the store are the ones who support it afterwards — there is no handover to a desk that has never seen the code.

If you would rather add engineers to your own team than outsource the build, that is IT staff augmentation, and it is a shorter conversation. Otherwise see the case studies, or book a free consultation and tell us what your platform will not let you do.