# How We Choose Tech Stacks for Websites and Growth Systems

> How I choose between Next.js, Nuxt, Shopify, headless commerce, CMSs, animation stacks, hosting, APIs, and backend systems for real business use cases.

Source: https://www.truenorthmarketing.ae/en/blog/development-brainstorm-to-production
Author: Vedant Achharya
Published: 2026-07-19
Updated: 2026-07-19
Category: Web & Development
Tags: Web Development, Tech Stack, Next.js, Nuxt, Shopify, Headless Commerce, UAE, GCC
Publisher: True North Marketing (truenorthmarketing.ae)

## Article

I do not choose a tech stack by asking which framework is most impressive. I choose it by asking what the business needs the website or system to do every day after launch.

At True North, development sits beside performance marketing, creative, SEO, and AI automation. That changes the decision. A site is not only a visual surface. It may need to carry paid traffic, expose clean HTML for search and AI systems, sync product data from Shopify, write a lead into HubSpot, run a voice agent safely, animate a premium brand moment, and still stay maintainable for the team that owns it.

The best stack is the one that gives the business control without giving the team unnecessary machinery to maintain.

I choose technology only after the job is clear: content model, commerce model, rendering needs, integrations, authoring workflow, performance budget, data ownership, and the person who will operate the system.

## What job does this website actually need to do?

A stack choice should answer a business problem. "Build in Next.js" is not a strategy. Neither is "headless Shopify" or "use WordPress because it is easy." The first question is what the system must do reliably.

| Business need | Stack question I ask |
| --- | --- |
| Paid traffic landing pages | Can we control speed, copy, events, metadata, and testing without slow handoffs? |
| Ecommerce growth | Does the team need Shopify-native operations, or does the frontend need deeper control? |
| Content authority | Who writes, reviews, localizes, updates, and owns structured content? |
| AI or voice workflows | Which server tools, knowledge bases, logs, and human handoffs are required? |
| Premium brand experience | Which motion or 3D layer improves understanding instead of adding weight? |
| CRM and attribution | Which system owns the lead, customer, event, value, and source truth? |

That is why our development brainstorms look more like operating design than a framework debate. We are trying to prevent the founder from buying a beautiful site that cannot be measured, edited, crawled, or integrated.

## When do I default to Next.js?

I reach for Next.js when the project needs strong control over rendering, route structure, metadata, structured data, performance, server routes, and custom interaction. It fits many of our marketing sites, AI surfaces, custom funnels, dashboards, and headless commerce builds.

