Request a discovery call
  1. Home
  2. What we build
  3. Digital Experience
  4. E-commerce and marketplaces

Digital Experience

E-commerce andmarketplaces.

E-commerce and marketplace work is the system a business sells through: the catalogue, the storefront, the account price, the checkout, and what happens after the order.

Anyone buys at the list price. Your accounts buy at theirs. Both go through one checkout that knows which province or state it is selling into.

Request a discovery call Start with an audit

Soundslike this?

  1. Our trade accounts still email their orders, and somebody keys them in.

  2. The website shows stock we do not have.

  3. Two customers pay two different prices, and the site knows about neither.

  4. Most of the orders we take on the phone are the same six things, again.

  5. People fill the basket and leave at the last screen, and nobody can say why.

  6. Revenue is up and nobody can tell me which products made money after shipping and returns.

  7. We sell on a marketplace that owns the customer relationship, not us.

If what you recognise is a customer phoning about an order that already exists rather than an order they want to place, that is a portal before it is a store, and Web Applications and Portals is the page for it.

What this is, in plain language.

What happens today

An account phones on Tuesday to reorder the same six items. Somebody finds the agreed price in a spreadsheet, checks whether the stock is really there, types the order into the system, and confirms it by email. Fifteen minutes, and none of it was a decision.

Online, a different customer reaches the last screen of the checkout and leaves. Nobody finds out why. At the end of the month revenue is a number and profit is a guess, because shipping, discounts and returns live in three places.

None of that means the platform is wrong. It usually means the engine is doing its job and the storefront was never asked to do its own.

What happens after

The account signs in and sees the price you agreed with them, their own order history, and a reorder that takes four taps on a phone in a truck. The stock number on the page is the stock number in the warehouse, because one system is the truth about it and everything else reads from that one.

The other customer reaches a checkout designed to be finished.

The total, the tax for their province or state, the delivery expectation and the returns terms are all visible before they commit, and the payment methods are the ones their customers actually use. At the end of the month, profit after shipping, discounts and returns is a report rather than an argument.

The engine handles the money. The storefront does the selling.

They arrive bundled together and they are not the same product. The engine is the part that has to be right and boring: payments, tax, inventory, orders, refunds. It is solved, it is maintained by somebody else, and rebuilding it is almost never the job.

The storefront is the part that decides whether anybody buys, and it is the part that ships generic. Most commerce projects that disappoint were strong on the first and default on the second, which is why our usual recommendation is to keep the engine you have and rebuild the thing in front of it.

The phone is the product, not a version of it. Most of the traffic and most of the hesitation happen there, so the phone experience is designed first and measured hardest, on a mid-range device on a cellular connection rather than on a new phone on office wifi.

Who this is for, and who it is not for.

Where this pays for itself

  • Direct to consumer brands with real repeat purchase behaviour, where the second order is the one that makes the arithmetic work.
  • Manufacturers and distributors whose accounts reorder on negotiated pricing, and whose inside sales team spends its day typing those orders in.
  • Retailers with stores and stock, where the website and the shelf have to agree or the promise breaks.
  • Businesses selling into Canada and the United States, where tax, duty, shipping and delivery expectations differ by destination.
  • Products that need explaining before they can be bought, which is where a default storefront loses most reliably.
  • Recurring models: dues, plans, renewals, cohorts, member content, maintenance agreements.
  • Two sided businesses: buyers and providers, owners and renters, clients and professionals, where the platform itself is the product.

You probably do not need this if

  • The catalogue is under roughly twenty items, there is one price, and nobody signs in. A hosted platform with a good theme does that well.
  • Nothing recurs and nothing repeats. Where a customer buys once every four years, the money belongs in the site that wins the enquiry, not in the checkout.
  • The margin does not carry the shipping. Some products cannot be sold profitably online at any conversion rate. The arithmetic says so before the build does, we will run it with you on the discovery call, and we will tell you what it says.
  • The platform is the complaint and no requirement sits under it. In most projects the engine stays and the storefront is rebuilt. A migration needs a thing the current engine cannot do, and if we cannot name one we will say so.
  • The marketplace has neither side yet. Most two sided platforms are built by making one side work against a manually assembled other side. Where neither exists, the first project is proving demand, and that is not a build.
  • Stock is not counted anywhere. A store makes a promise about availability. Where that number lives in a person's head or in a spreadsheet updated on Fridays, the first job is the system behind the store.

