Tech Stack Generator

There is no best stack, which is unhelpful, so here is the useful version: the best stack is the one your team can operate on its worst week. That is usually the one they already know, and failing that the most boring option with the largest community and the fewest moving parts.

The failure mode is choosing for a company you are not yet. A two-person team picks Kubernetes and event-driven microservices because that is what scale looks like, and spends the first year operating infrastructure instead of finding customers. You can migrate off a monolith when you have the revenue to pay for it. You cannot get the year back.

Weight three things in this order: what your team knows, what you can hire for, and what you can operate without a platform engineer. Everything else is preference, and preference is worth less than it feels.

Ask most founders what their stack is and you get a language, a framework and a database. That is maybe a third of the decisions, and the missing two thirds are where the delays come from.

Authentication is the most consistently underestimated. "Users can log in" sounds like a week and is not, once you add password reset, email verification, sessions, roles, organisations, invitations and eventually single sign-on. Use a managed service unless you have a reason not to.

Then there is the operational half, which produces no demo and is the difference between a product and a prototype: deployment, environments, secrets, backups you have actually tested restoring, error tracking, logs you can search, and uptime monitoring. A team that skips these ships faster for two months and then slows down permanently.

If you handle UK personal data you are subject to UK GDPR from your first user, not from your first enterprise deal. That means knowing what you store, where it lives, how long you keep it and how you would delete it if somebody asked. Retrofitting deletion into a schema that was not designed for it is genuinely difficult.

If you take card payments, use a provider that keeps you out of PCI scope. Never touch card numbers with your own code. This is one of the few places where the decision is simply made for you.

Everything else is unglamorous and cheap if you do it early: dependency scanning turned on, secrets out of the repository, least-privilege access, two-factor on everything, and a written answer to what happens if a laptop is stolen. These take an afternoon at the start and weeks later.

Every stack stops working eventually and that is not a mistake, it is a decision reaching the end of its useful life. The mistake is not noticing, and the other mistake is rewriting the moment somebody feels friction.

Change when there is a specific, measured problem the current choice causes and a specific fix. Queries timing out on a table you cannot index any further. Deploys taking forty minutes and blocking the team. A dependency abandoned by its maintainers.

Do not change because the code feels old, because a new engineer prefers something else, or because a conference talk made it look easy. A rewrite costs more than anybody estimates, produces nothing a customer can see, and is the single most reliable way for a startup to lose six months.

It works from a description. It has not seen your code, met your team, or read the contract with the deadline in it. Treat the output as a strong default to argue with, not a decision.

The cost figures are estimates at the scale you described. Cloud pricing is complicated and changes; use them for order of magnitude and check the actual pricing pages before committing.

It does not know what your team is genuinely good at, beyond what you tell it. That single fact outranks everything else here, so if you fill in one optional field, fill in that one.

Run it and nothing you paste is stored. Submit the form to unlock more runs or to download the recommendation and what you typed comes to us with your address, which is what the tick box on that form says. Either way, describe the product rather than pasting code or anything under NDA.