The practical advantage is not only React. It is the ability to mix static generation, server rendering, server components, metadata, API routes, image optimization, and deployment workflows inside one application. Current [Next.js documentation](https://nextjs.org/docs) makes that rendering and metadata model central to App Router projects.

Where it works well:

- service sites that need crawlable content, speed, and rich page systems;
- SEO and AEO-heavy sites with structured data and route-level metadata;
- product experiences where the frontend is part of the conversion path;
- headless Shopify or commerce builds where the theme is too limiting;
- AI interfaces that need server-side tools, signed calls, logs, and auth;
- dashboards and portals that require typed data contracts.

Where I avoid it: when the client only needs simple editing, native ecommerce operations, and a theme-level experience. A custom app is not automatically more premium. Sometimes it is just more to own.

## When does Nuxt make more sense than Next.js?

Next.js is not the only serious SSR framework. Nuxt is strong when the team prefers Vue, the ecosystem around the project is Vue-based, or the content and component model is a better fit for the client.

Nuxt supports server rendering, static generation, hybrid rendering, file-based routing, data fetching, and deployment patterns that can produce fast, crawlable sites. Current [Nuxt documentation](https://nuxt.com/docs) frames rendering modes as a core architectural decision, not an afterthought.

I would consider Nuxt for:

- editorial or product sites where Vue is already the team's language;
- brands that want structured content with strong frontend control;
- multilingual sites where the routing and content workflow fit Nuxt well;
- app-like experiences that need SSR without moving the team into React.

The deciding factor is not fashion. It is the team's ability to operate the stack and the business need for server-visible content.

## Should you stay on native Shopify or go headless?

Shopify is not one architecture. A native Shopify theme and a headless Shopify storefront solve different problems.

Native Shopify is usually the better first answer when the merchant needs stable operations: products, inventory, checkout, discounts, apps, theme editing, and a team that can manage the store without a developer in every change. Theme customization can still be serious work. We can improve layout, speed, sections, tracking, merchandising, SEO fields, and motion while staying close to Shopify's operating model.

Headless Shopify becomes worth discussing when the storefront itself needs more control than a theme can reasonably provide.

| Shopify path | Best fit | Tradeoff |
| --- | --- | --- |
| Native theme | Merchant-led operations, fast rollout, app compatibility, lower maintenance | Less frontend freedom and harder deep custom storytelling |
| Customized theme | Better brand, sections, tracking, and speed while staying Shopify-native | Still constrained by theme architecture |
| Headless Shopify | Custom frontend, richer content, complex international routing, strict performance and UX control | More engineering ownership, API discipline, cache logic, and preview workflow |

We have worked across both patterns. The [Twenty One Perfumes case study](/en/case-studies/twenty-one-perfumes) is a useful example because it compares a Shopify theme path with a Next.js headless storefront prototype instead of pretending one architecture is always superior.

## Which CMS actually fits your publishing workflow?

A CMS is not just "where the text lives." It defines who can publish, who can break layouts, how localization works, how SEO fields are managed, how approvals happen, and how content becomes structured enough for search and AI systems.

I usually group content systems like this:

| CMS model | When it fits |
| --- | --- |
| Repository MDX | High-control blogs, docs, technical content, case studies, and developer-owned publishing |
| Sanity or Contentful | Structured content, reusable blocks, previews, editorial workflows, localization |
| Strapi or custom CMS | Owned backend, custom permissions, internal workflow fit |
| WordPress | An existing editorial team already runs it; we work with it, but watch plugin bloat, security, and performance |
| Shopify CMS | Product and collection content that must stay close to commerce data |
| Webflow | Design-led marketing sites where the team needs visual editing and the app surface is limited |

For True North's own site, MDX works because we want typed content, case-study structure, strong version control, and developer-reviewed publishing. For a client with a non-technical marketing team publishing weekly, that same choice may be wrong.

## Does this animation earn its weight?

Motion can make a site feel expensive, but it can also make it slower, harder to operate, and worse on mobile.

My order is boring on purpose:

1. Use CSS for simple hover, reveal, and state transitions.
2. Use Framer Motion when React state, variants, layout transitions, or page choreography need control.
3. Use GSAP when a timeline, scroll sequence, or complex choreography is actually required.
4. Use Lenis only when smooth scrolling supports the experience and does not fight native behaviour.
5. Use Three.js only when 3D communicates the product, brand, or technical depth better than static media.

GSAP's [ScrollTrigger documentation](https://gsap.com/docs/v3/Plugins/ScrollTrigger/) is powerful, but power is not permission. We keep heavy motion behind a reason: product explanation, premium brand feel, spatial understanding, or a memorable interaction tied to the page's job.

Our creative and development work meet here. The [studio page](/en/studio) may need motion and media language. A lead-generation page may need restraint, speed, and a clearer form.

## What should the backend actually own?

Many websites do not need a large backend. They need a few reliable server contracts.

For growth systems, the backend usually owns:

- lead capture and validation;
- CRM writes to HubSpot or another system;
- server-side events for analytics and ad platforms;
- webhook handling and idempotency;
- user or account permissions;
- product, inventory, or booking reads;
- email, WhatsApp, or voice-agent tool calls;
- logging, retries, and failure queues.

Node.js, server routes, PostgreSQL, Supabase, queues, and custom APIs are tools around that job. For AI systems, we may add vector search, knowledge-base workflows, tool authorization, and evaluation logs. For ecommerce, Shopify often remains the commercial source of truth while the app layer controls presentation, personalization, and measurement.

This is where [AI automation](/en/blog/ai-automation-digital-marketing) and development are the same operating problem. The model can speak or classify, but the server must decide what is allowed and what was actually saved.

## Where should you actually deploy the site?

Deployment is not a final checkbox. It affects performance, preview workflow, rollback, environment variables, edge caching, image delivery, security headers, logging, and the team's confidence to ship.

Our formal partner ecosystem matters here because it sits close to real delivery. Vercel, DigitalOcean, and Cloudflare are not decorative logos for us. They represent deployment, infrastructure, and edge decisions we make repeatedly. HubSpot affects CRM and lifecycle handoff. Google and Meta affect acquisition and measurement. The point is not to force every client onto those platforms. It is that we understand how the website touches the rest of the growth system.

| Deployment path | Where I consider it |
| --- | --- |
| Vercel | Next.js sites, preview deployments, fast iteration, serverless routes, frontend-heavy apps |
| Cloudflare | DNS, caching, security, edge rules, image and traffic controls |
| DigitalOcean | More traditional app hosting, workers, databases, and controlled infrastructure |
| Netlify | Static and Jamstack-style sites where its workflow fits |
| WP Engine | WordPress sites where managed hosting and editorial operations matter |
| Shopify hosting | Native commerce where checkout and merchant operations should stay central |

The deployment stack should help the team ship safely. If one small copy update requires a fragile manual process, the architecture is hurting the business.

## When does a project need a full application stack?

Some projects are less like websites and more like tools: dashboards, internal portals, operational apps, or data-heavy customer experiences. In those cases, the question changes.

TanStack's ecosystem, including Router, Query, Table, and newer full-stack patterns such as TanStack Start, can be useful when the product needs strong client-side state, data fetching, tables, filters, and typed routing. Current [TanStack Start documentation](https://tanstack.com/start/latest) positions it around full-document SSR and modern React application patterns.

I do not reach for it because it is new. I reach for it when the interaction model needs it. A marketing site with a few forms does not need a data-app stack. A reporting product with filters, user state, and server functions might.

## How I make the final recommendation

The stack recommendation is usually a simple decision record.

| Question | What I write down |
| --- | --- |
| What is the business job? | The outcome this build needs to improve |
| Who operates it? | Founder, marketer, editor, developer, sales, support, or mixed team |
| What content model exists? | Static pages, structured CMS, products, docs, case studies, localized content |
| What must render on the server? | Core copy, metadata, schema, product data, authenticated state |
| What integrations matter? | CRM, analytics, ads, commerce, booking, email, voice, automation |
| What motion is justified? | CSS, Framer Motion, GSAP, Lenis, Three.js, or none |
| What can fail? | API errors, duplicate writes, slow pages, missing content, checkout issues |
| What proves it worked? | Qualified leads, orders, bookings, organic visibility, time saved, fewer handoffs |

This decision record is not bureaucracy. It is how we stop projects from becoming technology theatre.

## The stack should serve the growth system

The best build is not the most complex. It is the one the business can use, measure, maintain, and improve.

Sometimes that is a static Next.js site with MDX and structured data. Sometimes it is Nuxt with a strong CMS. Sometimes it is a customized Shopify theme. Sometimes it is headless Shopify, a custom backend, and a motion-heavy product experience. And sometimes the honest answer is a lean, modern build the team can genuinely operate, rather than a heavier custom app it will never maintain. We build on modern, engineering-grade stacks; restraint means matching scope to the job, not reaching backward for legacy tooling.

That is how I approach [web and software development at True North](/en/services#development): choose the stack around the commercial job, keep the system measurable, and only add complexity when it buys control the business will actually use.

## FAQ

### How do you choose the right website tech stack?

I choose the stack after defining the business job, content model, operating owner, integration needs, rendering requirements, and measurement path. We lead with modern, engineering-grade stacks: Next.js, Nuxt, and native or headless Shopify, matched to the team that will run the system. Legacy platforms can still be a pragmatic answer for an existing editorial team, but the wrong choice is always picking a framework before understanding who will operate it after launch.

### When do you prefer Next.js?

I prefer Next.js for high-control marketing sites, product-led sites, custom funnels, dashboards, AI interfaces, and headless commerce where React Server Components, static generation, server rendering, metadata control, API routes, and deployment workflows support the business model. It is strongest when engineering ownership is available.

### When does Nuxt make more sense?

Nuxt makes sense when the team prefers Vue, the content system already leans that way, or the project benefits from Vue's ecosystem while still needing SSR, SSG, hybrid rendering, strong routing, and a clean content experience. The decision is not Next versus Nuxt as status. It is operator fit.

### When should ecommerce stay native Shopify?

Native Shopify is usually best when merchant operations, theme editing, apps, checkout stability, and speed of management matter more than bespoke application control. We customize Shopify when the business needs a strong store that the team can operate without owning a full frontend application.

### When is headless Shopify worth it?

Headless Shopify is worth it when the brand needs deeper frontend control, complex content and commerce storytelling, custom performance budgets, international routing, or product experiences a theme cannot carry. It also adds ownership cost, so we only recommend it when the control clearly beats the maintenance burden.

### What CMS do you use?

It depends on the publishing workflow. Repository-backed MDX is excellent for controlled technical and editorial sites. Sanity, Contentful, Strapi, WordPress, Shopify CMS, and Webflow can fit when non-technical teams need editing control. The CMS must match the approval process, localization needs, SEO fields, and content velocity.

### How do animation libraries fit into serious websites?

Motion should clarify hierarchy, timing, and product feel. I use CSS and Framer Motion where React state and transitions matter, GSAP when scroll choreography or timeline control is genuinely needed, Lenis only when smooth scroll supports the experience, and Three.js only when the 3D scene earns its weight.

### What do you use for backend systems?

Most marketing and growth builds start with server routes, Node.js services, PostgreSQL or Supabase, CRM APIs, webhook orchestration, and server-side analytics. Heavier systems may need queues, workers, search, vector stores, or custom APIs. The backend is chosen around data ownership and failure recovery.

### How do partnerships affect stack selection?

Our formal partner and certification ecosystem helps execution, not sales theatre. Google, Meta, HubSpot, Vercel, DigitalOcean, and Cloudflare sit close to acquisition, CRM, deployment, and infrastructure decisions. We still choose the stack by client need, not by whichever logo looks strongest.

### What is the biggest mistake in stack selection?

Choosing a fashionable stack for a problem that needs operational simplicity. A headless build, custom backend, or animation-heavy frontend can be the right answer. It can also create avoidable cost if the team really needed a maintainable Shopify theme, a CMS-driven site, or a smaller server-rendered funnel.