Where the honest answer is a theme and a month of merchandising, that is the answer you will get, and it is a short conversation.

What it includes.

Sixteen capabilities, what each one does in plain words, and what it changes for the business. Nothing here is a category name standing in for work.

E-commerce and marketplaces, the capability table
Capability What it does What it changes
Before the storefrontThe arithmetic and the engine decision
Commercial discovery Margin, repeat rate, average order, return rate, channels, and the thing the store has to do that it cannot do today. You find out whether the store can make money before you pay to build it.
The platform recommendation Which engine, and why, written down with its reasoning, including the case for staying exactly where you are. The engine decision becomes a document you can argue with instead of a preference you inherited.
E-commerce platforms Sub-service
The storefront Designed on the phone first and measured there hardest, around your product and the place customers hesitate. The part that decides conversion stops being the part nobody designed.
Catalogue and merchandising Categories, filters, search, recommendations and product content, authored per language where your customers need it. People find the thing they meant rather than the words they happened to type.
Checkout Built for completion, with the payment methods people in this country actually use and details that are saved for next time. Fewer people leave at the last screen.
Tax, shipping and returns GST, HST, PST and QST by province, shipping rules, duty where you sell across the border, and a returns path that is designed rather than improvised. The number at the top of the invoice is right in every province you sell into.
Inventory and pricing Connected to the ERP or inventory system that is actually the truth, in one direction, on a schedule chosen per connection. The website stops promising stock you do not have.
B2B and account pricingNo child page yet
Account pricing The price you agreed with an account, shown to that account when they sign in, and to nobody else. Your trade customers stop phoning to ask what they pay.
Quotes and reorder Reorder from history, saved lists, and quotes that become orders without being retyped. The reorder stops being a fifteen minute phone call.
Terms, purchase orders and credit Purchase order numbers, agreed terms, and a credit decision that stops at a person every time. The store sells. It does not extend credit.
Marketplaces, subscriptions and memberships Sub-service
Recurring billing Plans, trials, proration, upgrades, downgrades, cancellations and dunning. Billing survives the edge cases, which is most of what billing is.
Failed payment recovery Retries on a schedule you set, what the member sees, when access pauses, and how it is restored. Usually the largest single revenue lever in a subscription business.
Two sides, matching and payouts Onboarding and verification per side, listings, availability, commissions, statements and payouts. Both sides are a product, rather than one side and a form for the other.
Entitlements and self-service Who can see what, what happens the day a subscription lapses, and a member account that handles the routine work. Routine account work stops arriving as email.
What every build carriesWhatever else is in the scope
Reporting after costs Profit after shipping, discounts and returns, by product and by campaign, with the definitions written down. You find out which products actually make money, not just which ones sell.
Migration Products, customers, orders and URLs moved, with a redirect map and the order history intact. You keep the rankings and the history you already had.

Scroll the table sideways to read it.

How it works.

One catalogue, one storefront, two prices. A trade account signs in to the price you agreed with them, and a credit is still a person's call.

Scroll the drawing sideways to read it.

The branch in the middle is a price, not a second store. That is the whole design, and getting it wrong once is enough.

What the system does

The work, the path it takes, and everything HUREAL builds. It never means anything else.

What stays with a person

The line, its single opening, and the plate standing in it. On a light board it is the one dark plate.

What you already run

