E-commerce development for catalogues, orders and the systems behind the shop.
We build and integrate the systems an online business runs on: the product catalogue, the order and fulfilment flow, and the connections into the ERP, payment provider and warehouse that all have to agree about price and stock.
Most of this work starts on a store that already sells. We are a custom development and integration partner, not a platform reseller, so the honest answer is often that your platform is fine and two of your integrations are not.
- 120+Projects delivered across 12 countries since 2012
- 100+Senior in-house engineers, six countries
- 2 to 4 weeksTypical time from signature to start
- ISTQBCertified QA inside every sprint
- ISO 27001Certified security practice, audited by Quay Audit UK
01Overview
What e-commerce development covers, and what an e-commerce platform actually is
E-commerce development is the building and integration of the systems an online business runs on: the storefront and product catalogue behind it, the order and fulfilment flow, and the connections into the ERP, payment provider and warehouse that must agree about price and stock. A platform (Shopify, WooCommerce, Adobe Commerce) covers the standard shape of that, and custom work starts where it stops. Published examples: JewelCandle's catalogue and ERP integration, Bigfood Group's EDI order collection, and the storefront side at e-commerce website design.
- Take the orderEvery route an order can arrive by, and the last screen a shopper judges you on.
- Storefront and channels
- Basket and checkout
- B2B and EDI order capture
- Know the catalogueOne product record every channel reads, rather than three that slowly disagree.
- Product information
- Stock and pricing
- Catalogue at volume
- Fulfil and settleThe unglamorous half, and where an otherwise good store loses money quietly.
- Warehouse and 3PL
- Payments and refunds
- ERP and accounting
- Run it after launchA shop is not a project that ends. It is a system with a peak season.
- Monitoring and support
- Peak-season readiness
- Module-by-module change
02Architecture
Headless, custom, or the platform you already run: how to tell which one you need
The decision that governs an e-commerce budget is not which agency, it is which architecture, and the test for it is short. Each row below is a situation we are genuinely brought in on, what it costs while it lasts, and the route that fits it. The first one ends in advice to change nothing about your platform.
| Where you are | What it costs you | The route that fits |
|---|---|---|
| “One shop, a normal catalogue, and it works.” | Nothing, and going headless would | Stay on the platform. If you cannot name the thing it stops you doing, headless buys you a second system to maintain and a slower first release.Storefront design on the platform you haveOr book a meeting |
| “The same catalogue has to feed a shop, an app and a marketplace.” | Three copies of the truth, and they drift | Headless earns its cost here. One catalogue and one pricing service behind several fronts, each front free to change on its own schedule.Platform development and integrationOr book a meeting |
| “Our pricing, bundles or configurator break the data model.” | An extension per rule, and a fight on every upgrade | Build the part that does not fit: a custom storefront, or a pricing and configuration service beside the platform you keep running.How we build custom systemsOr book a meeting |
| “The shop is fine. Stock, prices and orders disagree.” | Oversells, re-keying, refunds and apologies | Leave the storefront alone. The work is the middleware between the shop, the ERP and the warehouse, so one number means one thing everywhere it appears.How we did this for JewelCandleOr book a meeting |
| “Orders arrive as files and email, and someone re-keys them.” | A person standing between your buyer and your ERP | An order-collection layer, over EDI where your buyers already send that way, taking the order off the channel and handing it to the system of record.What the Bigfood EDI tool doesOr book a meeting |
03Solutions
What we build behind the shop front
Six kinds of work, drawn from what we have actually delivered in commerce. Each names the situation it is right for, because most of them are wrong for most businesses.
Catalogue and product information
One product record every channel reads: attributes, variants, media, translations, and the rules deciding which market sees what. JewelCandle runs theirs on an AWS product information system we built.
- Right when
- The same product means three things
Order flow and fulfilment
Taking orders off every channel you sell through, routing them to the warehouse or the 3PL, and getting status back out to the buyer without anyone opening a spreadsheet.
- Right when
- Orders arrive faster than you route them
ERP and system-of-record integration
The middleware between the shop and the systems that already hold your truth: products, stock, prices, orders, logistics partners, and the accounting ledger behind them.
- Right when
- The shop and the ERP disagree
Payments, refunds and reconciliation
Provider integration, the strong-customer-authentication and 3-D Secure flow, and the part everyone forgets: failed payments, partial refunds, and matching settlements back to orders.
- Right when
- Payments succeed and reconciliation does not
B2B ordering, EDI and account pricing
Account-specific price lists, credit terms, approval steps, and order collection over EDI or file drops, because a business buyer rarely arrives through a basket.
- Right when
- Your buyers are businesses, not shoppers
Running it after launch
Support, monitoring, peak-season readiness, and modernization module by module, so changing one part of the commerce stack does not stop the rest of it selling.
- Right when
- Peak season is the test you cannot fail
04Stack
What we build commerce systems with
The stack behind our published commerce work, plus the platforms and the ERP we integrate rather than resell. Running something not on this list? Send your integration list with the enquiry and we will tell you what is realistic before you commit to anything.
Angular
React
Flutter
Laravel
PHP
Yii2
Node JS
ASP.NET
C#
MySQL
AWS
Shopify
WordPress05Obligations
The obligations a catalogue and an order flow pick up
A commerce system inherits obligations the day money moves, and most of them land in the data model rather than on a policy page. Six below, each with what it constrains in a build. Then what unicrew brings to the same list.
Payment authentication and 3-D Secure
Strong customer authentication under PSD2 means some orders get challenged and some qualify for an exemption. Which ones, and what happens when a challenge fails, is checkout logic.
- In a build
- Failure paths designed, not discovered
VAT, OSS and selling across borders
Sell into several EU countries and the rate depends on where the buyer is, which threshold you have crossed, and whether you file through the One Stop Shop.
- In a build
- A tax decision inside the order model
Consumer law, returns and cancellation
Distance selling in the EU and the UK gives a consumer a cooling-off period, and a return is not an email. It is stock coming back, a refund, and a settlement line that has to match.
- In a build
- Returns are a workflow, not an inbox
Product safety information on a listing
The EU General Product Safety Regulation wants safety and responsible-person information beside the product itself, which makes it catalogue data rather than a PDF somebody maintains apart from it.
- In a build
- A field on the product, not an attachment
Personal data under GDPR
A store accumulates it without anyone deciding to: addresses, order histories, support threads, marketing consent, and the analytics identifiers stitched to all of them.
- In a build
- Retention and erasure, designed in
One audit trail per order
Every price, discount, stock movement and status change has to be reconstructable months later, for a tax authority, a chargeback, or a customer who says the site showed a different price.
- In a build
- Event history, costly to retrofit
What we bring to the same list
unicrew holds ISO 27001:2022 and ISO 9001:2015, both renewed through a multi-stage audit with Quay Audit UK, which is usually what a retailer's security questionnaire is reaching for. Delivery runs with ISTQB-certified QA engineers inside the sprint rather than a test pass bolted on at the end. Contracts and NDAs are signed before anyone starts, and we work from least-privilege access agreed with your technical contact, read-only wherever the work allows.
Headless gets recommended far more often than it is needed. It genuinely helps when you sell through several fronts, or when your catalogue logic is stranger than a platform's data model allows. Otherwise it buys you a second system to maintain and a slower first release. If you cannot name the thing the platform stops you doing, stay on it.
Yaroslav HavrylivSenior Engineering Manager, unicrew06Proof
What e-commerce clients have put their name to
Two verified Clutch reviews from commerce clients, and three published projects. Every figure below is either the metric published on the work itself or the client's own words, quoted exactly.
- A catalogue and an ERP that had to agreeWe moved JewelCandle's shops onto Shopify and built the middleware to a Microsoft Dynamics ERP and an AWS product information system. Their Head of IT describes it in his Clutch review of work under our former Artelogic brand: "We also developed a component that connects products to the appropriate sales channels, takes orders from channels, connects them to the ERP, and manages logistics."10,000-plusproducts, seven EU countries, one order flow
- A B2B order tool that earns on its ownBigfood Group, a German group of food companies, has us build and run the EDI tool that collects their customers' orders. Their Senior Digital Manager writes in his Clutch review: "The EDI tool generates significant daily revenue and helps us solve order collection issues." On the timeline: "We started working together in September 2016 and the partnership is ongoing."2016the year this client started with us
- Product data at the volume a catalogue reachesA software company in Munich filled its product databases by having two operators type datasheets in by hand, about 5,000 datasets a month. We built a recognition tool in C# on AWS that reads the documents, sorts the data and hands it to an operator to release or correct, roughly doubling throughput. The same shape fits supplier catalogues arriving in whatever format they send.2xdata-entry throughput, published on the study
07Client voices
What retail and B2B commerce clients say
Artelogic anticipates our needs and meets them before we even identify them. My team lead wants to keep both of Artelogic’s developers on the project until the product’s release. We have a backlog of 40 big projects, so I only see Artelogic’s involvement increasing.
We occasionally disagreed about the code and process. Artelogic was self-critical during these exchanges and didn’t charge us for the time. In the end, the team’s quality deliverables have created value for cost. The EDI tool generates significant daily revenue and helps us solve order collection issues.
08Case studies
Catalogues, orders and integrations we have built
Three published builds, three different parts of the same problem: a manufacturer whose seven markets and one ERP had to agree, a food group whose orders arrive over EDI, and a product database people were typing in by hand.
See all case studies
eCommerceEcommerce software development for JewelCandleJewelCandle, a mid-size European manufacturer of scented products, sells across seven EU countries (B2B and B2C) via online shops.10,000-plusProducts manufactured
FoodtechDigital Transformation in Food IndustryOur client is an innovation-oriented group of food companies based in Germany that produces and distributes a wide range of products for well-known retail businesses and food services.- AutomationDoubling data-entry throughput with a custom recognition toolunicrew automated a manual data-entry bottleneck with a C# and AWS recognition tool, doubling the data sets the team got through each month.2xData sets processed per month
09Questions
E-commerce development: frequently asked questions
An e-commerce platform packages the storefront, catalogue, basket, checkout and admin into one product. We meet Shopify, WooCommerce and Adobe Commerce most often, and for most businesses the platform should stay. You have outgrown it only when you can name what it stops you doing: a pricing or bundling rule its data model will not hold, a catalogue larger than it serves well, or a second and third channel needing the same product data.
Usually not. Headless separates the storefront from the commerce back end, so several fronts share one catalogue and one pricing service. It earns its cost when you sell through a shop, an app and a marketplace at once, or when your catalogue logic is stranger than a platform's data model allows. With one storefront and an ordinary catalogue it mostly buys a second system to maintain and a slower first release.
Yes, and it is usually the larger half of the work. For JewelCandle we built the middleware between Shopify storefronts, a Microsoft Dynamics ERP and an AWS product information system, including the component that takes orders off each sales channel and hands them to logistics. For Bigfood Group the same shape runs over EDI. Where a system exposes no usable API, the access layer is the first thing we build. More on platform development and integration.
Yes, and they are different builds. A B2B order carries account-specific price lists, credit terms and approval steps, and often arrives over EDI or as a file, not through a basket. Bigfood Group runs an EDI tool we built that collects their customers' orders; their Senior Digital Manager writes in his verified Clutch review: "The EDI tool generates significant daily revenue and helps us solve order collection issues." JewelCandle sells B2B and B2C off one catalogue across seven EU countries.
Three engagement models: time and materials billed hourly and quoted per project, fixed price quoted per project against an agreed outcome, and team extension billed monthly per team member. Which fits depends on how firm the scope is; we recommend one at the end of discovery. We do not publish a project price band: one ERP integration and a full rebuild are not the same job. Fixed-scope work carries a post-launch warranty, length agreed in the contract; team extension has no recruitment or placement fee.
Most engagements start within two to four weeks of signature. Duration is usually set by your trading calendar rather than the engineering: nobody wants a cutover landing in peak season, so releases are sequenced around it. The first slice is normally one integration or one flow, built against your real catalogue on your own staging and running before the rest of the scope is committed. A replatforming moves shop by shop, or market by market, so the store keeps selling.
Most of our commerce clients stay: Bigfood Group since September 2016, JewelCandle since January 2020, both ongoing in their reviews. Staying on is team extension billed monthly per team member; otherwise the handover is the deliverable. On data: contracts and NDAs first, access least-privilege and read-only wherever the work allows. unicrew holds ISO 27001:2022 and ISO 9001:2015, renewed through a multi-stage audit with Quay Audit UK. We do not hold SOC 2, and we say so up front.
Tell us what breaks between the shop and the systems behind it
A call with a senior engineer who has shipped catalogue, order and ERP integration work, not a sales qualifier. You leave with an opinion on architecture, scope and sequence, and the reasoning behind it.
What happens after you contact us
- We reply within one business dayA senior engineer reads your message, not a bot.
- A call about the systemsWhat you sell through, what holds the catalogue, and where the two stop agreeing.
- Route and engagement model, in writingKeep, integrate or build, priced as time and materials, fixed price, or team extension.
- NDA, then discoveryMost engagements start within two to four weeks of signature.