Choose a tech stack by testing constraints

Choose for the product you have to operate

A stack is a set of tools you will learn, connect, secure, pay for, and maintain. The right choice is the one that gets the important user outcome into reliable use with the least total burden under your actual constraints. A popular stack is not automatically a good fit; the cheapest advertised plan is not automatically the lowest-cost system.

Write constraints before comparing products

Make a short decision brief:

• Product shape: content site, dashboard, API, mobile app, background processing, or a combination.
• Must-work journeys and data types.
• Experience the builder already has and time available to learn.
• Requirements for authentication, authorization, privacy, backups, regions, accessibility, and uptime.
• Integrations that are essential now, not merely plausible later.
• Expected usage range and what event would make capacity important.
• Acceptable recurring spend and the cost of migration or downtime.
• Who will respond when the service breaks.

Use estimates as ranges and label assumptions. “May reach a million users” is not a workload. “About 200 weekly reports, each processing 500 rows, produced every Monday” gives you something to compare.

Compare a few realistic options

Score each candidate from 1–5 against the same criteria and write one sentence of evidence for each score: can you ship the core flow quickly; are docs and examples understandable; can you get help; does it satisfy data/security needs; can you export data; what is the bill at plausible use; what do you do at an outage; how hard is the exit? Weight the criteria that matter to this product. A weighted total is a way to reveal assumptions, not a scientific ranking.

Verify current prices, quotas, terms, and data-processing details on official vendor pages immediately before commitment. Record the date, expected volume, tax/currency assumptions, and which plan features you rely on. Treat every vendor comparison as time-sensitive procurement research, not a permanent recommendation.

Use a boring default, then revisit on evidence

If two options are close, pick the one you can already operate and document. Keep provider-specific code at the boundary where separation is cheap, but do not build a premature portability framework. The Twelve-Factor App is a useful set of operational design prompts for web services, not a requirement to adopt every factor for a small product. Make backups in formats you can restore elsewhere. Write down a trigger for revisiting the choice: a measured limit, repeated outage, required integration, security obligation, or sustained cost.

For a solo builder, operational simplicity is a feature. One managed database and one deployment path may beat a collection of fashionable services. Conversely, a service that hides a critical capability or creates an unmanageable lock-in may be a poor bargain. Use evaluate builder tools to compare a specific product, and MVP scope to keep the stack from outrunning the evidence.