Present, named, and not for sale. The lowest contrast on the board, deliberately.

  1. One place knows the price.

    Cost, stock, the list price and your account terms live in one system and everything else reads from it. Which system that is gets decided in week one and written down, because almost every unhappy commerce project is this question left unanswered.

  2. One storefront, and the branch is the price.

    Not a public site and a trade site. One store, one catalogue, one checkout, and a signed-in account sees different numbers. Two stores means two sets of product content to maintain and two places for the truth to drift.

  3. A trade account signs in to what you agreed.

    Their price, their history, their saved lists, their purchase order number. The reorder that used to be a phone call becomes four taps, and it happens at six in the morning when the person who needs it is loading a truck.

  4. One checkout, and it knows the province.

    GST, HST, PST or QST by destination, the shipping rule that applies, the total visible before anyone commits, and the payment methods people here actually use. The engine you already have does most of this well, which is precisely why we do not rebuild it.

  5. Fulfilment and returns stay where they are.

    Picked, shipped, tracked. Back on the shelf, or not. The store writes to those systems and reads from them; it does not become a second copy of them.

  6. The credit stops at you.

    A refund, a term, an exception: the drawing puts one line across the bottom and the plate standing in it is a person. That is not a limitation of the software. It is the boundary you would want on a Tuesday when somebody asks for something unusual.

  7. What sold goes back to the catalogue.

    And what did not. The loop from the bottom of the drawing back to the top is the merchandising work, and it is the reason the work continues after launch.

Before the conversation, you can have the evidence. The Website Performance Audit measures what you have against the job you want it to do. It covers the product page and the checkout on a mid-range phone, where the orders come from and what they are worth, what search engines and AI assistants can read, and what comparable companies do differently.

The document is yours either way.

Start with an audit

What you end up with.

  • The commercial picture, in writing

    Margin, repeat rate, average order, return rate and channel mix, with the arithmetic that says what the store has to do to pay for itself.

  • The engine decision, with its reasoning

    Which platform, why, and what it would have cost to be wrong. Including, where it applies, the recommendation to stay put.

  • The storefront

    Designed on the phone first, measured there hardest, running in your accounts.

  • The catalogue and the merchandising system

    Categories, filters, search and product content your team maintains without a developer.

  • The account layer

    Account pricing, saved lists, reorder, quotes and purchase order handling for the customers who buy that way.

  • The money, configured and tested

    Payments, provincial tax, shipping rules, returns, and for recurring models the plans, the proration and the dunning schedule.

  • The connection to the truth

    Inventory and pricing read from the system that owns them, on a schedule chosen per connection and documented.

  • Reporting after costs

    Profit by product and by campaign after shipping, discounts and returns, with every metric defined in writing.

  • The migration record

    Products, customers, orders and URLs moved, with the redirect map you can audit.

  • The launch record

    The fourteen published checks, run in full, with the result of each one written down.

V3. The account price, shown

your-company/store/product Signed in as a trade account

The same product, to two people

One catalogue. One page. The price is the branch.

  • List price

    What anyone sees. Shown struck through to the account, because they should be able to see what they are saving.

  • Your price

    The price you agreed with this account, with the agreement it comes from named.

  • Availability

    Read from the system that owns stock, with the date it was last true.

  • Reorder

    The last three times this account bought this item, as one tap each.

  • Purchase order

    Their reference field, because their accounts department will ask for it.

  • Terms

    Their agreed terms, shown, with a note that any change to them is a person's decision.

    A person decides
The last row is the one that matters. The store can show a price, hold a basket and take an order. It cannot decide to extend somebody credit, and on this build it is never asked to.

The store, the repository, the analytics and the merchant account are opened in your name from day one. How ownership works

Discover, design, build, launch, improve. Scope, price and timing are agreed before implementation. See the full process

What it connects to.

By category, because the category is the question. The first real objection is whether this works with what you already run, and the honest answer is a list plus a qualifier, not a wall of logos.

  • ERP and inventory

    Where cost, stock, the list price and your account terms are actually true.

    NetSuite, SAP Business One, Sage, Dynamics 365 Business Central

  • Payments

    Where the money is taken, and where the card data stops being your problem.

    Moneris, Stripe, Square, PayPal, Interac e-Transfer for account customers

  • Tax

    Where the rate for a province and a product class is decided.

    Avalara, TaxJar, the platform's own provincial tax tables

  • Shipping and fulfilment

    Where a rate is quoted, a label is printed and a parcel is tracked.

    Canada Post, Purolator, UPS, FedEx, ShipStation, a third-party warehouse's system

  • Accounting

    Where the order becomes an invoice and the refund becomes a credit note.

    QuickBooks, Sage, Xero

  • Point of sale

    Where a store sells the same stock, so the shelf and the site agree.

    the point of sale you already run in store

  • Marketing and feeds

    Where a product listing, an abandoned basket and a consent record live.

    Klaviyo, Mailchimp, Google and Meta product feeds

  • EDI with large accounts

    Where a big customer requires orders and invoices in their format, not yours.

    the exchange your largest accounts already mandate

  • Marketplaces you also sell on

    Where stock and price have to agree with a channel you do not control.

    the general and trade marketplaces you already list on

