Nearly every ecommerce quote you receive is really an answer to one question you may not have been asked. Are you buying a platform you configure, or software you own? Shopify and a custom build are both sold as “ecommerce development”, they cost different orders of magnitude, and the right answer is usually the cheaper one.
Shopify or BigCommerce until a specific named requirement makes it impossible.
Subscriptions compound and each app is a dependency that can break or be abandoned.
Right when content and merchandising are a genuine differentiator, not before.
Fraud, tax and uptime become permanently yours. Only for genuinely unusual commerce.
On this page
- Platform, custom, or headless
- What actually drives the cost
- Replatforming without losing your search traffic
- What your checkout has to support
- The rules a storefront has to meet, who issues each one, and what we do about it
- The systems a store has to talk to
- What to ask any ecommerce development company
- What we build for retail and commerce
- Published commerce case studies
- Frequently asked questions
- Ecommerce development with Sthenos
- Talk to our engineers
Platform, custom, or headless
Hosted platform
The honest default
- Checkout, payments, PCI scope and hosting handled for you
- Right when the catalogue and the checkout are standard, which is most stores
- The real cost is monthly fees plus per-transaction cuts, and hard limits on checkout logic below the top tier
Fully custom
Only when a named requirement forces it
- Complete control of catalogue, pricing and checkout
- Right when pricing, B2B contracts or fulfilment are genuinely unusual
- The real cost is that you inherit PCI scope, fraud, tax and uptime, permanently
Those are the two poles. The table below adds the two routes between them, and what each one really costs.
| Route | What you get | Right when | The real cost |
|---|---|---|---|
| Hosted platform (Shopify, BigCommerce) | Checkout, payments, PCI scope and hosting handled for you | Standard catalogue and standard checkout, which is most stores | Monthly fees plus per-transaction cuts, and hard limits on checkout logic below the top tier |
| Platform plus apps | The gaps filled by third-party apps | You need a handful of specific behaviours | App subscriptions compound, and every app is a dependency that can break or be abandoned |
| Headless | Custom storefront, platform commerce engine behind it | Content and merchandising are a genuine differentiator | You now own a frontend, with its own build, hosting and performance work |
| Fully custom | Complete control of catalogue, pricing and checkout | Genuinely unusual pricing, B2B contracts, or complex fulfilment | You inherit PCI scope, fraud, tax and uptime, permanently |
The honest default is a hosted platform until a specific, named requirement makes it impossible. “We might want flexibility later” is not that requirement, and it is the most expensive sentence in ecommerce procurement.
What actually drives the cost
- Catalogue complexity. Variants, configurable products, bundles and per-customer pricing each multiply the data model and the testing surface.
- Integrations. ERP, warehouse and fulfilment, tax, and accounting. Order data has to reconcile across all of them, and reconciliation is where the hidden work lives.
- B2B requirements. Quotes, approval chains, credit terms and contract pricing turn a store into an application.
- Migration. Moving an existing store means products, customers, order history and every URL. The redirect map is not optional and is routinely forgotten until traffic drops.
- Performance. Conversion tracks page speed closely enough that it belongs in scope from the start, not in an optimisation phase afterwards.
- Catalogue size. The number of SKUs decides how much of the work is data rather than code: import and cleanup, attribute modelling, search tuning and the testing surface all scale with it.
- Order volume. Orders per month is the other sizing axis, because it decides how much of the fulfilment path can stay manual, what the integrations have to sustain, and how hard the busiest trading day of the year actually is.
Replatforming without losing your search traffic
The most expensive ecommerce mistake we see is a technically clean migration that silently loses organic rankings, because the SEO work was treated as a marketing task after launch rather than an engineering deliverable during it.
- Map every old URL to a new oneBefore launch, including retired products, which should go to a relevant category rather than to a generic 404.
- 301, never 302Temporary redirects do not pass ranking signals, and the difference is invisible until it is not.
- Keep the structured dataProduct, price, availability and review markup drive how listings appear, and it is easy to lose in a rebuild.
- Benchmark before you cut overCapture rankings, traffic and Core Web Vitals first, so a regression is provable rather than arguable.
What your checkout has to support
A checkout is a list of payment routes, and the routes a US store is asked for are fairly predictable: card payments taken online, digital wallets built into a phone or a browser, card present and NFC at a counter where the business also sells in person, ACH and bank transfer on larger or recurring orders, buy now pay later offered through a provider, and stored cards for repeat purchase and subscriptions. Marketplaces and social checkouts add a route that is not on your site at all, which is a data problem rather than a payment one.
The engineering question is not which routes you like. It is where the card data goes, because that single decision sets your annual compliance work for the life of the store. The PCI Security Standards Council issues PCI DSS and publishes a different Self-Assessment Questionnaire for different environments, each with its own eligibility criteria written into the document.
- The payment page is entirely the processor’s. SAQ A covers merchants with “account data functions completely outsourced to PCI DSS validated and compliant third parties”, and for ecommerce it requires that “All elements of the payment page(s)/form(s) delivered to the customer’s browser originate only and directly from a PCI DSS compliant TPSP/payment processor.”
- Your site never receives card data but shapes the page that does. That is SAQ A-EP, for an ecommerce site that “does not itself receive account data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the customer’s account data”. An embedded field and a script on the checkout page both land here.
- Your systems touch card data. SAQ D for Merchants “applies to merchants that are eligible to complete a self-assessment questionnaire but do not meet the criteria for any other SAQ type”, and the first example the document gives is “E-commerce merchants that accept cardholder data on their website.”
So an afternoon’s decision about whose form collects the card sets which questionnaire somebody answers every year afterwards, and how much of the store is inside the assessment when they do. We design checkouts to keep card data out of your environment unless a named requirement makes that impossible, and we tell you which questionnaire the design implies before it is built rather than after.
The rules a storefront has to meet, who issues each one, and what we do about it
Four bodies of rule and one technical standard reach an ordinary online store. None of them is a badge Sthenos holds, and the honest sentence is the same one we use everywhere else on this site: we build to them and we hand you the evidence, which is different from claiming an attestation and is the only version that survives a buyer checking.
| Rule | Who issues it | Who it binds | What a build has to do under it |
|---|---|---|---|
| PCI DSS | PCI Security Standards Council | The council’s own scope statement: “Entities that store, process, or transmit cardholder data (CHD) and/or sensitive authentication data (SAD) or could impact the security of the cardholder data environment (CDE). This includes all entities involved in payment card processing”. Whether you have to validate, and how, is set by your acquirer or payment brand rather than by the council. | Keep the cardholder data environment as small as the business allows, know which Self-Assessment Questionnaire the architecture implies, and be able to show it. The standard is “a baseline of technical and operational requirements designed to protect payment account data”, so the build has to be able to evidence those requirements, not merely pass a scan. |
| WCAG 2.2 | W3C, a W3C Recommendation published 12 December 2024 | Not a law in itself. It is the technical standard the US Department of Justice points to in its own ADA web guidance, and it defines three conformance levels, A, AA and AAA. | Build against the four principles the standard sets out: content must be Perceivable, “presentable to users in ways they can perceive”; Operable, so “user interface components and navigation must be operable”; Understandable; and Robust, “enough that it can be interpreted by a wide variety of user agents, including assistive technologies”. Level AA conformance, in the standard’s own words, means “The Web page satisfies all the Level A and Level AA Success Criteria, or a Level AA conforming alternate version is provided.” |
| ADA, Titles II and III | US Department of Justice, Civil Rights Division | Title II covers “all services, programs, and activities of state and local governments”. Title III “prohibits discrimination against people with disabilities by businesses open to the public”, which is what an online store is. | The Department’s guidance says covered entities must ensure that the programs, services, and goods that they provide to the public, including those provided online, are accessible to people with disabilities, and it points to technical standards such as WCAG rather than prescribing one. In practice that means keyboard operation, real form labels, contrast and alternative text designed in, not retrofitted, and the checkout tested the same way the catalogue is. |
| GDPR | European Parliament and Council of the European Union, Regulation (EU) 2016/679 | Article 3(2) reaches a controller “not established in the Union” where the processing relates to “the offering of goods or services, irrespective of whether a payment of the data subject is required, to such data subjects in the Union”. A US store that ships to the EU is inside that sentence. | Article 25 requires data protection by design and by default, “appropriate technical and organisational measures, such as pseudonymisation … designed to implement data-protection principles, such as data minimisation”. Article 32 names encryption and pseudonymisation of personal data and “a process for regularly testing, assessing and evaluating the effectiveness” of those measures. For a store that is a real deletion path, a real export path, and a data model where marketing consent is a field rather than an assumption. |
| CCPA | California Department of Justice, Office of the Attorney General | For-profit businesses doing business in California that cross any one of three thresholds the Attorney General publishes: annual gross revenue, the number of California residents whose personal information they buy, sell or share, or the share of revenue they derive from selling personal information. | Build the rights the Act gives consumers into the system rather than into a policy page: the right to know what is collected, “The right to delete personal information collected from them (with some exceptions)”, “The right to opt-out of the sale or sharing of their personal information”, the right to correct, and the right to limit the use of sensitive personal information. Every one of those is a workflow that has to reach the store, the CRM and the analytics stack together. |
What Sthenos does with all four is the same thing. We build to them, we scope which of them your store is actually inside before design starts, and we produce the artefacts a reviewer asks for. We do not hold PCI DSS, ISO or SOC 2 attestations and we do not describe ourselves as certified against any of them, because that is a statement about an auditor’s opinion and we would have to be able to hand you the report.
The systems a store has to talk to
A commerce build rarely fails inside the storefront. It fails on the seams between the storefront and the systems around it, which is where the cost and the risk sit. These are the surfaces that turn up, and what each one is actually for.
ERP
Finance and operations: the master record for products, stock, pricing, invoices and the general ledger. When the store and the ERP disagree about what a product costs, the ERP is the record that wins and the customer has already checked out.
OMS, order management
The layer that decides which location or supplier fills an order, splits and re-routes it, and holds the truth about status once payment succeeds. Without one, the store becomes the order system by accident.
WMS, warehouse management
Bins, picking, packing and despatch inside the building. This is where promised delivery dates either become true or stop being true.
PIM, product information management
One place where descriptions, attributes, media and translations live, so a change reaches the store, the marketplace listings and the print catalogue at once instead of three times.
Payment gateway
The route to the acquirer, and the boundary that decides your PCI scope. Tokenisation, refunds, chargeback handling and stored-card management all live on this seam.
Tax engine
Rates and rules for the jurisdictions you sell into, applied at the moment of quoting rather than after the order. US destination-based sales tax and EU VAT are different problems and both are worse when they are calculated in the storefront.
Marketplaces and channels
Listings, inventory and order feeds moving to and from third-party channels. Every channel wants its own catalogue shape, which is the argument for a PIM.
CRM and support
Customer identity, history and consent, shared with the store rather than copied from it, so a deletion or an opt-out is honoured in both places.
Figure 1. An order, from the storefront to the warehouse
Every box on this diagram is a system named in the section above, described in that section’s own words. It shows no volume, no timing, no vendor and no price. The dashed box is the payment gateway, which the section calls the boundary that decides your PCI scope.
What to ask any ecommerce development company
- Which platform do you recommend, and when would you recommend against it? An agency that recommends the same platform every time is telling you about their bench, not your business.
- Who owns the apps and integrations? Accounts and licences should be yours.
- Show me a migration you did, with the redirect map. This single artefact separates the careful from the confident.
- What happens on the busiest day of the year? Load testing before peak, not after it.
- Who is on call during a checkout outage? Agree it before you need it.
- Which PCI self-assessment questionnaire will this design put us in? If the answer does not name SAQ A, SAQ A-EP or SAQ D, the person answering has not thought about where card data goes.
- How will you test the checkout for accessibility, and against what? WCAG 2.2 Level AA is the usual answer. A vendor who names no standard is telling you they will not test.
- Where will customer data live, and how does a deletion request actually run? A privacy answer that exists only on a policy page is not an answer. Ask to see the path through the store, the CRM and the analytics stack.
What we build for retail and commerce
Commerce work rarely stays inside the storefront, so these are the services on this site that a retail or commerce programme actually draws on. Every one of them is a page you can read before you talk to us.
- Ecommerce solutions and Magento development, for the storefront itself, whether it is a platform build, a headless front end or a Magento estate that has grown past its original design.
- Custom software development, for the parts of a commerce business that no platform models: contract pricing, approval chains, fulfilment logic, anything a merchandiser currently keeps in a spreadsheet.
- CRM and ERP work, because order, inventory and customer data reconciling across the store, the finance system and the sales system is where the operational saving actually comes from.
- Data engineering and analytics, for the warehouse and reporting layer that lets merchandising, finance and marketing stop arguing about which revenue number is real.
- AI and machine learning, applied inside the commerce workflow rather than beside it: search and recommendation, catalogue enrichment, support triage.
- Cloud consulting and migration, for the hosting, scaling and cost work that decides what the busiest trading day of the year looks like.
- Cybersecurity and penetration testing, for the checkout, the admin panel and the integrations, which is where a store is actually attacked.
- Managed IT services and help desk, for the operational layer after launch, and staff augmentation where your own team is delivering and simply needs more hands or a skill it does not have in house.
Published commerce case studies
Two of the case studies published on this site are commerce builds, served together with our delivery partner NeoSOFT. They are picked out here because they speak to what this page describes: catalogue work, payment routes and integration.
- Customized E-Commerce Platform Built for a Trend-Focused Clothing and Accessories Brand. In the case study’s own words, it was about “Enhancing visual appeal, inventory accuracy, and payment flexibility through deep platform customization”.
- Smart Commerce Platform Built for a Leading German Company in Advanced Cleaning Solutions. Its own summary line reads “Enhancing digital shopping experiences for cleaning devices through intelligent analytics and offline-first design”.
Frequently asked questions
How much does ecommerce development cost?
Catalogue complexity, the number of systems the store has to reconcile with, B2B requirements and the migration move the number far more than design does. Our hourly rates are published in the rates block at the foot of every page on this site, and we give a costed roadmap before any build starts.
Should we use Shopify or build custom?
Use a hosted platform until a specific, named requirement makes it impossible. Wanting flexibility later is not that requirement. Build custom when pricing, B2B contracts or fulfilment are genuinely unusual, and accept that you then inherit PCI scope, fraud, tax and uptime permanently.
Can you migrate our store without losing SEO?
Yes, and the redirect map is the part that decides it. Every old URL needs a mapped destination before launch, retired products included, permanent redirects rather than temporary ones, structured data carried across, and rankings and Core Web Vitals benchmarked before cutover so a regression is provable.
Do you integrate ecommerce with ERP and CRM?
Yes. The operational saving in a commerce integration comes from order, inventory and customer data moving between the store, the finance system and the sales system without being re-keyed. We quote integration and data migration as separate lines so you can see what is driving the total.
Which PCI self-assessment questionnaire applies to an online store?
It depends on where card data goes. The PCI Security Standards Council puts a fully outsourced payment page under SAQ A, a site that shapes the payment page without receiving account data under SAQ A-EP, and a store that accepts cardholder data on its own website under SAQ D for Merchants. Your acquirer decides how you validate.
Does an online store have to be accessible?
The Department of Justice says Title III of the ADA prohibits discrimination by businesses open to the public, and that covered entities must ensure the goods and services they provide to the public, including online, are accessible to people with disabilities. The technical standard the Department points to is WCAG, published by the W3C.
Do GDPR and CCPA apply to a US online store?
They can. GDPR Article 3 reaches a controller outside the EU where the processing relates to offering goods or services to people in the Union, so shipping to the EU brings you inside it. CCPA applies to for-profit businesses doing business in California that cross any one of three thresholds the Attorney General publishes.
Who owns the store after launch?
You do, entirely, from the first commit. The repository and the cloud accounts are in your name, with no licence back to us and no dependency on us continuing to exist. The platform accounts, app subscriptions and integration credentials should be yours on the same principle.
More on ecommerce and retail
Services: Ecommerce solutions, Magento development, Custom software development, ERP, CRM, Penetration testing, Managed IT services.
Standards, at their issuers: PCI DSS from the PCI Security Standards Council, WCAG 2.2 from the W3C, ADA web guidance from the US Department of Justice, Regulation (EU) 2016/679 on EUR-Lex, and CCPA from the California Attorney General.
Ours, on the same subject: Ecommerce and retail industry page, what a redesign costs, the clothing and accessories platform, the smart commerce platform, and talk to our engineers.
Ecommerce development with Sthenos
We build and replatform ecommerce systems for organisations across Maryland and the Washington DC region, delivered through an established engineering partnership with NeoSOFT. We will tell you when a hosted platform is the right answer even though it is the smaller engagement, because inheriting PCI scope and fraud handling for no reason is not a favour. To scope a build, a replatform or a set of integrations, talk to our engineers. Related: our ecommerce practice and what a redesign costs.