Ecommerce software development: platforms, custom builds and headless explained

Ecommerce software development is the design, building and integration of the software that lets a business sell online: the storefront, product catalogue, cart, checkout, payments, order management and the links to stock, fulfilment and accounting. For most businesses the right answer is not to write all of that from scratch, but to start from a proven commerce platform and build custom software only where it creates an advantage. This guide explains the options, how to choose between them, and the details that decide whether a store converts and stays reliable.

The stakes are large and growing. The US Census Bureau's quarterly estimate for the second quarter of 2026 put ecommerce at 17.1% of total US retail sales, seasonally adjusted. At the same time, buyers are unforgiving: small frictions in speed, checkout or trust send them elsewhere in a click. The software decisions below shape all of that.

What an ecommerce system is made of

A store looks like one website, but behind it sit a dozen distinct capabilities. Knowing them helps you see which ones a platform gives you for free and which ones are worth building yourself.

Your four main options

Almost every ecommerce project lands in one of four approaches. The differences are about how much you control, how much you maintain, and how quickly you can launch.

Shopify, for example, describes its headless option as separating the storefront's front end from its back end, so you can build the shopping experience in your own framework while its APIs handle products, carts and checkout. That middle ground, a proven commerce back end with a custom front end, is where many growing brands end up.

When custom ecommerce development makes sense, and when it does not

Be honest about where your advantage lies. If you sell physical products to consumers with standard shipping and promotions, a hosted platform with a well-built theme will serve you better than a custom build, and the money is better spent on product, photography and marketing. Our guide to custom software versus off-the-shelf explains the wider reasoning.

Custom work starts to pay off in situations like these:

• B2B commerce: company accounts with several buyers and approvers, customer-specific price lists, quotes, credit terms, purchase orders and reorder flows.
• Configurators and made-to-order products: pricing and validity depend on combinations of options, measurements or uploaded files.
• Marketplaces: many sellers, split payments, commissions, seller onboarding and payouts.
• Subscriptions and memberships: recurring boxes, usage-based billing or access tied to services, beyond what subscription apps handle.
• Rentals, bookings and services: availability over time rather than stock in a warehouse.
• Omnichannel operations: click and collect, ship from store, endless aisle and shared stock across shops, warehouses and marketplaces.
• Performance and brand experience: a front end that must be faster or more distinctive than any theme allows.
• Commerce inside a product: purchasing that lives inside a SaaS product or mobile app, where a separate shop would break the experience.

Even then, custom rarely means everything. A typical pattern is a commerce engine for catalogue, cart and checkout, a payment provider for payments, and custom code for the parts that are genuinely yours: the configurator, the B2B approval flow, the integration with your ERP.

Checkout: where most revenue is won or lost

Checkout deserves more design and testing time than any other part of the store. Baymard Institute calculates an average documented cart abandonment rate of 70.22% across 50 studies. Many of those visitors were only browsing, but the reasons the rest give are revealing: extra costs such as shipping, tax and fees were too high (40%), delivery was too slow (20%), they did not trust the site with their card details (19%), the site wanted them to create an account (18%), and the checkout was too long or complicated (17%). Baymard also estimates that the average large ecommerce site could gain a 35.26% increase in conversion rate through better checkout design alone.

• Show the full cost, including delivery and taxes, before checkout rather than revealing it at the last step.
• Offer guest checkout. Invite account creation after payment, when it costs the buyer nothing.
• Ask only for the fields you need, use address lookup, and set the correct input types so mobile keyboards help rather than hinder.
• Offer the payment methods your buyers expect in each market, including wallets and local methods, not only cards.
• Make delivery dates and the returns policy visible before payment, not buried in the footer.
• Keep error messages specific and next to the field, and never clear the form when one field fails validation.
• Test checkout on a mid-range phone on a mobile connection, with a screen reader, and with autofill, before every major release.

Payments, PCI DSS and strong customer authentication

