Custom Ecommerce Development Services: A Buyer’s Guide

You're three weeks from a vendor shortlist, the catalogue export is still a spreadsheet, and finance hasn't named which system owns price. That call will waste an hour if the brief is a feature wishlist.

Online selling is now ordinary operating work, not a side channel. Eurostat reports that the share of EU enterprises conducting ecommerce sales rose from 18.93% in 2014 to 23.59% in 2024, while the share of enterprise turnover from ecommerce rose from 16.43% to 19.49%. A build has to carry that load across channels, not just launch a theme.

This is how I would prepare, shortlist, and contract custom ecommerce development services. If you want an ecommerce software development partner that treats the store as software, start with scope, not a demo.

How to Scope Requirements Before You Talk to Vendors

In the United States, the Census Bureau estimated adjusted retail ecommerce sales at $1.2337 trillion for 2025, a 5.4% increase from 2024, with ecommerce at 16.4% of all U.S. retail sales. The Bureau counts a sale when the buyer places an order, or negotiates price and terms, through the internet, a mobile device, an extranet, EDI, email, or a comparable system. Payment doesn't have to happen online. Your brief has to cover that whole path.

Finish this before any vendor call.

1. Name the outcome in numbers: Orders per month, B2B revenue share, or a checkout conversion target. A vendor can't trade scope against a slogan.

2. List every channel, market, and currency: The website, a sales-rep portal, a marketplace, and a subscription renewal are different order types.

3. Map the systems of record: ERP, CRM, order management, product information, tax, payments, and fulfilment. One owner per record.

4. Classify the data: Card data, personal data, health or policy information, and seller records. Classification decides who may see a field.

5. Estimate volume, including peak multiples: A Tuesday average hides a sale weekend. State the multiple you expect operations to survive.

6. Write acceptance criteria: It should be for checkout and each integration. "Syncs with the ERP" isn't a test. "Price and stock match the ERP within five minutes of a change" is.

Before you freeze hosting assumptions, check UI Lib hosting prerequisites so environment limits surface during planning, not in week six.

Requirements that change by business case

The same sentence, "we need a store," means five different builds.

Practical rule: Close the pack as one page: outcome, channels, systems, data classes, peak volume, and acceptance tests. If a vendor can't question that brief, they haven't read it.

Platform Choice by Catalogue, Integrations and Team

Platform choice matters less than fit against catalogue complexity, integration count, and the skills you already have. I would shortlist two, not five, then reject anything that only looks good in a scripted demo.

Who each platform actually suits

Shopify is the right hosted SaaS bet when you need a store live quickly, and the catalogue is straightforward. Checkout customisation is the constraint. If your price rules won't fit the platform, apps won't fix that cleanly.

Magento (Adobe Commerce) earns its cost on large catalogues and contract pricing. You pay in hosting and in upgrade discipline. Read how to choose a Magento development company before you treat "we know Magento" as proof.

WooCommerce suits content-led catalogues and teams already running WordPress. It gets expensive in a different way. Plugin sprawl slows the site and makes upgrades fragile.

Litium fits enterprise teams that want commerce, content, and personalisation in one commercial platform. Expect fewer ready-made extensions, so budget for connectors instead of an app store.

nopCommerce gives .NET teams source-level control. They also carry patching and security ownership that a hosted SaaS vendor would absorb.

We develop custom ecommerce solutions with ERP connectivity for B2B and B2C. If you plan a headless front end, budget web application development as its own workstream, with its own acceptance tests.

Pick two finalists, then run one real integration scenario on each. A polished storefront demo doesn't prove that contract prices survive a round trip to your ERP.

Integration Patterns for ERP, CRM and Payment Systems

Integration decides whether the platform survives its first peak. Checkout that looks finished and can't recover a failed payment is a visual feature, not a transaction workflow.

Baymard reports that 17% of US online shoppers have abandoned an order because checkout was too long or complicated, and its research finds an average of 32 potential checkout improvements per large ecommerce site. Unexpected extra costs are a major abandonment cause in that same body of work. Totals that appear late are an integration failure as much as a design failure.

Four patterns, and where each breaks

• Point-to-point API connectors: Fine for one ERP and modest volume. Each new system multiplies mappings, and nobody owns the whole chain.

• Middleware or an iPaaS hub: Mapping and monitoring sit in one place. You now run and license another platform.

• Event-driven messaging: Fits high volume and asynchronous fulfilment. Handlers must be idempotent and support replay, or a retry becomes a second order.

