How do you choose a tech stack without being a developer?
You don't need to code to steer the tech choice – you need to ask the right questions. What matters is talent availability, maturity, operating cost, and how easy the technology is to recruit for. Watch out for exotic choices that lock you into one vendor, and ask multiple vendors to justify their choices in comparable terms.
Choosing a tech stack can feel like a question only engineers are allowed to have opinions on. That’s not true. You don’t need to write a line of code to steer the decision wisely – you need to ask the right questions and weigh the answers. And it’s a decision worth engaging with, because the tech choice stays with the product for years and affects what it costs to run, improve, and staff long after the build is finished.
Let go of the idea that you have to understand the technology
Your job isn’t to decide whether one framework is technically superior to another. You leave that judgment to the developers. Your job is to make sure the choice is made for the right reasons – that it fits your situation, not just the agency’s habit. That takes no programming knowledge, just a few straightforward questions and the nerve not to settle for “trust us.”
Think of it like choosing a car without being an automotive engineer. You can’t design the engine, but you can ask about running costs, parts availability, and how easy the car is to resell. The same logic applies to technology.
The criteria that actually matter
Four questions carry most of the decision, and none of them are about technical elegance:
- Talent availability. Are there plenty of developers who know the technology, or a handful in the whole country? The wider the availability, the lower the risk.
- Maturity and stability. Is the technology proven and well maintained, or new and untested? New technology is tempting but carries more risk.
- Operating cost. What does it cost to run the product month after month – servers, licenses, services? Cheap to build isn’t the same as cheap to own.
- Recruitability. If you want to bring development in-house or switch vendors in two years – how easy is it to find people who can take over?
Weigh long-term ownership more heavily than how fast something can be built right now. The fastest route to launch is rarely the cheapest route over five years.
The warning flag: the choice that locks you in
The single most dangerous trap is an exotic technology few people know. It might be chosen in good faith – maybe it’s genuinely smart – but the effect is still that you’re stuck with the vendor who chose it. If you want to switch, it becomes hard and expensive to find someone who can take over, and that realization always comes at the worst possible moment.
Be extra alert, then, when a vendor advocates for something unusual with arguments you can’t really evaluate. Ask directly: how many other people know this, and how easy would it be for us to switch away from you? A vague answer is an answer in itself.
A scenario
Say two agencies quote the same product. One proposes a widely used, proven stack; the other a niche platform you’ve never heard of, with the promise that it builds faster. That speed claim might well be true. But ask what happens if you want to switch vendors in three years. Around the widely used stack, there are hundreds of developers to choose from. Around the niche platform, maybe a handful – and several of them work for the vendor itself. The time saved at the start can turn into a lock-in that costs far more than it saved.
A question template for comparable answers
Have vendors justify their choices against the same questions, in writing, so you compare reasoning against reasoning:
| Question | What the answer reveals |
|---|---|
| Why this technology for our product specifically? | Whether the choice is deliberate or just the house habit |
| How mature and widely used is it? | The risk level in stability and support |
| What does the recruiting picture look like in Sweden? | How easily you can staff up going forward |
| What does operating it cost per month? | The long-term cost of ownership |
| How easily can we switch vendors later? | The degree of lock-in |
A serious vendor answers all of this clearly and in writing. One who gets irritated by the questions is telling you something about how the collaboration will feel.
At Weapp we’re glad to justify our tech choices against your needs rather than our own convenience, and we recommend proven technology where long-term ownership matters most. Want help evaluating a technical proposal? Take a look at our services or get in touch.
Frequently asked questions
Do I need to understand the technology to choose the right stack?
No, but you need to be able to ask the right questions and weigh the answers. You don't need to know how a framework works internally – you need to know if it's mature, if you can recruit for it, what it costs to run, and whether it locks you in. Anyone can ask those questions.
What's the risk of an agency just proposing its house stack?
That the choice is driven by what the agency already knows rather than what best fits your product. Sometimes those coincide, sometimes they don't. An agency's favorite technology can be excellent – but have them justify the choice against your needs, not just their own convenience, so you know which it is.
How risky is it to choose an unusual technology?
It can lock you in hard. An exotic stack that few people master makes you dependent on the exact vendor who chose it – if you switch, it becomes difficult and expensive to find someone who can take over. Proven, widely used technology is almost always safer for long-term ownership, even if it feels less exciting.
Which criteria carry the most weight in a tech choice?
Talent availability and recruitability, the technology's maturity and stability, and total operating cost over time. A technology that's impossible to staff or expensive to run becomes a long-term burden no matter how elegant it is in theory. Weigh long-term ownership higher than short-term development speed.
How do I fairly compare two vendors' technology proposals?
Give them the same question template and ask for written, justified answers on the same points: why this technology, how mature is it, what does the recruiting picture look like, what does it cost to run, and how easy is it to switch vendors later. Then you're comparing reasoning against reasoning instead of gut feeling against gut feeling.