Do not build card handling yourself. Use a payment service provider and its hosted payment page or embedded fields, so card numbers go straight from the buyer's browser to the provider and never touch your servers. This keeps your PCI DSS scope as small as possible. Under PCI DSS v4.0.1, Adyen's summary of SAQ A eligibility explains that all elements of the payment page delivered to the browser must come directly from a PCI DSS compliant provider, and that merchants must also confirm their site is not susceptible to script attacks that could affect their ecommerce systems. If you host your own payment page, the stricter requirements on managing and monitoring payment page scripts apply. Confirm your scope with your acquirer or a qualified assessor rather than assuming.

If you sell to customers in the European Economic Area, card payments are also subject to strong customer authentication under PSD2, usually through 3D Secure. Stripe's SCA guide notes that banks may decline payments that do not support the required authentication, and that saved cards charged later (subscriptions, reorders) need the customer's permission and a correctly flagged off-session payment. Modern payment APIs handle most of this if you use them as designed; problems arise when a custom checkout skips these flows.

• Treat the payment provider's webhook as the source of truth for whether an order is paid, not the browser redirect, which can fail if the buyer closes the tab.
• Make order creation idempotent so a retried payment confirmation never creates two orders or charges twice.
• Plan refunds, partial refunds, chargebacks and failed renewals as first-class flows, not afterthoughts.
• Keep a reconciliation between orders and payouts so finance can match every payment to an order.

Performance: speed is a feature buyers notice

Google's Core Web Vitals give a shared definition of a fast, stable page: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint of 200 milliseconds or less, and Cumulative Layout Shift of 0.1 or less, measured at the 75th percentile of real page loads on mobile and desktop. They matter commercially as well as for search. In a study by Deloitte Digital and Google covering 37 brand sites, published as Milliseconds make millions, a 0.1-second improvement in mobile site speed was associated with an 8.4% increase in conversion rates for retail sites. It was a statistical analysis rather than a controlled experiment, but it points in the same direction as most practitioners' experience.

• Images: serve modern formats at the right size for each screen, reserve their space to avoid layout shift, and lazy-load anything below the first screen.
• Third-party scripts: reviews, chat, tracking, A/B testing and personalisation tools are the usual cause of slow stores. Audit them, remove the ones nobody uses, and load the rest after the page is interactive.
• Apps and plugins: on hosted platforms, each app can add scripts to every page. Fewer, better-chosen apps often beat any amount of tuning.
• Caching: product and category pages can usually be served from a CDN and refreshed when data changes; carts and checkout cannot.
• Measure real users: lab tests are useful for debugging, but field data from real visitors on real phones is what counts.

Accessibility is now a legal requirement in many markets

Accessibility has moved from good practice to obligation for many online sellers. The European Accessibility Act lists ecommerce among the services it covers, and, as Slaughter and May's briefing notes, it has been fully enforceable since 28 June 2025 and reaches businesses outside the EU that sell to EU consumers, with specific exceptions for microenterprises. Enforcement is handled by each member state, so penalties and procedures vary.

The practical benchmark is the W3C's WCAG 2.2 at level AA. Several of its newer criteria bear directly on stores: Redundant Entry (do not make people retype information they already gave, such as a billing address), Accessible Authentication (do not rely on memory puzzles at login), Target Size (buttons large enough to tap) and Focus Not Obscured (sticky headers and cookie banners must not hide the focused field). Build these in from the design stage; retrofitting a finished store is slower and more expensive, and accessibility overlays do not make an inaccessible site compliant.

Integrations: the part customers never see

A store is only as good as the data behind it. Stock that is wrong, prices that disagree with the ERP or orders that never reach the warehouse cause more customer complaints than any design choice. Typical integrations include the ERP or accounting system, a product information management (PIM) system, a warehouse or third-party logistics provider, carriers, tax calculation, the CRM and email platform, marketplaces, reviews and search. Our guide to system integration explains the patterns and reliability rules in depth.

• Decide which system owns each piece of data: price, stock, product content, customer details.
• Reserve stock when an order is paid, not when an item enters the cart, unless you sell scarce items where a short timed reservation makes sense.
• Sync stock often enough for your sales speed, and keep a safety buffer for items that also sell in shops or on marketplaces.
• Make every order flow idempotent and monitored, with a dashboard that shows orders stuck between systems.
• Plan returns end to end: the return request, the warehouse receipt, the stock update and the refund.

