"Tech stack" means the set of tools an app is built with: the programming language, the database, where it is hosted. Non-technical founders often feel they should have an opinion about it, and then either defer completely or pick something they read about.
You do not need an opinion on the tools. You need an answer to one question.
Key Takeaways
- The question that matters: if this developer disappears, can I hire someone else to work on it within a couple of weeks?
- Popular, boring tools are the safe default, because many developers know them.
- Unusual tools, private frameworks, and platforms you cannot export from are the real risks.
- Ask the builder to explain each choice in one sentence of plain English.
The One Question
"If you were hit by a bus tomorrow, how fast could I find someone to take over?"
Ask it exactly like that. A good builder will not be offended. The answer tells you almost everything:
- "Very fast, these are among the most common tools in the industry" is what you want.
- "Well, we use our own framework, so it would need to be us" is lock-in, however good the framework is.
- "It is built on a platform, so you would need someone who knows that platform" is a middle case you should understand before signing.
Why Common Tools Win
Popularity is a feature for a business owner. It means more developers to hire, more answers online, and fewer surprises.
The numbers are public. In the Stack Overflow Developer Survey 2025, JavaScript was used by 66% of respondents, SQL by 58.6%, and Python by 57.9%, and PostgreSQL was the most used database at 55.6%. A web app built with JavaScript or TypeScript, Python, and PostgreSQL, hosted on one of the big cloud providers, is something a very large pool of developers can pick up.
That is roughly what our own software factory builds with: React, Next.js, Node.js, Python, TypeScript, PostgreSQL, and AWS or GCP. We pick them for the same reason you should want them: whoever works on your app after us will know them.
A Plain-English Map
| Part | What it does | Common, safe choices |
|---|---|---|
| Frontend | What users see and click | React, Next.js |
| Backend | The rules and logic behind the screens | Node.js, Python |
| Database | Where the information is kept | PostgreSQL |
| Hosting | The computers it runs on | AWS, Google Cloud, Vercel |
| Mobile | Phone apps, if needed | React Native, Flutter |
You do not need to remember this table. Hold it next to any proposal. If most of the proposal's choices appear on it, you are in safe territory. If most do not, ask why.
Warning Signs
- "Our proprietary platform." You may never be able to leave.
- The newest tool of the month. Exciting to developers, harder to hire for.
- A different tool for every small part. More moving pieces, more things to maintain.
- No explanation. If the builder cannot tell you why in one sentence, the choice may be about their habits rather than your app.
- Code that lives only inside a builder platform. Some no-code platforms do not let you export your app as code. See when to move your app off a no-code builder.
A Concrete Version
An owner gets two proposals for a customer portal.
Proposal A: Next.js for the screens, Python for the logic, PostgreSQL for data, hosted on AWS. Each choice explained in a line ("PostgreSQL because your data has clear relationships, clients, documents, invoices").
Proposal B: the agency's in-house framework, a newer database the lead developer likes, hosted on the agency's own servers.
B is not necessarily worse built. But if the owner parts ways with that agency in a year, B probably needs the agency or a rewrite. A can be handed to almost any web developer. For a business that needs the portal for years, A is the safer bet, even at a slightly higher price.
The Honest Counterpoint
Common is not always right. Some apps have unusual needs, like heavy real-time video, offline use in the field, or specialized data work, where a less common tool is the correct call. And a skilled team with a slightly unusual tool can outperform an average team with a popular one. The point is to make the unusual choice on purpose, with a reason you understand and a plan for who maintains it, rather than by default. Our engineering post on choosing boring technology makes the longer case.
Frequently Asked Questions
Should I let the developer choose?
Yes, within limits. Let them choose among common tools, and ask the one question above. Veto anything that fails it unless the reason is convincing.
Does the tech stack affect cost?
Somewhat. Common tools usually mean faster building and cheaper maintenance, because developers do not need to learn anything new.
Can I change the tech stack later?
Yes, but it is usually a rebuild, which is expensive. Our post on whether to rewrite or refactor your app covers that decision.
Do I need a technical advisor to check this?
For a small app, the one question and the table above are usually enough. For a larger build, a few hours with a fractional CTO is money well spent.
The Bottom Line
Ask who could take over if the builder disappeared, prefer tools many developers know, and make every unusual choice a deliberate one. If you want a builder that uses mainstream tools and hands you everything at the end, look at our software factory. If you are earlier than that, start with the free honest read.
Roberto Espinoza is CEO of Ruzora, which builds custom software for business owners at a fixed price and places pre-vetted senior LATAM engineers with US teams. Get a free honest read on your idea.
