How We Choose a Tech Stack for an E-commerce Build

Tech stack conversations go wrong in a predictable way. Someone proposes a framework, someone else has a preference, and the discussion becomes about tools rather than outcomes. On a commerce project, that is backwards. The stack should fall out of the business requirements, not the other way around.

Here is the framework we actually use when starting a build.

Why the stack is a business decision

Every architectural choice trades something: launch speed, ongoing cost, flexibility, or the size of the team you need to maintain it. Those are business variables. Choosing React over another framework matters far less than whether you can hire for it, ship on time, and change direction without a rewrite.

So we start with constraints, not technologies.

The five questions we ask first

1. What does the business actually sell, and how? A standard catalogue, a configured product, a subscription, a marketplace, or a service are five different problems.
2. Who will maintain this in two years? A stack your future team cannot run is a liability, however elegant.
3. What has to move fast, and what has to be correct? Checkout correctness and marketing page speed have different tolerances.
4. Which integrations are non-negotiable? ERP, warehouse, payments, support tooling. These quietly dictate the architecture more than anything else.
5. What is the realistic launch date, and what happens right after? Shipping something credible beats shipping something perfect late.

The options on the table

Hosted commerce

Shopify and its peers handle payments, tax, fulfilment, and the operational burden that surrounds selling. You trade some control for a large amount of reliability and speed.

This is the right answer more often than agencies like to admit.

Headless commerce

A hosted commerce backend with a custom front end. You gain complete control of the experience and the ability to serve multiple channels, at the cost of building and maintaining more yourself.

Headless is genuinely powerful and genuinely expensive. It should be a deliberate choice, not a default.

Custom application

When the business logic does not fit a cart at all, custom software is the honest answer. This is where the platform stops being a constraint and your own code becomes the product.

We build these when pricing, workflow, or domain complexity genuinely demands it.

What we usually recommend

Our default for most merchants is the hybrid: a hosted platform for the commerce core, plus a small custom layer for the specific thing that makes the business different. It keeps the boring parts boring and concentrates custom effort where it creates advantage.

That pattern is exactly how we approach our own products: a hosted foundation, with custom logic where it matters.

The cost nobody budgets for: migrating later

Reversing a stack decision is expensive in a way that is easy to underestimate. Migration cost scales with the custom logic and data you have accumulated. A store with two years of custom checkout rules is a very different project from a fresh build.

That asymmetry is the whole argument for spending an extra week on the decision now.

Our default toolkit

For most of our work:

• Next.js and React for marketing sites and custom front ends, because the ecosystem is deep and hiring is realistic.
• React Native for cross-platform mobile when one codebase matters more than platform-specific polish.
• Node.js for APIs and services that need to sit close to the front end.
• Shopify for the commerce core, extended through apps and theme extensions.

None of these are dogma. They are defaults chosen for maintainability by a small team, and they get revisited whenever the constraints say they should.

The short version

Ask what the business needs, who will maintain it, and what happens after launch. Pick the least complex stack that satisfies those answers, and write down why you chose it. Six months later, that note will be worth more than any benchmark.

If you are weighing a rebuild or unsure whether your current stack is holding you back, our custom builds service covers exactly this, or you can start a conversation.