Security, fraud and bots

Online stores attract automated abuse: credential stuffing against customer accounts, card testing through checkout, bots buying limited stock, scraping of prices and fake account creation for promotions. The basics go a long way: rate limits and bot protection on login, checkout and promotion endpoints; fraud screening from your payment provider; multi-factor authentication for every admin account; least-privilege staff roles; and a regular review of which apps and scripts can access customer data. For APIs, the OWASP API Security Top 10 is a useful checklist, particularly broken object-level authorisation (one customer seeing another's orders) and unrestricted access to sensitive business flows (bots buying out stock).

Replatforming: moving an existing store without losing what works

Many ecommerce projects are migrations rather than new builds. The risks are predictable, which means they can be planned for.

1. Map every URL. Export all product, category and content URLs from the old store and set permanent redirects to their new equivalents, so search rankings, links and bookmarks survive.
2. Migrate data carefully. Products, variants, images, customers, order history, reviews, gift cards and store credit all need mapping. Password hashes often cannot be carried across platforms, so plan a friendly reset flow.
3. Keep structured data. Product, price, availability and review markup should carry over so search results keep their rich listings.
4. Rebuild integrations and test them with real orders in a staging environment before launch.
5. Freeze changes and launch at a quiet time, with a rollback plan and the team watching orders, payments and errors closely for the first days.
6. Compare before and after: conversion, speed, organic traffic and order errors, so you can spot and fix regressions quickly.

Most ecommerce problems are not about the shop window. They live in checkout, in stock and order data, and in the scripts nobody remembers installing. Fix those first and the design work pays off.

How a build is planned, and what drives the effort

A sensible plan starts small. Launch with the catalogue, checkout and core integrations working well, measure, then add features buyers actually use. Our article on scoping an MVP explains how to decide what goes in the first release. The main effort drivers are:

• Approach: configuring a hosted platform is a fraction of the work of a headless or custom build.
• Catalogue complexity: variants, bundles, configurators, multiple languages and currencies.
• Pricing and B2B rules: customer-specific prices, quotes, approvals, credit terms.
• Integrations: the number of systems and the quality of their APIs, especially older ERPs.
• Design ambition: a tuned theme versus a fully bespoke front end.
• Markets: each country can add tax rules, payment methods, delivery options, languages and legal text.
• Migration: the volume and messiness of data and URLs coming from an old store.
• Compliance: accessibility, payments, consumer law and data protection reviews.

To show how these combine, here are illustrative shapes rather than quotes. A consumer brand moving to a hosted platform with a customised theme, a few apps and an accounting integration is often a job for one or two people over six to ten weeks. A headless storefront on an existing commerce engine, with a custom front end, a headless CMS and ERP and warehouse integrations, is more typically three or four engineers plus a designer over three to five months. A B2B portal with company accounts, approval flows, customer price lists and a two-way ERP integration sits at the larger end again. The software cost calculator can help you explore how your own choices move the estimate.

Mistakes we see most often

• Choosing headless or custom for prestige rather than a specific need, then struggling with the extra systems to run.
• Installing an app for every small need until the store is slow and the apps conflict.
• Customising a platform's checkout beyond what it supports, which breaks on the next platform update.
• Leaving integrations to the end of the project, when they are usually the riskiest part.
• Launching without redirects, losing search traffic that took years to build.
• Treating accessibility as a final audit instead of a design input.
• No owner after launch: platforms, apps, payment rules and browsers keep changing, and a store needs ongoing maintenance and support.

How Authect approaches ecommerce projects

Authect is a founder-led software studio: you talk to the founders who design and build your store, never a salesperson, and every project is led by a senior engineer. We start by asking whether you need custom software at all. If a hosted platform does the job, we will say so; if your model needs a headless front end, a B2B portal or deep integrations, we build those with small teams and AI-accelerated delivery where an engineer reviews every line.

You own the code, infrastructure and designs from day one, so you are never locked in. Work can run as a fixed-price project, as monthly sprints, or as support and evolution after launch. You can read more about our work for ecommerce businesses, see a concept storefront SaaS we designed as a blueprint, or talk to the founders about your store.