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.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.
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 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 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.
We have worked across both patterns. The Twenty One Perfumes case study 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:
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:
- Use CSS for simple hover, reveal, and state transitions.
- Use Framer Motion when React state, variants, layout transitions, or page choreography need control.
- Use GSAP when a timeline, scroll sequence, or complex choreography is actually required.
- Use Lenis only when smooth scrolling supports the experience and does not fight native behaviour.
- Use Three.js only when 3D communicates the product, brand, or technical depth better than static media.
GSAP's ScrollTrigger documentation 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 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 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.
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 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.
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: choose the stack around the commercial job, keep the system measurable, and only add complexity when it buys control the business will actually use.
