If you're an owner sitting in a meeting where two developers are arguing about frameworks, here is what you actually need to know about how to choose a tech stack: the framework rarely matters as much as who you can hire to maintain it five years from now. I have sat on both sides of that table, as the developer with opinions and as the person who has to explain the decision to a non-technical founder, and the criteria that actually protect a business are almost never the ones developers argue about first.
Performance benchmarks, the elegance of a syntax, whether a framework is "modern," these are the topics engineers enjoy debating. They are also, for 95% of business web apps, irrelevant to whether the project succeeds. What actually decides success is whether you can find people to build and later maintain it, and whether the thing keeps running without drama for years.
This is the version of that conversation I'd have with you directly, as the owner approving the decision, not the developer making it.
Ask these four questions before any technology name comes up
Before "React vs Vue" or "Node vs PHP" enters the room, answer these:
- Who will build this? In-house team, agency, or freelancers?
- Who will maintain it in year three? Same team, a different agency, whoever you can find at that time?
- What is this app actually for? Internal tool, customer-facing product, something that needs to scale to thousands of users, or something that serves 50 staff?
- How long does this need to last? A campaign microsite has a different bar than a core operations system.
The answers to these four questions eliminate most technology debates before they start. A five-year internal tool maintained by whoever you can hire locally has completely different constraints than a customer app aiming for rapid scale with a dedicated engineering team.
Hiring pool beats performance benchmarks
Here's the uncomfortable truth for engineers who love a good technical argument: the fastest, most elegant framework is worthless if you can't hire anyone in your city who knows it well enough to maintain it without you.
In Indonesia, the practical hiring pool for business web apps looks roughly like this:
| Stack | Hiring pool size | Typical use case fit |
|---|---|---|
| React / Next.js | Large | Customer-facing web apps, dashboards, most business software |
| PHP (Laravel) | Large | Internal tools, admin panels, CMS-driven sites |
| .NET | Large in enterprise/finance sector | Systems needing strong typing, regulated industries |
| Node.js (Nest.js etc.) | Medium-large | APIs, backend services paired with React front ends |
| Niche/newer frameworks | Small | Rarely worth the risk for a business app unless a specific technical need demands it |
Choosing a stack with a large hiring pool means that if your original developer or agency disappears, and this happens more often than owners expect, you can find a replacement in weeks, not months. Choosing a niche stack because it's technically superior means you are betting the business's continuity on one person or one agency never leaving. That is a bad bet regardless of how good the technology is.
Five-year maintainability over benchmarks
A business web app is not a research project. It needs to still work, and still be maintainable, in year five, probably by people who did not build it. This changes what "good" means.
Boring, well-documented, widely-adopted technology ages better than clever, cutting-edge technology, because:
- Documentation and community support persist. A widely used framework has a decade of Stack Overflow answers and tutorials. A niche one has a Discord server that may or may not still be active in five years.
- Upgrades are gradual, not cliff-edges. Popular frameworks maintain backward compatibility paths. Smaller projects sometimes force painful rewrites when the maintainer changes direction or abandons the project.
- Onboarding a new developer is fast. If your stack is common, a new hire is productive in days. If it's obscure, expect weeks of ramp-up even for a good developer.
This is why, for the majority of business apps I've scoped, from an automotive workshop's booking system to a retail inventory tool, I default to React or Next.js on the front end and either Node.js or .NET on the back end, not because they're the most exciting choice, but because they are the safest long-term bet for a business that isn't in the business of software itself.
When it's actually worth deviating
There are legitimate reasons to pick something less common, but they should be explicit, not accidental:
- A regulated industry (finance, healthcare) where a specific stack has proven compliance tooling.
- An existing team with deep expertise in a particular stack, where switching would cost more in retraining than it gains in hiring-pool breadth.
- A genuinely unusual technical requirement, like heavy real-time processing, that a mainstream stack handles poorly.
None of these apply to most business web apps. If your developer's argument for a stack is "it's more modern" or "it's more fun to write," that is a preference, not a business justification, and you should ask them to make the case in terms of the four questions above.
Takeaway: decide like an owner, not a developer
How to choose a tech stack for a business web app comes down to two questions that have nothing to do with technical elegance: can you hire for it consistently, and will it still be maintainable in five years without depending on one irreplaceable person. Boring and common beats clever and rare almost every time. If you're evaluating a proposal right now and the justification leans on technical excitement rather than hiring pool and longevity, that's worth pushing back on before you sign off on the budget.