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 |
|---|---|---|---|
| procol.ai | Fast B2B marketing site, campaign pages shipped often | Next.js, TypeScript, Tailwind CSS | Server rendering for Core Web Vitals, a component library for quick pages, typed props that fail at build time |
| Sun Shoppers | Grocery marketplace with vendors, commissions and accounting | WordPress, WooCommerce, WCFM, Elementor Pro, Xero | Supported plugins the client can maintain instead of a custom vendor system |
| Blenzy | Faithful build of a Figma design, edited by the client | WordPress and Elementor with custom CSS | The client needed to edit visually after handover |
| mohitgoyal.in | Indexable portfolio with an AI chat and an admin | TanStack Start, React, Firestore, Claude API | Server rendering with typed routes, and no custom backend to host |
| 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. 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.
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 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. Sun Shoppers uses WCFM rather than a hand-built vendor system, which keeps it within supported plugins the client can maintain.
- 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.
If you choose No developers, the Advisor favours tools you can run yourself, such as WordPress, Webflow, Shopify or no-code automations, and says when you would outgrow them. It is free with no sign-up, with ten runs per tool 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, send me the project 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, and on WordPress and WooCommerce for teams that edit their own sites.