• Scheduled batch sync: Fits a legacy ERP that posts overnight. Stock goes stale between runs, and that gap is where overselling starts.

Choose the pattern before anyone writes a connector. Scope ERP and CRM integration with a team that has done the unglamorous parts. We've built an API connector from Magento to Exact Online starting from zero, a Magento batch-code tracking module, and secure migration into the customer's ERP and CRM ecosystem. As we explored in our guide to automotive ecommerce software integration, the hard part is keeping order state consistent when several systems move at different speeds.

Failure handling before the first connector

Design the unhappy path first.

• Authoritative totals: Calculate shipping, tax, discounts, inventory, and final price on the server before payment. The browser must not be allowed to set the order value.

• Separate paths: Guest checkout and account creation stay distinct, and the cart survives login, payment redirects, retries, and a dropped connection.

• Idempotent payments: A retry can't create a second order. Reconcile payment-provider webhooks with order and fulfilment states.

• Correlation IDs: Log validation failures, authorisation responses, and recovery outcomes so one order can be traced across systems. Don't store prohibited card data.

For a plain explanation of how gateways sit in that sequence, payment flows for SaaS and ecommerce is a useful companion to your own sequence diagram. Reducing those failure points is also a design job, which is why our streamlined checkout UX notes belong in the same review as the integration contracts, alongside UI/UX design services rather than after launch.

Engagement Models and How Vendors Price Them

Settle the model before you compare prices. The model decides who carries scope risk. A cheap bid on the wrong model isn't cheap.

What each model is actually for

Full-Cycle Delivery is for teams that want to hand the product journey to a cross-functional group. We take ownership from discovery through delivery. It works when acceptance criteria are written. Vague criteria become change requests.

Corporate Business Solutions is co-creation. Our developers, architects, and delivery leads work beside your product owners and developers, including agile coaches and AI specialists when the roadmap needs them. It fits acceleration, team scaling, legacy modernisation, and agile transformation. It fails when nobody names a counterpart or shares one backlog. Our software development service models spell out how those working arrangements differ.

Team augmentation adds engineers under your direction. Use it for a named gap, such as Magento or integration work. Output quality tracks your review capacity. If your leads can't review pull requests, extra hands don't help.

Prices you can actually compare

Match the commercial shape to how well the scope is known.

• Fixed scope when the brief, integrations, and acceptance tests are stable.

• Time and materials when discovery will change the design.

• A dedicated monthly team when the roadmap runs longer than one release.

A comparable contract also names code and repository ownership, acceptance criteria, change-request handling, incident response times, a data processing agreement, security testing, and an exit and handover plan. A price without those clauses isn't comparable with another price.

Price drivers worth weighting before you request bids are integration count, the share of custom versus configured features, catalogue size, compliance scope, and support hours. Don't benchmark vendors against published day rates unless the source and the scope of that rate are documented.

Compliance and Security Obligations That Shape the Build

Treating compliance as a launch checklist is how payment pages ship with scripts nobody authorised. These duties change the data model and the release process, so they belong in the first sprint.

Payment pages and script control

PCI DSS v4.x is explicit about the browser, not only the server. The PCI Security Standards Council describes requirement 6.4.3 as authorising and managing scripts on payment pages, including an inventory and protection against unauthorised modification. Requirement 11.6.1 requires a mechanism to detect unauthorised changes to payment-page content and security-impacting HTTP headers, with checks at least every seven days. The Council frames both as a response to e-skimming, where malicious JavaScript captures payment data in the customer's browser.

Tokenisation from the payment provider reduces card-data exposure. It doesn't remove the need to control scripts on the rendered page. Put the script inventory, tag governance, content-security rules, integrity monitoring, deployment approvals, and incident alerts into the release path. As we explored in our PCI DSS compliance checklist, these controls fail when a marketing tag is added outside the change process.

Marketplaces, access, and checkout reach

For EU online marketplaces, the European Commission requires marketplaces to counter illegal products, offer notice-and-action and complaint mechanisms, work with trusted flaggers, follow advertising-transparency rules, and prohibit dark patterns. The interface must let sellers submit required pre-contractual and product-safety information. A separate European Parliament briefing describes the Commission's know-your-trader duty: verify business sellers, display their contact details, and make reasonable efforts at random product checks or traceability technology. Seller identity, product ownership, sampling, takedown, and evidence retention belong in seller, catalogue, and order services. A manual back office after launch won't keep up.

