About three years ago, a startup founder reached out to us in a panic. His development team had spent four months building a mobile app in a framework that, frankly, wasn't right for the project. They'd chosen it because the lead developer had used it at a previous job and was comfortable with it. Now they were hitting walls: the framework didn't support a key feature the app needed, performance was poor on older Android devices, and they were running out of runway.
They ended up scrapping four months of work and starting over. That's roughly $80,000 in development costs, gone. Not because the team was bad. Because the technology decision was made for the wrong reasons.
We see some version of this story at least a few times a year. The technology stack question seems technical, but the consequences are entirely business ones: timeline, budget, hiring, maintenance costs, and whether your product can actually do what you need it to do.
Here's how we walk clients through the decision.
Start with the Problem, Not the Technology
The first thing we ask in any new project conversation is: "What does this software need to do for your business?" Not "what technology are you interested in?" Not "do you want React or Angular?"
The technology choice should fall out of the requirements, not the other way around. When a client says they want a React app, our next question is always "why React specifically?" Sometimes they have a good reason. A lot of the time, the honest answer is that they read an article about it or a friend's company uses it.
We map out the functional requirements first, then the non-functional ones (performance needs, expected user count, integration requirements, deployment constraints), and only then start matching technologies to the list.
The Factors That Actually Matter
Here's what we evaluate, roughly in order of importance.
What systems does this need to integrate with? This is often the most constraining factor, and it's the one most teams underweight. If your organization runs on Microsoft infrastructure (SQL Server, Active Directory, Azure), building the backend in .NET is a practical choice because the integration work will be dramatically simpler. If you need to connect to a Python-heavy data science pipeline, a Python backend makes sense. If your existing systems expose REST APIs with no platform preference, you have more flexibility.
We worked with a financial services firm that wanted to rebuild their client portal. Their existing infrastructure was entirely Microsoft-based: SQL Server databases, Windows servers, Active Directory authentication. A previous consultant had proposed a Node.js backend. It would have worked, technically, but every integration point would have required extra libraries, extra configuration, and extra testing. We recommended .NET instead, and the integration work that would have taken weeks took days.
Who's going to maintain this after you build it? This is the question that separates good technology decisions from regrettable ones. If you're a company with an in-house team of three .NET developers, building your next project in Go because it's faster might give you a product that none of your people can maintain, debug, or extend. Now you're dependent on contractors forever, or you're hiring someone new just to support one application.
We always ask: what does your current team know? What can they realistically learn? If the answer is "we don't have a team yet," then we factor in the local hiring market. Some technologies have deep talent pools. Others require you to compete for a smaller group of specialized developers, which drives up salaries and makes it harder to replace someone who leaves.
What's the timeline? Some technology choices are faster to build with than others, but the specifics depend on what you're building. For an internal admin panel with lots of data grids and forms, Angular with DevExpress components will get you to a working product faster than React with custom-built components. For a consumer-facing web app where design flexibility is paramount, React or Next.js gives you more control over the user experience.
For mobile apps, the native-vs-cross-platform decision often comes down to timeline and budget. Flutter and React Native let you ship on both iOS and Android from a single codebase, which can save 30-40% of development time compared to building two separate native apps. But if your app relies heavily on platform-specific features (augmented reality, complex Bluetooth interactions, intensive local processing), native development in Swift and Kotlin might be necessary.
We built a field service app last year where the client needed iOS and Android support, but the app was primarily forms, photos, and GPS tracking. React Native was the right call. We shipped both platforms in 14 weeks. A native approach would have taken closer to 22 weeks for the same functionality.
What are your actual scaling needs? Note the word "actual." Not aspirational, not "what if we go viral." What does your user base look like today, and what does realistic growth look like over the next 18 months?
We've seen startups choose microservices architectures designed to handle millions of users when their realistic Year One audience was 500 people. That's months of extra development work for infrastructure they won't need for years, if ever.
A well-built monolithic application can comfortably serve thousands of concurrent users. You don't need Kubernetes and twelve microservices for an internal tool used by 200 people. Start with what you need now and architect it so it can be split apart later if necessary.
Common Mistakes We See
Choosing technology because it's trending. Every year, there's a new framework or language that the tech press declares is the future. Some of them are genuinely good. Some of them are gone in two years. We had a client who was quoted a project in a relatively niche JavaScript framework. Within a year, the core maintainer had moved on and the community was shrinking. The client came to us to migrate to React, which cost almost as much as the original build.
Our general advice: choose technologies with proven track records and active communities. It's not exciting, but "boring technology" is boring because it works.
Over-engineering for scale you don't need. We covered this above, but it's worth emphasizing because it's so common. Every additional layer of architectural complexity adds development time, increases the surface area for bugs, and makes onboarding new developers harder. Build for the load you actually have, with a clear plan for how to scale when you need to.
Ignoring the ecosystem. A programming language or framework doesn't exist in isolation. The libraries, tools, hosting options, and community resources around it matter just as much. Python is great for automation and data work partly because of pandas, scikit-learn, and hundreds of other mature libraries. React's value comes partly from the massive ecosystem of components, tools, and educational resources around it.
When we evaluate a technology for a project, we check whether the specific libraries and integrations we'll need exist and are actively maintained. A technically superior language with a sparse ecosystem will slow you down more than a "good enough" language with the right tools.
Treating the database as an afterthought. The database choice gets less attention than it deserves. SQL Server is our go-to for complex business applications with heavy reporting needs. Its query optimizer is excellent, and the tooling (SSMS, SQL Profiler) makes debugging and performance tuning much easier than the alternatives. PostgreSQL is what we recommend when the client needs an open-source option or is running on Linux infrastructure. For simpler applications with flexible data structures, MongoDB has its place, though we reach for it less often than the industry hype would suggest.
How Our Process Works in Practice
When a client comes to us with a project idea, the technology conversation usually takes two to three meetings.
In the first meeting, we focus entirely on business requirements and constraints. What does the software need to do? Who will use it? What systems does it need to talk to? What's the budget and timeline? We don't discuss specific technologies at all in this meeting.
Between meetings, we put together a technology recommendation document. It's usually two to three pages. For each layer of the stack (frontend, backend, database, hosting), we recommend a primary option and explain why. If there's a legitimate second choice, we lay out the trade-offs. We include rough timeline estimates for each approach.
In the second meeting, we walk through the recommendation together. The client asks questions, pushes back on things, brings up constraints we didn't know about. We adjust.
Sometimes there's a third meeting if the decision is particularly consequential or if we need to do a proof-of-concept to validate a technical assumption. For one project where the client needed real-time synchronization across mobile and web, we spent a week building a small prototype to confirm that our proposed approach could handle the data volume before committing to the full architecture.
The Technologies We Work With (and When We Recommend Each)
Here's a quick reference based on our experience:
- .NET (C#): Enterprise web applications, APIs that integrate with Microsoft infrastructure, complex business logic. Our most-used backend technology.
- React / Next.js: Consumer-facing web apps, marketing sites, applications where design flexibility and SEO matter.
- Angular: Large internal applications with many forms, data grids, and structured workflows. Pairs exceptionally well with DevExpress components.
- React Native: Cross-platform mobile apps where the core functionality is standard (forms, lists, maps, camera). Gets you to market faster than native.
- Flutter: Cross-platform mobile apps where you need very custom UI or smooth animations. Slightly better performance than React Native for graphics-heavy apps.
- Python: Automation scripts, data processing, machine learning integrations, API backends for data-centric applications.
- SQL Server: The default for business applications in our stack. Excellent for reporting, complex queries, and transaction-heavy workloads.
- PostgreSQL: When the project needs open-source, runs on Linux, or requires specific features like JSONB or PostGIS.
We don't have a "favorite" that we push on every project. The right answer depends on your situation.
Getting This Right Matters
The technology stack isn't just a developer decision. It affects how fast you can hire, how much maintenance costs, how easily you can add features in Year Two, and whether your software can actually handle what your business needs.
If you're starting a new project and aren't sure where to begin with the technology conversation, or if you're worried your current stack isn't the right fit, we're here to help. We'll tell you what we'd recommend and, just as importantly, why.