Every connection is validated by HUREAL's engineers during scoping and confirmed in writing before signature. Where a system genuinely cannot be connected, you hear it during discovery rather than during the build, and the scope is drawn around it instead of making a platform migration the price of entry.

What we do, and what we will not do.

What we do

  • Run the arithmetic firstMargin, repeat rate, average order and return rate, before anyone designs anything.
  • Keep the engine where the engine is fineThe usual scope is a new storefront on the platform you already pay for.
  • Design the phone firstBecause that is where most of the traffic and nearly all of the hesitation is.
  • Make one system the truthAbout price, about stock, about the customer. Written down, in week one.
  • Test the moneyTest transactions end to end, including a refund, before launch day rather than after the first one.
  • Report after costsProfit by product and by campaign after shipping, discounts and returns, with every metric defined.

What we will not do

  • Move you off a platform that worksThe engine handles money and inventory well, and the storefront is what decides conversion. A migration needs a requirement, not a preference, and we will show you the arithmetic before you decide.
  • Promise a conversion rateWe will run the arithmetic with your numbers and show the working. A percentage we invented is not evidence, and a percentage from somebody else's store is not yours.
  • Take pricing or credit decisions away from youAn account price is what you agreed. A credit, a term and an exception stop at a person, every time.
  • Launch a migration without the redirect mapProduct and category URLs that rank and then disappear take their traffic with them, and in commerce that traffic had a basket in it.
  • Build a two sided marketplace with neither sideWhere demand is unproven, the honest first project is proving it, and it is not a build.
  • Certify your complianceWe design to the standard, test against it, and document what we built. The determination belongs to your counsel, your privacy officer or your accountant.

A theme, a built storefront, or a built engine.

Three ways to sell online, and the middle one is what we recommend most often. That makes this the one comparison on the site where both ends of the table sometimes beat the thing we usually sell.

The three approaches, on ten deciding factors
Deciding factor A hosted platform with a bought themeSubscribed A hosted platform with a built storefrontRented engine, built front A fully custom commerce buildBuilt, engine and all
What you are buying A commerce engine and a theme somebody else designed. The same engine, with the selling surface built for your product. Everything, including the parts that are already solved.
Cost to start Lowest. Middle. Highest, usually by a lot.
Cost to keep A subscription plus apps, and both rise with volume. The same subscription, and fewer apps, because the storefront does natively what apps were patching. Hosting, plus you now maintain payments, tax and inventory logic yourself.
Payments, PCI and card data Handled by the platform. Handled by the platform. Handled by the platform if you are sensible, by you if you are not.
Provincial tax The platform's tables, configured. The platform's tables, configured, plus the product class rules that make them right. Yours to build and yours to keep current.
Speed on a mid-range phone Whatever the theme and the installed apps add up to. A budget agreed in the scope and measured before launch. Whatever you build, and yours to keep fast.
Account pricing and B2B A bolt-on if the platform has one, a workaround if not. Built: the account signs in and the price is theirs. Built, and you also rebuilt everything around it.
Connecting to your ERP A connector if one exists, a paid app if not. Built and validated during scoping, in the direction you chose. Built, along with everything else.
When the platform changes something Your theme may break and you wait for the theme author. The storefront is your custom work, so the change is a scoped fix. It does not affect you, because you also carry everything the platform was carrying.
When it is the right answer Under roughly twenty products, one price, nobody signs in, and you need to be selling next month. The catalogue, the account pricing or the product story is doing the selling, and the engine is fine. A genuinely unusual commercial model that no platform expresses, and the volume to justify carrying it.

