A business doesn't need to pick a programming language — it needs to check five things: how many specialists in that stack the market has, what its maintenance costs, whether it fits your scenario, how easily you could switch contractors later, and whether the team has real experience in it. A mainstream stack is almost always the better deal than an exotic one: cheaper to build, cheaper to maintain, and the product never becomes hostage to a single team.
Contents
Why "what to build it in" isn't your question
Clients often get pulled into a technical argument: React or Vue, Flutter or React Native, Node or Python. From the outside it looks like a decision the product's fate depends on, but for most business tasks several stacks would work — the difference isn't in capability, it's in cost of ownership and risk.
For most business tasks several stacks would work — the difference isn't in capability, it's in cost of ownership and risk.
Below are five criteria for judging a proposed stack without understanding programming.
Criterion 1: the talent market
The most practical criterion. If your team walked away tomorrow, how quickly could you replace them?
Mainstream technologies
- Plenty of specialists
- Competitive rates
- Knowledge that transfers easily
Rare technologies
- Months of searching
- The price is set by a market of three people
We deliberately work on a mainstream stack: TypeScript, Node.js, PostgreSQL, React. It isn't the trendiest choice at conferences, but you aren't tied to us — any team with that set can continue from our documentation.
Criterion 2: cost of ownership
Development is a one-off payment; maintenance is a permanent one. Cost of ownership includes:
- hosting and infrastructure;
- dependency and security updates;
- changes;
- and above all, how fast a new developer can understand the project.
Indirect signs of expensive maintenance
- A homegrown framework "of our own design"
- Unusual architecture with no documentation
- Heavy infrastructure for a simple task
- All of it can be justified — but the contractor should explain exactly how
The opposite extreme: builders and template CMSes
- Cheap at the start
- Hit a ceiling when you need a non-standard scenario
- Then the rewrite is total — more expensive than building in headroom from the beginning
Criterion 3: fit with the scenario
The technology should match what the product actually does. A few practical examples:
A content site meant to bring in customers from search
- What's critical
- Server-side rendering
- Note
- Otherwise search engines and AI assistants see an empty page
A customer portal or internal system
- What's critical
- Roles, permissions and reliable data handling
- Note
- Animation polish is secondary
A mobile scenario with camera, background geolocation or offline
- What's critical
- Native or cross-platform with access to those capabilities
- Note
- Detailed breakdown in our PWA vs apps article
High load or real-time
- What's critical
- Architecture matters more than language
- Note
- Queues, caching, service separation
Criterion 4: freedom to switch contractors
A good stack doesn't tie you to the builder. Three questions settle it:
- Is the code in your repository?
- Is the infrastructure on your accounts?
- Is there enough documentation for another team to pick up the project without you?
It's the same principle as in the contract: rights to code without the practical ability to use it is half a guarantee.
Criterion 5: the team's actual experience in it
The best stack in the world won't help if the team is learning it on your project. Ask directly: how many projects have been built on this set, can you see working examples, who on the team owns this part.
Questions instead of a holy war
A short list that replaces the technical argument:
- Why this stack for my task?
- How many specialists are on the market for it?
- What will maintenance cost per year?
- What would another team need to continue?
- What limits appear if the product grows several times over?
Want your project checked? Come to a brief: we review both the current stack and the alternatives, with an honest cost-of-ownership estimate a couple of years out.
