Boring Technology Wins: Architecture for Mid-Market E-Commerce

Let me share a secret about mid-market e-commerce: boring technology wins.

Your clients (or your business, if you're the one buying) don't need cutting-edge. They need reliable. Maintainable. Something the next developer can understand without a six-month induction.

Umbraco, .NET, SQL Server, Azure. This stack is boring in the best possible way. It works, it scales, and you can hire people who know how to run it. Contrast that with enterprise platforms that need specialist consultants billing at eye-watering rates, or stacks so obscure nobody wants to maintain them. When a website goes down at 2am, you want someone who can fix it, not someone who needs to read the documentation first.

Boring is a feature, not a bug. So what does boring look like in practice?

A typical mid-market architecture

Umbraco sits at the centre: catalogue, checkout, customer accounts, order management. It connects to the ERP (usually Business Central or Dynamics in the UK market), syncing stock, pricing and customer data one way and pushing orders back for fulfilment.

Around that core, only what's needed. A PIM if the product data is genuinely complex - though honestly, for most mid-market projects the ERP or Umbraco itself handles product data fine, and PIM only earns its place with thousands of SKUs carrying complex attributes. A payment provider: Stripe for most, Adyen where the payment flows get more demanding. A fulfilment integration if there's a third-party logistics provider or separate warehouse system in the mix.

That's it. The architecture isn't complicated. The complexity lives in the details of each integration, not the overall shape - so keep the shape simple, and there's less to go wrong.

Real-time or scheduled?

The key architectural decision is how you sync with the ERP, and there are basically two options.

Real-time means every stock check and price lookup hits the ERP live. It's accurate - you're always showing current data. But it's slower, as you're waiting on the ERP to respond, and it's more fragile: if the ERP is down or slow, so is your website.

Scheduled sync means pulling data periodically and caching it locally. Every 15 minutes, every hour, overnight - whatever suits. It's faster (you're reading local data) and more resilient (a sluggish ERP doesn't take the site with it), but your data is only as fresh as the last sync.

Most projects land on a hybrid: scheduled sync for catalogue, product information and stock levels, where a slight delay is acceptable, and real-time for order submission, where you want it in the ERP immediately. The right balance depends on the business. A company selling ten high-value items a day has different needs to one selling hundreds of low-value ones, so ask about volume and tolerance for data latency rather than reaching for a default.

Beware the word "just"

If I had to pick one technical red flag, it's underestimating integrations, and the tell is always the same word.

"We just need to pull products from the ERP." But the product data is a mess, there's no unique identifier matching the website, and half the fields are used for things they were never designed for.

"We just need to push orders back." But the ERP expects data you don't capture at checkout, the field mappings differ for trade and retail customers, and nobody's quite sure what happens to returns.

"We just need to sync stock levels." But there are three warehouses, the ERP tracks each differently, and "available" doesn't mean the same thing as "in stock".

Every "just" in an integration statement is doing heavy lifting. Budget discovery time for every integration point. Assume the documentation is wrong or missing. Assume the first approach won't survive contact with real data. That's not pessimism, it's experience.

When there's no API at all

A few years ago we worked with a couple of high street fashion brands, Republic and Roman Originals. Their warehouse ran on a proprietary system called RSG. No API. No export function. The only way to see web order data was logging into a web portal or receiving an email.

"We just need to connect to the warehouse system" is how that brief started.

There was no connector and no documented integration path, so we built one: a process that logged into the portal, pulled down orders, and pushed stock updates back. Essentially, we automated what a human would do, as that was the only interface available. It wasn't elegant. It worked.

When someone says "we just need to connect to X", always ask: connect how, exactly? Sometimes the answer is "we don't know", and what you're really scoping is a design-and-build from scratch.

The takeaway

Keep the architecture boring and the shape simple: Umbraco at the centre, the ERP as the source of truth, hybrid sync as the default, and nothing in the diagram that hasn't earned its place. Spend the cleverness where it counts - inside the integrations - and treat every "just" as an invitation to ask harder questions. Boring technology, done well, is what still works in 20 years.

Tim Gaunt is the founder and CEO of TSD, a UK e-commerce agency that's been designing, building and supporting complex commerce platforms for over 20 years. This post is part of a series based on his Codegarden 2026 talk, The €200k Sweet Spot.