Which one to choose

If the catalogue is small, there is one price and nobody signs in, buy the theme. It will be selling next month, the platform maintains it, and the money you did not spend is better used on product photography and a month of merchandising.

We would rather tell you that on the discovery call than build you something handsome that does not change the number.

If you are about to ask for a fully custom commerce build, we will probably talk you out of it. Payments, provincial tax, inventory and refunds are solved, boring and maintained by somebody else, and taking them on means owning a permanent maintenance obligation in exchange for flexibility you will use twice.

This one is against us in the other direction: it is the most expensive thing on the table and we are saying do not buy it. There are real exceptions, and they are commercial models no platform expresses, at a volume that pays for carrying it.

The middle column earns its cost in a specific place: the catalogue, the account pricing, or the product story is what does the selling, and the default storefront is the part that is generic.

That is most distributors, most manufacturers selling to trade, and most brands whose product needs explaining. Keep the engine, rebuild the thing in front of it, and spend the difference on the catalogue.

Designed around the markets you serve.

A store takes money, holds customer records and makes promises about price and delivery, which is more law than a website carries. We identify privacy, accessibility, data-location, and operational requirements during discovery, based on where your business operates and what the system handles.

Technical controls and documentation are agreed with your team and legal advisers where needed. For a business operating in Canada, these are the requirements that usually apply.

  • Sales taxGST, HST, PST and QST, by province of destination

    What we design forTax decided by the destination and the product class rather than by a single default rate, with the rules configured against the catalogue. The total including tax is visible before the order is placed. Registration thresholds are flagged to your accountant when the store starts selling into a new province.

    What we document for your counsel and your accountantWhich rules are configured where, which product classes were treated how, and which determinations we left open because they are not ours to make.

  • Payments and card dataWhat the payment provider carries, and what the store carries

    What we design forCard data handled by the payment provider and never stored by the store, the payment methods a Canadian buyer expects, and refunds and chargebacks designed as a path rather than discovered as an incident.

    What we document for your counselWhich provider is in the flow, what each one sees, and where the boundary sits between their obligations and yours.

  • What a buyer is told before they orderProvincial consumer protection legislation, including Quebec's

    What we design forThe total, the taxes, the shipping, the delivery expectation, the currency and the returns terms visible before the order is placed rather than after it, and a cancellation path that is findable rather than technically present.

    What we document for your counselWhere each disclosure appears in the buying path and at which step, so a review is reading a map rather than clicking through the store.

  • PrivacyPIPEDA, Quebec's Law 25, and the provincial private-sector statutes where they apply

    What we design forCustomer accounts and order history held with a stated purpose, the smallest set of fields that does the job, consent captured before marketing and analytics scripts run, retention set per record type, and the hosting and processor regions chosen in the scope rather than inherited from a default.

    What we document for your counselWhat is held, where, by which processor, who can reach it, and for how long.

  • Electronic messagesCASL, for anything the store sends that is commercial

    What we design forA clear separation between the message that confirms an order somebody placed and the message that tries to sell them something else, consent and its basis recorded against the record, no pre-ticked boxes, and an unsubscribe that works in one action.

    What we document for your counselThe consent basis per contact, the send log, and the classification we built against, so the determination is theirs to confirm rather than ours to assert.

  • AccessibilityWCAG 2.2 AA, plus AODA and the provincial equivalents

    What we design forEvery surface a customer has to use, which on this service means the product page, the basket and the checkout above all. Keyboard, screen reader, contrast and reduced motion, tested rather than asserted, including the error states in the checkout where most stores fail.

    What we document for your counselThe test results per template and the standard tested against, so a barrier report can be answered with a measurement.

  • LanguageQuebec's Charter of the French Language, where the business operates there

    What we design forProduct content, the basket, the checkout, the confirmation email and the returns policy authored per language rather than translated at the end, because these are the surfaces a customer reads while deciding whether to trust you with a card.

    What we document for your counselWhich surfaces are authored per language and which are not yet, so the gap is a list somebody owns rather than a surprise.