Accessibility is the same class of requirement. A 2025 audit of leading European and global ecommerce sites found that 94% had inaccessible checkout flows, with average scores of 4.3/10 for cart, 4.4/10 for delivery, and 5.1/10 for payment. The most common failure was WCAG 4.1.2, Name, Role, Value. The European Accessibility Act is part of why this can't wait for a one-time audit. Test keyboard and screen-reader paths on every release.

For a healthtech-adjacent or insurance storefront, confirm with counsel whether health or policy data enters the commerce stack. That answer sets the controls. We implement encryption, access controls, and regular security audits on ERP and CRM work, and those obligations should be in the contract, not a later change request.

A Sample Onboarding Timeline for a First Release

Treat the calendar below as a planning example, not a benchmark. A first release with catalogue, checkout, and two integrations typically runs 14 to 16 weeks, depending on integration count and how fast stakeholders approve.

Before week one, name a product owner and a technical lead. Open sandboxes for the ERP, the CRM, and payment test accounts. Export the catalogue. Attach the one-page brief and a risk register. Missing sandbox access is the usual reason week three slips.

Gates that actually stop the next phase

Phases overlap on purpose. Testing starts before the last build sprint ends, because a script inventory assembled in week 14 is too late to change the payment page.

The gates stay strict. A signed brief closes discovery. A passed architecture review closes environments. Passed sprint tests close each increment. Zero open critical defects close the test window. The pilot stays on one market or a subset of SKUs, with monitoring live before traffic rises.

Add about two weeks when a payment provider requires certification, or when the ERP team only ships inside fixed release windows. Those waits aren’t development time, and pretending they are is how the plan misses.

Track Key KPIs and Start With a Discovery Sprint

Measure the platform and the vendor on one dashboard. A launch that lifts completed orders can still raise support load, duplicate charges, or slow checkouts.

Review these monthly for the first year.

• Step-level checkout abandonment, not a single site-wide rate.

• Payment authorisation rate and duplicate-order rate.

• Checkout latency and recovery rate after a payment failure.

• Support contacts per thousand orders, plus release frequency.

Add a maintenance line to the budget. We provide support and maintenance for ERP and CRM systems, including fixes and necessary updates, and those response times should be written into the ecommerce service-level agreement so two vendors can be compared.

A vendor who will only discuss completed orders is hiding the failures that cost you margin.

Then move in a fixed order.

1. Shortlist three vendors that have shipped on your chosen platform, and read their ecommerce client cases for integration work, not only storefront screenshots.

2. Send the requirements brief and the integration map. Ask them to mark what they would challenge.

3. Require written answers on code ownership, security testing, and handover.

4. Run a paid discovery sprint of two to four weeks with the top choice. The outputs are a costed backlog and a working integration prototype.

If a vendor resists a paid discovery, treat that resistance as information about how the engagement will feel later.

Bridge Global designs and builds custom ecommerce platforms for B2B and B2C, including ERP connectivity, checkout, and the security controls those systems need. If your next release depends on integrations and a contract you can enforce, talk with Bridge Global about a discovery sprint against your brief.

Frequently Asked Questions

When is a custom build worth it over a hosted theme?

Choose custom work when contract pricing, multi-system stock, marketplace seller rules, or a checkout the platform won’t allow are already blocking revenue. A hosted theme is still the better start for a small catalogue and a standard checkout. Custom ecommerce development services pay off when you’re working around the platform more than with it.

What should a vendor prove before we sign?

Ask for a written response to your brief, one integration scenario on your platform, and named owners for code, security testing, and handover. A demo store isn’t evidence. A prototype that reads price or stock from your ERP is.

How should we compare fixed and time-and-materials bids?

Compare them only after the engagement model, acceptance tests, and change process are the same on both proposals. Fixed scope fits a stable brief. Time and materials fit work that discovery will still reshape. A lower number with no exit plan isn’t the cheaper contract.

What usually breaks at the first sales peak?

Stale stock from batch syncs, payment retries that create duplicate orders, and totals calculated in the browser. Idempotent payments, server-side totals, and a correlation ID across ERP, tax, and the payment provider are the controls that keep a peak from becoming a support incident.

Do PCI script rules apply if we use a payment provider?

Yes, when scripts run on your payment pages. Tokenisation cuts card-data exposure, and it doesn’t replace a script inventory, change detection at least every seven days, or deployment approval for tags. Marketing pixels added outside that process are a common gap.

What should a discovery sprint deliver?

A costed backlog and a working slice of one real integration, plus a clear statement of what is out of scope. Two to four weeks is enough to expose sandbox, data, and approval problems. If the vendor won’t do that work on a paid basis, expect the same avoidance after kickoff.