To choose a tech stack, answer three questions in order: what are you building, who will build and maintain it, and what matters most, such as speed to launch, SEO, scale, low running cost or easy editing. Then pick popular, well-documented tools that fit those answers, and start with the simplest version that works. There is no best stack, only the best fit for your project and your team.
I have shipped 100+ sites in 4+ years on stacks ranging from WordPress page builders to Next.js and plain JavaScript. The free Tech Stack Advisor asks the same three questions and returns a stack with reasons. Here is the thinking behind it.
Why does the right stack depend on the project?
Because each layer is a trade-off. A marketing site the content team edits every day needs a different stack from a real-time dashboard. A visual builder makes editing easy and costs some speed. A custom React frontend makes the site fast and flexible and means a developer for every layout change. Neither is wrong; they fit different teams.
The most expensive mistakes I see come from choosing the stack first and the requirements second: a headless setup for a five-page brochure site, or a page builder for something that is really an app.
What are the three questions?
What are you building? List the main features, who uses them and what the product must connect to: payments, a CRM, accounting, maps. Integrations shape the stack more than page count.
Who builds and maintains it? No developers, one developer, a small team or an agency. This is the question people skip, and it decides the most. A stack nobody on the team can run is a liability from launch day.
What matters most? Speed to launch, SEO and content, scale and performance, low running cost, or easy editing for non-developers. You can have several, but you have to rank them.
How did I choose stacks on real projects?
| Project | What it needed | Stack | Why |
|---|---|---|---|
| Taxocity | Tax and compliance firm site that captures leads | Custom WordPress on Bricks Builder, Google Sheets | Mostly pages and forms, with every lead saved to a Google Sheet |
| IPL Biologicals | WooCommerce store and corporate site, with a careers section and the Grow Organic sub-brand | WordPress, WooCommerce, custom Oxygen Builder theme | Custom product templates, and one site to maintain on a monthly retainer |
| Cyprianis | New homepage, events listing and private dining template from a Figma design | WordPress and Elementor | Elementor templates for the homepage, events and private dining pages, built from Figma |
| mohitgoyal.in | Portfolio with a chat that answers as me | TanStack Start, React, Claude API, Firestore | React for the site, the Claude API to answer as me and Firestore as a managed database |
| Under1MB | Image converter with no uploads | Plain JavaScript, HTML and CSS | Everything runs in the browser, so there is no server to run at all |
Notice that the same developer picked five different stacks. The project and the people running it decided each one.
Which priority changes the answer most?
Easy editing for non-developers. When the client's team will update pages and build new ones, I lean towards WordPress with a builder such as Bricks or Elementor, because they can do it without me. When developers ship every page, a code-based stack like Next.js wins on speed and control: server rendering helps Core Web Vitals, a shared component library keeps pages consistent and TypeScript catches broken props at build time. My post on Next.js or WordPress for a marketing site goes deeper on that one decision.
Speed to launch is the second big one. It favours mature tools with plugins or managed services for the hard parts: payments, auth, email. Building any of those yourself is rarely the fastest route.
How do common stacks compare on editing, speed and cost?
This is the shortlist most business websites end up choosing from. Prices change often, so check the linked pricing pages before you budget.
| Stack | Editing for non-developers | Speed | Maintenance needs | Typical running costs |
|---|---|---|---|---|
| WordPress plus Bricks or Elementor | Easy and visual | Good with caching and a lean builder | Core, theme and plugin updates, plus backups | Shared WordPress hosting from a few dollars a month (Hostinger), plus a builder licence (Elementor Pro, Bricks) |
| Next.js | Hard without a CMS; developers ship changes | Excellent when server rendered | Dependency updates and a developer for layout changes | Free hobby tier, Pro from $20 per member a month on Vercel; paid Workers from $5 a month on Cloudflare |
| Headless WordPress | Easy for content, layouts need a developer | Excellent | Two systems to update, host and monitor | WordPress hosting (Hostinger) plus frontend hosting (Vercel) |
| Shopify | Easy for products and pages | Good, fully managed | Low; the platform handles hosting and security | Plans from $39 a month, less if billed yearly, plus apps and transaction fees (Shopify) |
None of these wins every column. WordPress is cheapest to run and easiest to edit, Next.js is fastest and most flexible, headless gives you both at the cost of running two systems, and Shopify trades control for a platform that looks after itself.
What does a stack cost to run after launch?
The build is a one-off. Running costs arrive every month, and they are where cheap-looking stacks get expensive. Count these before you decide:
- Hosting. Shared WordPress hosting is a few dollars a month; a commercial Next.js site on Vercel Pro is billed per team member.
- Licences. Page builders, premium plugins and themes usually renew yearly. Five premium plugins at a yearly fee each add up quickly.
- Platform fees. Shopify charges a monthly plan plus transaction fees unless you use its own payments, and most stores add paid apps.
- API usage. Maps, email, SMS and AI features are often billed per request. An AI chat on the Claude API is priced by usage, so traffic changes the bill.
- Maintenance time. Someone has to apply updates, test them and fix what breaks. That is a real monthly cost whether it is your time or a retainer.
My post on Next.js website cost vs WordPress breaks the build and running costs down side by side.
When is headless WordPress worth it?
Headless means WordPress holds the content and a separate frontend, usually Next.js, renders the pages through the REST API or WPGraphQL. It is worth it when three things are true: your content team already knows WordPress and publishes often, the site needs speed or app-like features a builder can't give you, and you have a developer to look after two systems.
It is not worth it for a five-page brochure site, for a team that wants to build its own layouts, or on a budget that can't cover a developer after launch. In those cases a well-built WordPress site with a lean builder gets you most of the speed for a fraction of the effort. I cover the decision in headless WordPress with Next.js: when is it worth it?, the numbers in how much a headless WordPress site costs, and the build itself on my headless WordPress service page.
What mistakes should you avoid?
Do not choose a stack because it is new
New tools are exciting and thinly documented. Popular, well-documented tools are easier to hire for, have answers to common problems and keep working for years.
The Stack Overflow Developer Survey shows React and Node.js among the most used web technologies year after year, and W3Techs puts WordPress behind over 40% of all websites. That popularity is what makes them easy to hire for and quick to fix.
The others I see most:
- Microservices before users. Split a system when one part needs to scale on its own, not on day one.
- Tools nobody on the team knows. The person who maintains it should be comfortable with it.
- Custom where a plugin or service exists. A multivendor marketplace is a good example: plugins such as WCFM Marketplace already give vendors dashboards, commissions and membership plans, so building that by hand rarely makes sense. My multivendor marketplaces service and guide to building a multivendor marketplace on WooCommerce cover the trade-offs.
- Ignoring running costs. Hosting, plugin licences and API usage add up every month after launch.
- No plan for content. Every stack needs an answer to "where do people edit the words?"
How do you use the Tech Stack Advisor?
- 1
Describe the project
The main features, who uses it and any systems it has to connect to. Specific beats short.
- 2
Set team and priority
Pick who will maintain it and what matters most. Both change the right answer.
- 3
Read the reasons, not just the names
You get a layer-by-layer stack with reasons, an alternative and when to pick it, trade-offs and an architecture diagram.
- 4
Pressure-test it
Ask whoever will maintain the site whether they can run each layer. Swap anything they cannot.
The Advisor recommends a stack based on what you are building, who will maintain it and what matters most. You get a layer-by-layer stack with reasons, an alternative stack, the trade-offs and an architecture diagram. It is free with no sign-up, with 10 runs per day.
What should you do after choosing a stack?
Write it into the project scope, with the reasons, so every developer you talk to quotes the same thing. My guide to writing a website project scope has a template, and the Architecture Diagram Generator draws the system so everyone sees the same picture.
If you want a second opinion from someone who uses these stacks every day, contact me with the project or book a call, and I will reply with the stack I would pick and why. I build on Next.js and React through my Next.js and React websites service, on WordPress through WordPress websites on Bricks, Elementor and Oxygen, and online stores through WooCommerce stores and online ordering for teams that edit their own sites.
