Every enterprise web project starts with the same question: what do we build it in? And every time, someone in the room has a strong opinion based on the last thing they used. The result is a religious debate when what you actually need is a practical, evidence-based decision. Here is how we evaluate it.
What You Need to Know
- There is no universally "best" tech stack. There's the right stack for your project, your team, and your timeline
- The most important factor isn't the language. It's whether you can hire for it, maintain it, and scale it over 5-10 years
- Framework maturity, community size, and hosting options matter more than benchmarks
- We've built enterprise apps across PHP, Node.js, and .NET. Each has its place
The State of Play in 2016
The web development world has more options than ever, and more opinions to go with them.
55.4%
of developers use JavaScript, making it the most popular language worldwide
Source: Stack Overflow Developer Survey, 2016
JavaScript is everywhere. Node.js has brought it to the server, and frameworks like Express and Hapi are maturing fast. On the front end, React is gaining serious traction and Angular 2 just launched. The JavaScript ecosystem is moving quickly, which is both its strength and its risk.
PHP still powers the majority of the web. Laravel has transformed what PHP development looks like, and PHP 7 brought performance improvements that silenced a lot of the criticism. For teams with PHP experience, it remains a strong choice.
.NET is the enterprise incumbent. C# is a well-designed language, Visual Studio is a serious IDE, and the recent open-sourcing of .NET Core signals that Microsoft is serious about cross-platform. If your organisation runs on Windows infrastructure, .NET is the path of least resistance.
The Questions That Actually Matter
Tech stack debates usually focus on the wrong things. Benchmark performance, syntax elegance, what's trending on Hacker News. Here's what actually matters for an enterprise project that needs to run for years.
Can you hire for it?
This is the single most important question in New Zealand. We're a small market. If you choose a stack that has five capable developers in the country, you've created a dependency that will hurt when those developers move on.
PHP and JavaScript have the largest talent pools in NZ. .NET has a solid pool, particularly in Wellington and Auckland's enterprise sector. Go, Rust, and Elixir are interesting technologies with tiny hiring pools here.
Pick a stack where you can replace any team member within a reasonable timeframe. Glamorous choices that nobody else knows how to maintain aren't glamorous for long.
How mature is the framework?
A framework's age matters. Not because new is bad, but because mature frameworks have solved more edge cases, have better documentation, have more Stack Overflow answers, and have established patterns for common problems.
5 years
minimum framework age we recommend for enterprise projects
Source: IDESIGN internal guideline
Laravel (PHP, released 2011), Express (Node.js, released 2010), ASP.NET MVC (.NET, released 2009). These have years of production use behind them. The bugs have been found. The patterns are established. The documentation is written by people who've actually used them in anger.
Newer frameworks can be excellent, but for a system that needs to be maintainable for five to ten years, proven is better than promising.
What does the hosting look like?
Enterprise clients care about where their data lives and who can access the infrastructure. Your stack choice constrains your hosting options.
.NET traditionally means Windows servers, though .NET Core is changing this. PHP and Node.js run on Linux, which gives you more hosting flexibility and generally lower costs. AWS, Azure, and local NZ hosting providers all support Linux well.
Think about this early. A stack that runs beautifully in development but requires specialised hosting in production creates ongoing friction.
How does it handle your data?
Most enterprise applications are data-heavy. Complex queries, reporting, relationships between entities. Your stack needs to work well with your database, and your database choice matters as much as your language choice.
PostgreSQL is our default recommendation for new enterprise projects. It handles complex queries well, has excellent data integrity features, and scales further than most enterprise applications will ever need. MySQL is solid for simpler use cases. SQL Server makes sense if you're in the Microsoft ecosystem.
The ORM or query builder matters too. Does the framework have a mature database layer? Can it handle migrations? Does it make complex queries readable or does it fight you?
The ThoughtWorks Perspective
The ThoughtWorks Technology Radar is one of the few industry publications we trust for stack guidance. Their 2016 assessment is worth reading.
They've moved React into "Adopt," which aligns with what we're seeing. Docker is in "Trial" for production use. Microservices are generating buzz but they caution against premature adoption. For enterprise, that caution is warranted. A well-structured monolith is easier to build, deploy, test, and maintain than a poorly structured set of microservices.
How We Decide at IDESIGN
We don't have a default stack. We have a decision framework.
What does the client already run? If the organisation has a .NET team and Windows infrastructure, building in Node.js creates unnecessary friction. Work with what's there unless there's a strong reason not to.
What does the project need? Real-time features push toward Node.js. Complex business logic with heavy database interactions works well in PHP with Laravel or .NET. High-traffic public-facing applications benefit from Node's async model.
What's the team's experience? Our team has depth in PHP and JavaScript, with solid .NET capability. We'll choose the stack where we can deliver the highest quality in the available timeframe. Novelty isn't a factor.
What's the maintenance plan? Who maintains this after we deliver? If it's the client's internal team, the stack must match their capability. If it's us, we have more flexibility. Either way, the decision needs to account for year three, not just month one.
The best tech stack is the one your team can maintain at 2am when something breaks. Not the one that looked exciting at a conference.
John Li
Chief Technology Officer
A Practical Recommendation
If you're starting an enterprise web application in 2016 and you don't have strong existing infrastructure constraints:
Back end: Laravel (PHP) or Express/Hapi (Node.js). Both are mature, well-documented, and have strong NZ talent pools. Choose based on team experience.
Front end: Start with server-rendered HTML and progressive enhancement. If you need rich interactivity, React is the front-end framework with the most momentum and the clearest architecture.
Database: PostgreSQL. Unless you're in the Microsoft ecosystem, in which case SQL Server.
Hosting: AWS or a local NZ provider with good support. Decide based on data sovereignty requirements and the client's comfort level.
Deployment: Get a proper CI/CD pipeline from day one. Jenkins, GitLab CI, or similar. Manual deployments are a risk that compounds with every release.
This isn't the only right answer. But it's a defensible starting point that will serve you well for years. The stack decision shouldn't be the hardest part of your project. The problem you're solving should be.