How to Choose a Tech Stack When the Business Has to Live With It

Your CTO candidate has just finished a pitch for a low-code platform. Your existing tech lead wants to build custom on Node.js. A vendor you met six months ago builds everything on a stack you've never heard of, and swears it's faster to ship on. You are the one who has to decide. In eighteen months, you'll also be the one explaining to the owner why the person who built the system left, and why nobody else can touch the code.

Most advice on choosing a stack compares frameworks on performance, ecosystem size, and how fast you can ship a first version. None of that matters if your city can't supply three competent developers who already know it, or if the one person on your team who understands the codebase hands in their notice in March. The question isn't which stack is best. It's which stack your business can still run two years from now, with different people in the room.

What should actually decide which stack you pick?

Two things decide it: the hiring reality in your location, and who owns the system after the original builder is gone. Everything else, performance, trendiness, developer preference, is secondary.

If you're a manufacturer in Ahmedabad or Coimbatore hiring an internal IT team, the stack has to match what the local job market actually produces. If you're a GCC trading company outsourcing development to a team in India, the stack has to match what that outsourced team's bench is built on, not what sounded impressive in a sales call. If you're a US-based buyer evaluating an India-based partner, ask them what percentage of their own bench can pick up a project in that stack without ramp-up time. A partner who has to hire specifically for your project has already told you something about risk.

This is also where the low-code versus custom argument gets resolved, not by ideology but by what you're actually automating. We understand how your business actually works first, then we design the system around it, and the stack decision follows from that, not the other way round.

Low-code or custom, which one actually survives?

Low-code suits approval chains and data entry with no complex logic. Custom suits anything with real business rules, integrations with other systems, or growth beyond a few hundred users.

A low-code platform gets a basic approval workflow or an inventory form running fast, and for a business with straightforward processes, that speed is real value. The trouble starts when the process has conditional logic, the kind you'd map out when designing who approves what on an org chart (our post on designing access control from the org chart covers how that mapping actually works). Low-code platforms handle three or four approval levels reasonably well. They start to strain when approval routing depends on order value, customer category, and plant location all at once, which is normal in manufacturing and trading businesses within a year of going live.

The other cost that doesn't show up in the demo is licence pricing at scale. Most low-code platforms price per user or per workflow run. A pilot with twenty users looks cheap. The same platform at three hundred users, which is where a lot of internal tools end up once word spreads across departments, can cost more annually than a custom build would have cost to maintain.

How do you tell if a stack is already dead in your hiring market?

Search job boards for that stack and your city, and count live listings over the last two weeks. If you find fewer than five relevant results, that stack is effectively dead for you, regardless of how healthy its global ecosystem looks.

This check takes fifteen minutes and tells you more than any framework comparison article. GitHub stars and Stack Overflow activity describe a global developer population. You don't hire globally for a maintenance role, you hire locally, or from whatever outsourced bench your partner maintains. A stack with a huge global following but no presence in your hiring city or your vendor's bench is a stack you'll be paying a premium for every time someone needs replacing.

The same check applies in reverse when evaluating an outsourced partner. Ask them how many people on their current bench, not just available to hire, already work in the stack they're proposing for you. If the answer involves hiring someone new for your project, you've just become dependent on one person again, only now it's someone you've never met.

What does "who maintains it" actually change about the decision?

It changes the question from "can this person build it" to "can a different person maintain it after this person leaves." Assume the original developer is gone within two years, because in most teams, they are.

This is where mainstream, slightly boring choices usually beat the stack a developer is excited to put on their CV. A developer who wants to learn a new framework on your project isn't wrong to want that, but it's your business paying for the learning curve, and your business paying again when they leave and the next hire has to climb the same curve from scratch. If the answer to "why does this break" needs a phone call to the person who built it, it's not a system, it's a dependency on a person, and you've bought software that behaves like an employee you can't replace.

Practically, this means asking for documentation that exists outside any one person's head before sign-off, not after launch. It means preferring patterns a new hire recognises on day one over patterns that are technically elegant but unusual. Boring and well-documented beats clever and undocumented, every time the business, not the developer, has to live with the result.

Does the stack decision change for an MVP versus a scale-up versus an ERP migration?

Yes. The acceptable risk in an unfamiliar stack goes down as the system's blast radius goes up.

For a small internal tool, the kind scoped by counting the decisions it removes from someone's daily judgement (our MVP scoping guide walks through that counting), a slightly unusual stack is a recoverable mistake. If it doesn't work out, you rebuild a small tool. For a system that will eventually hold production data, financial approvals, or customer records, the recoverable-mistake budget disappears, and mainstream, well-hired-for choices matter far more.

For an ERP migration, stack choice interacts directly with how you run the cutover. Running the new system alongside the old one, module by module, as covered in our piece on migrating off a legacy ERP without stopping the shop floor, only works if the new stack is one your team can staff for the full parallel-run period, which is often six to twelve months. An unfamiliar stack during a migration means you're short-staffed at exactly the point you can least afford it.

Factor	Low-code platform	Mainstream custom stack	Niche or trendy stack
Hiring pool in India, GCC, US	Platform-certified only, small	Large (Node, .NET, PHP, Java)	Very small, often one person
Cost to replace a developer	Retraining plus licence seat	Standard market rate	High, retraining or re-platform
Risk after year two	Vendor controls the roadmap	Medium, depends on docs	High, single point of failure
Best fit	Approval forms, simple workflows	Shop-floor logic, integrations, scale	Rarely justified for internal tools

What should you check before signing off on a stack?

Run a short checklist before the decision is final, not after development has started. Most stack mistakes are caught in an afternoon of checking, not in a year of regret.

The checklist isn't about technical depth. It's about forcing the hiring and maintenance questions into the room before the contract is signed, when they're still cheap to answer. Once development starts, every one of these questions becomes expensive to revisit.

If you want a structured way to work through this for a system you're planning now, our building software hub covers MVP scoping, access design, and migration in more depth, and our custom software development team can walk through the hiring and maintenance side of a stack decision specifically for your location and team size before you commit to a vendor or a platform.

The next step isn't choosing a framework. It's listing every system this one will need to talk to, every approval it will touch, and every person in your city or your vendor's bench who already knows how to keep it running. Do that list before the demo, not after.