The technology stack debate — which framework, which language, which database — can consume enormous amounts of time and generate strong opinions. Most of the debate is misdirected.
The right tech stack for your project is almost never the newest, or the trendiest, or the one the most vocal engineer on the team prefers. It’s the one that best fits the specific constraints of what you’re building, who’s building it, and how it will need to evolve.
The Questions That Actually Matter
What is the application actually doing?
A customer-facing web application, an internal business tool, a mobile app for field workers, a data processing pipeline, and a real-time communication platform each have different performance characteristics, different hosting considerations, and different frameworks designed for them. Starting from the use case narrows the field significantly before any other conversation happens.
Who is building and maintaining it?
A technology a team is highly productive with is worth more than an objectively superior technology they’re unfamiliar with. Learning curves have real costs: higher initial development time, more bugs from unfamiliarity, slower debugging. If your team has deep expertise in a stack, the productivity advantage usually outweighs the benefits of switching to something newer.
What does the hosting and operational environment look like?
Some stacks run cheaply on commodity hosting. Others require specific runtime environments, GPU access, or managed services that cost significantly more. If the application needs to run in a constrained environment (a client’s on-premises infrastructure, a specific cloud provider, an edge network), the viable stack choices may be determined by the environment rather than preference.
What does the long-term maintenance picture look like?
Technologies have lifecycles. A framework that’s actively maintained, has a large community, and is backed by a stable organisation will be easier to hire for, find answers about, and keep secure in five years. A framework that looked exciting at the time but turned out to be a dead end creates costly migration projects later.
Common Patterns and When They Apply
Frontend: React, Vue, or Angular
For most business web applications, React is the pragmatic choice — the largest ecosystem, the most available developers, the widest adoption. Vue is a reasonable alternative when team preference or project scale favours a lighter framework. Angular suits larger enterprise projects where its strong opinions about structure are an asset rather than a constraint.
Backend: .NET, Node.js, Python
.NET is excellent for business applications: strong typing, mature ecosystem, excellent performance, and well-suited for APIs, background services, and integration work. Node.js performs well for I/O-heavy APIs and real-time applications. Python is the dominant choice for data science, machine learning, and scripting, though for most business APIs it’s a weaker fit than .NET or Node.
Mobile: React Native or .NET MAUI
For most business apps targeting both iOS and Android, cross-platform is the right call. React Native has the larger ecosystem and community. .NET MAUI is the stronger choice when the rest of the codebase is .NET and shared business logic matters. Native development (Swift/Kotlin) is reserved for performance-critical or platform-specific use cases.
Database: SQL Server, PostgreSQL, or MongoDB
For structured business data with relationships, a relational database (SQL Server or PostgreSQL) is almost always the right choice. MongoDB suits applications with genuinely variable or document-like data structures. Don’t choose a database because it’s interesting — choose it because it fits the data model.
What to Avoid
Choosing by hype. New frameworks attract attention out of proportion to their proven fitness for production use. Some become industry standards; many more quietly disappear.
Designing the stack before understanding the problem. Technology choices made before requirements are understood tend to reflect team preferences rather than project needs.
Over-engineering for scale. Most business applications don’t need the distributed systems architecture designed for global consumer platforms. The additional complexity has a real cost in development time and operational overhead.
Under-valuing operational simplicity. A stack that’s slightly less optimal but dramatically easier to deploy, monitor, and debug is often the better choice in practice.
The Real Priority
Consistency within a codebase matters more than having made the objectively optimal choice. A coherent system built on well-understood foundations — even conventional ones — is easier to maintain, extend, and hand over than a patchwork of best-of-breed choices that don’t fit together well.
Working through technology decisions for a new project? Talk to us — we’ve designed and built software across a wide range of stacks and can give you an honest view of the trade-offs.