Choosing the Right Tech Stack: Avoiding Regret and Ensuring Success

The failure pattern shows up around month eighteen. The site that launched on time, on budget, doing what the brief asked for, has become the constraint. Conversion has plateaued. A feature the business needs — tiered B2B pricing, a wholesale portal, a custom checkout, headless content distribution to a mobile app — sits outside what the platform supports. The agency that built it offers workarounds. The internal team quietly starts pricing a rebuild. The answer, almost always, is more than the original build cost.

The decision that led here was made eighteen months earlier in a meeting that took perhaps thirty minutes. The platform was picked because the agency knew it, a competitor used it, or the licence fee was low. The business requirements that would have changed the answer — roadmap, integration set, traffic curve, the team that would maintain it — were never weighed against the platform's limits.

A platform selection framework is the structured trade-off that prevents that outcome. It is not a vendor comparison; it is a decision process that scores a small set of candidates against the business they will run, the team that will own them, and the cost of being wrong. The output is a written rationale for one platform, the conditions under which it would be re-evaluated, and a documented exit path. This article walks through the process in enough detail that a founder, CTO, or head of digital can run it on their own decision before signing the build proposal.

The framework sits inside P01 — The Right Problem — of EB Pearls' Built to Last™ 2.0, alongside the Discovery Workshop™ and the Riskiest Assumption Test™. The discipline applies to web platforms, eCommerce builds, and custom software stacks. The principle is the same in each case: choose for the business, not the team.

What Choosing the Wrong Platform Actually Costs

The cost of a poor platform choice compounds along three axes — and only the smallest of them is the rebuild bill.

The first is the rebuild itself. Migrating from a hosted platform to a headless stack, or from a CMS to a custom application, commonly costs more than the original build. Templates have to be re-authored. URL structures, SEO equity, and analytics tags have to be carried across without losing rank. Data has to be exported, transformed, and re-imported through APIs never designed for bulk extraction. None of that work was in the original budget.

The second is opportunity. While the rebuild is in flight, the roadmap is not. New features sit in a backlog because the existing platform cannot ship them and the new one is still in design. Competitors who chose better do not pause.

The third is the easiest to underestimate. A team that has invested two years in a platform has built process, deployment, monitoring, and content workflows around it. Replatforming asks them to relearn all of that while the business waits. Some of them leave. Some of the knowledge leaves with them.

This is why the framework treats platform fit as a first-class decision, not an implementation detail. The cost of the assessment is small; the cost of skipping it is paid back over years.

The Five Dimensions of the Decision

The framework is a structured comparison of three to five platform candidates against five business dimensions, scored independently then combined. It is not an objective ranking — different businesses will score the same platform differently — and it is not meant to produce a winner by arithmetic. The score exists to make trade-offs explicit so the decision can be defended in eighteen months when the business has changed.

Business stage and growth trajectory. A pre-revenue MVP and a Scale-stage business with twelve months of usage data are not solving the same platform problem. A platform that is fine for proving the concept may be wrong for the next 10× of traffic, or vice versa. The framework asks where the business is now and where it expects to be in three years. The platform must fit both the current state and the most credible next horizon.

Feature fit against roadmap. A platform is not chosen against today's features; it is chosen against the roadmap the business has committed to and the integrations that roadmap implies. A retail business adding B2B alongside DTC, or a content site syndicating to a native mobile app, has feature requirements some platforms support natively and others require expensive workarounds for. Score each candidate on roadmap fit — including features the business has not yet built.

Total cost of ownership over three years. Sticker price is the worst proxy for cost. A platform with a low licence fee but high transaction fees, mandatory app subscriptions for table-stakes features, or heavy customisation overhead can cost more in year two than a higher-licence-fee platform with everything included. Model three-year TCO including licence, hosting, third-party apps, integration build, customisation, and the operational team it will require.

Exit cost and platform lock-in. Every platform decision should be made with the exit in mind, because some exit will eventually happen. What would it cost to migrate off this platform if the business outgrew it in eighteen months — data export, content portability, integration rebuild, SEO continuity? Platforms vary enormously here. Some make exit close to costless; others structurally penalise it. The exit number is a real number even if you don't use it.

Team fit and maintenance footprint. The team that will operate the platform after launch matters more than the team that builds it. A platform that requires a developer for every content update is fine for a brochure site; it is wrong for a retailer that ships content daily. Assess the team you will actually have, not the team you wish you had.

A platform that scores well on three dimensions and badly on two is not automatically wrong — it depends on which two. A weak score on team fit can be fixed by hiring; a weak score on exit cost cannot, and shows up only when you need to move.

Working the Matrix: WordPress, Shopify, Headless, Custom

For most web and commerce builds, candidates fall into four buckets — and the right answer is rarely obvious from outside the assessment.

WordPress fits content-led businesses with predictable editorial workflows, light commerce, and a marketing team that needs to ship pages without engineering involvement. It scores well on team fit and year-one TCO, moderately on roadmap fit when commerce becomes central, and weakly on exit cost when heavily customised. It is the right answer more often than its critics suggest, and the wrong answer when chosen by reflex.