HUREAL designs to a standard, tests against it, and documents what was built. The determination is your counsel's or your privacy officer's to make. Our own conformance target and how to report a barrier are on the accessibility page.

Questions people actually ask.

  • Do we have to leave our current platform?

    Usually not. The engine handles money and inventory well, and the storefront is what decides conversion, so in most projects we rebuild the storefront and keep the engine. If a move really is warranted, you get the arithmetic and the reasoning in writing before you decide anything.

  • What about all the apps we have installed?

    They get inventoried. Some are doing real work and stay. Some are doing work the storefront should do natively, so it gets built in and the app is removed, which usually makes the store faster and the subscription bill smaller. You get the list with a recommendation per app, and you decide.

  • Can our trade accounts see their own prices?

    Yes, and that is the centre of the design rather than a feature on the end of it. One catalogue, one storefront, one checkout, and the price is the branch: anyone sees the list price, a signed-in account sees what you agreed with them, along with their history, their saved lists and their purchase order field.

  • Will we keep our rankings if we migrate?

    Not by accident, and yes if the redirect map is done properly. Every product, category and content URL is mapped to its new home before launch day and the internal links are updated to match. It is a named step in the launch phase and a deliverable you can audit, not a task somebody remembers.

  • Can the site show real stock?

    Yes, and the honest part of the answer is the word "real". It means one system is the truth about stock and the store reads from it on a schedule chosen per connection. Where the truth is a spreadsheet updated on Fridays, the site can only be as true as that, and we will say so before you commit.

  • How do you handle tax across provinces?

    Tax is decided by the destination and the product class, configured against your catalogue rather than set to a single default, and the total including it is visible before the order is placed. Where selling into a new province raises a registration question, that goes to your accountant with our working, not from us as advice.

  • What does it cost?

    The price is set after the discovery call and written into the proposal you sign. How scope and price are set

  • Can you build the French store properly?

    It can be built for French from the start, with product content, the checkout, the confirmation emails and search terms written in French rather than translated at the end. Who writes the French is agreed in the scope: your own people or a fluent writer brought in for the project.

  • What happens when a subscription payment fails?

    That is a design decision, not an accident, and we design it with you: how many retries, on what schedule, what the member sees, when access pauses and how it is restored. Recovering failed payments is usually worth more than acquiring new members, which is why it gets designed rather than defaulted.

  • Should we start with one side of the marketplace?

    Usually yes. Most two sided platforms are built by making one side work against a manually assembled other side, then automating the second once demand is real. We will help you work out which side is the hard one, because that is the side to build for.

Three services next to this one.

Where this matters most.

Four sectors, and the reason in each

  • Manufacturing and distribution

    The account price is the whole problem. A distributor's customers each buy at a number that was agreed in a conversation, and until the store knows those numbers the reorder stays a phone call and the inside sales team stays a typing pool.

  • Construction and trades

    Where there is a counter or a supply arm, the order that should take four taps at six in the morning is the one being taken by phone at eight. The buyer is in a truck, on a mid-range phone, on a cellular connection, and that is the only device that matters.

  • Professional services

    Not products, but plans: retainers, memberships, training, certification and renewals. The revenue arrives in month eleven rather than month one, which makes billing, entitlements and failed payment recovery the actual product.

  • Healthcare and clinics

    Named here with a limit rather than a pitch. Retail sales, plans and memberships are a normal build. Anything that touches health information is scoped out of the store rather than designed around, until the storage region and the handling are settled, and that boundary is written into the scope before the build.

Read on this topic

Every article about this service lives under one index, so a reader who wants depth has one place to go rather than a tag cloud.

The e-commerce and marketplaces index

Everything we have published on this

Two ways to start from here.

I know what I need to build.

Discovery call

A free conversation, then a written proposal with scope, price, and timing.

Request a discovery call

My website is underperforming.

Website Performance Audit

A written report and a prioritized plan of what to fix first.

Explore the audit

One catalogue, two prices, and a person on the credit.