How to choose the right technology stack for a digital project: what we ask before writing code

Choosing a tech stack for a digital project starts with three questions: who will actually use this, what does the business need to do in two to three years, and what existing systems does this need to talk to. Everything else — framework choice, hosting model, commerce platform — is a consequence of those answers. Use this before scoping features.

 

Why the tech question is never just a tech question

From our project work, the most expensive mistakes we see aren't wrong framework picks — they're stacks chosen before anyone understood the user. A React front-end is the wrong answer when half the audience is on a 4G connection in a warehouse. A headless commerce build is the wrong answer when the client has no engineering team to maintain it. A custom platform is the wrong answer when a standard one would have shipped six months sooner.

Tech decisions only look like tech decisions. They're really business decisions about maintenance cost, speed to market, user experience on the actual devices people use, and what happens when the business grows or changes direction.

 

The three questions we answer first

1. Who is actually using this?

Not "the target persona" on the brief, but the real people: where they are, what devices they use, how reliable their internet is, whether they'll install an app, how much of the flow they want to complete on a phone in three minutes. We pull this from user behavior data, analytics, or a short round of interviews when there's nothing on record.

 

2. What is the business trying to do in two to three years?

A site built for 5,000 orders a month is structurally different from one built for 50,000. A brand launching a single product line uses a different stack than one preparing for wholesale and retail simultaneously. We ask where the business thinks it will be in 24 months so we don't design a solution that has to be rebuilt in 12.

 

3. What existing systems does this need to talk to?

Fulfillment, CRM, inventory, accounting, analytics, the marketing stack, the customer support tool. Each of these is either a connection the project must support or a limitation we have to design around. Missing this question is the reason many rebuilds happen — the original stack couldn't connect to what the business already depended on.

 

Two types of briefs — and how we respond to each

When a client arrives with a feature list

Sometimes the brief comes in as a list of features the client wants built. This happens most often when the client has already been thinking hard about the problem and has converged on a solution shape.

Our job here is not to build the list. It's to check the list against the three questions above and push back where a feature doesn't serve the stated outcome. "You've asked for a live chat widget — we pulled the analytics on your current site and 0.3% of visitors click the existing help link. Can we talk about whether this is the right investment versus a better FAQ page?" We bring data, not opinions, and we respect the client's final call when they have context we don't.

 

When a client arrives with a business problem

Sometimes the brief is open: "we want to grow online sales" or "we need a better way to work with our sales team." No feature list, no fixed direction.

Here we propose options. We show reference projects inside the client's industry so they can react to something concrete, and sometimes we bring patterns from adjacent industries when they fit the problem better. The goal is to converge on a direction both sides can commit to before we start scoping — not to ship the first idea.

 

The four paths we most often recommend

Path 1: Standard e-commerce website

Best when the business needs SEO reach, multiple product categories, connections to standard fulfillment and inventory tools, and a foundation that will hold up for years of growth. We usually recommend this when selling direct to consumers at meaningful volume is the goal. It integrates cleanly with search engines, paid channels, analytics, and shipping and inventory APIs.

 

Path 2: Progressive Web App (PWA)

Best when the audience is on inconsistent internet, uses a wide range of devices, or pushes back on installing another app. A PWA works through a browser, caches what the user needs for offline use, and behaves app-like without taking up space on the device. We often recommend this for field-facing tools — sales teams on the road, agricultural suppliers in rural areas, logistics operators across multiple sites.

 

Path 3: Messaging-first commerce

Best when the audience already lives inside a messaging platform and will not install anything new. In practice, this means setting up an official business presence on a platform the audience uses daily — WhatsApp Business, Facebook Messenger, Instagram DM commerce — with a structured chatbot that handles common questions, routes complex ones to a human, and pushes notifications when something needs attention. The product isn't a site the user visits; it's a conversation thread they already have open.

 

Path 4: Legacy integration project

Best when the real work isn't a new interface — it's connecting a new surface to an existing system the business already runs on. Enterprise clients often have an ERP, a CRM, or an inventory database that holds the single source of truth, and the project is about building a thin, safe layer on top of it. We scope these tightly, with the client's internal IT team involved from week one, and we treat API contracts and data integrity as the center of the work.

 

The user reality check

One recurring reason a "good" stack fails in production is that it was chosen for the developer's machine, not the user's. We've built for audiences whose browsers were several major versions behind what modern frameworks support. In those cases the right choice isn't the newest front-end library — it's a stack that actually loads for the people who need to use it.

Same pattern applies to connectivity, screen size, and device age. A flashy single-page app that takes 8 seconds to paint on a mid-range phone on 4G is a failure, no matter how elegant the codebase is. We check this before we pick the stack, not after launch.

 

Red flags that the proposed stack is wrong for the brief

We treat these as signs to revisit the tech choice — and we catch them in scoping, not production:

- The client wants "the newest framework" but has no engineering team to maintain it after launch. Fix: choose a mainstream, well-documented stack the client can hire for, or include a maintenance agreement.

- The stack cannot integrate with the client's fulfillment, payment, or CRM provider. Fix: change either the stack or the provider — don't ship a system that won't talk to the business.

- A growth-critical site has no SEO hooks, no analytics layer, or no way to run marketing pixels. Fix: fold these into the architecture before development, not as a retrofit.

- The team only knows the experimental stack and has no fallback if it doesn't hold up. Fix: run a short technical spike before committing, or keep a reliable stack in reserve.

- The client's audience is on older devices or slow connections that the chosen stack doesn't perform well on. Fix: reconsider the front-end approach, or add a lightweight fallback path.

 

When to stick with what we know vs. try something new

On tight timelines, we stick to what the team is fastest and most reliable with — usually HTML, CSS, JavaScript, PHP, and WordPress for marketing sites and mid-weight commerce builds. Predictable output, predictable schedule.

When the brief gives room — longer timeline, a client who explicitly wants to explore new approaches, or a problem a mainstream stack handles awkwardly — we'll propose newer options: Node.js, Nuxt, Firebase, Docker, React, or a streaming-specific setup when the product needs live video. We don't ship these on short runways. And we don't pick them because they're new; we pick them because the specific brief rewards what they do.

 

Every recommendation traces back to the three questions. If we can't explain a stack choice in terms of users, business horizon, and integration load, we haven't finished thinking yet.