Shopify fits product-first DTC retail at the MVP and early-Scale stages, where the team needs storefront, payments, fulfilment, and an admin in one platform. It scores well on team fit and time-to-market, moderately on three-year TCO once app subscriptions compound, and structurally weakly on exit cost. It is the right answer for a business whose roadmap stays inside Shopify's commerce model — and the wrong answer when bespoke checkout, deep B2B logic, or headless distribution will be needed sooner than the platform delivers them.

Headless commerce — a decoupled front-end on a commerce backend like Shopify Plus, BigCommerce, or commercetools — fits Scale-stage retailers and brands that need control over experience, performance, and channel distribution. It scores well on roadmap fit and exit cost, moderately on team fit (it requires real engineering capacity), and weakly on year-one TCO compared with a hosted store. It is the right answer when the business has the team to operate it and a roadmap that monolithic platforms will throttle.

A custom application is the right answer when the business workflow is the product — when no off-the-shelf platform models what the business does, integration density is high, or data ownership is non-negotiable. It scores best on roadmap fit and exit cost, weakest on year-one TCO and time-to-market. It is over-prescribed by agencies who build it well and under-prescribed by agencies who don't.

The matrix is the artefact: five dimensions across the top, three to five candidates down the side, a score and a written rationale in each cell. The rationale is what the team will read in eighteen months when the question of "did we choose right?" comes up.

How to Run the Assessment

The assessment is a half-day working session with the people who will own the platform's outcomes — a founder or business sponsor, the head of marketing or commerce, the head of engineering or external technical lead, and a finance representative who can defend the TCO numbers. A platform decision made without finance present is a decision that will be revisited the first time the invoice arrives.

The week before, gather the inputs: a written three-year roadmap, a list of required integrations (committed versus speculative), a traffic model, and a list of the operational team that will own the platform post-launch — with their actual skills, not their job titles.

The session itself runs the matrix. Each dimension is scored for each candidate, with the rationale captured live. Disagreements are documented, not averaged. The output is the chosen platform, the dimensions on which it scored weakest, the conditions that would trigger re-evaluation, and the exit path documented in advance.

What to avoid: scoring on developer comfort, scoring on what competitors used without checking whether their business shape matches yours, scoring on a single feature when the rest of the roadmap is the larger consideration. And — the most common error — running the assessment after the platform has been chosen, as a justification rather than as a decision. By that point, the rationale is reverse-engineered and the exercise is theatre.

A Composite Scenario: The Cost of Choosing on Comfort

An Australian retail business at the early-Scale stage chose Shopify on the recommendation of an agency that had built dozens of Shopify stores and could ship one in six weeks. The store launched on time. Conversion was solid. For the first nine months, everything worked. Then the business added a wholesale channel with tiered pricing, then a subscription product, then an enquiry-driven custom-quote flow for higher-value items. None of these were in scope at launch, and none fit the platform's commerce model cleanly. Each was implemented as an app bolt-on with a per-month subscription fee. By month fifteen, the app stack was costing more than the platform licence and the checkout had become brittle. By month eighteen, the business committed to a headless rebuild that took six months and cost more than the original site.

A comparable retailer with the same stage and mixed DTC-and-wholesale ambition ran the platform selection framework before signing a proposal. Shopify scored well on team fit and time-to-market, weakly on roadmap fit when wholesale and subscription requirements were modelled out three years, and weakly on exit cost. The team chose headless on day one, at a slightly higher initial build cost. Launch took three months longer. Eighteen months later, both businesses were running at comparable revenue. The second had spent nothing on a rebuild and had shipped two roadmap features in the time the first spent migrating.

Same starting point. Different decision. Different second year.

When This Assessment Matters Most, and When It Can Wait

The framework matters most when the platform will run a business with a roadmap that already exceeds what a single hosted product can model — multi-channel commerce, regulated workflows, deep integration with finance or operations systems, expected scale beyond what the platform's reference customers describe, or a long-term content strategy needing SEO continuity beyond a likely replatform cycle.

It matters less, though it is still worth running, when the platform's job is short-lived and small in scope — a campaign microsite, a single-product MVP, a brochure site for a non-revenue function. The assessment can be compressed to a one-hour conversation against a shorter matrix. What you should not do is skip it entirely. The cheapest decisions are often the ones most worth documenting, because the cost of being casually wrong compounds the longest.

If the decision is being made on developer comfort, vendor relationship, or a single feature in isolation, slow down and run the matrix anyway. The half-day cost is the cheapest insurance you will buy across the life of the build.

What to Do Next

If you are within four weeks of signing a build proposal, the platform selection framework is the half-day exercise that should sit between the proposal and the signature. Draft the three-year roadmap. List the required integrations. Pull together the people who will own the outcome. Score the candidates against the five dimensions, with written rationale in every cell. For the broader question of how the rest of an engagement is structured around the same discipline, see how we approach custom software delivery end to end.

Frequently Asked Questions