How to choose the right tech stack (without an engineering degree)

The question I hear most often goes like this: "Vlad, what technology should I use?" And the honest answer, almost every time, is that the question has no answer until we change the question.

"Which technology is best" assumes there's an objective ranking, the way there is for cars or phones. There isn't. A technology is good or bad only in relation to your situation: who writes it, who maintains it, how fast you need to reach the market, where it has to hold up. Two teams building the identical product can make completely opposite correct decisions, because they work in different contexts.

I've sat on both sides of this. I led architecture as CTO at a legaltech company, where every stack decision tied us to years of maintenance. I built the most performant Romanian speech-to-text model, integrated into a product valued at €4M, where the wrong infrastructure choice would have been costly and painful to undo. The pattern that keeps repeating isn't "which tool is hottest". It's "which constraint did you forget to put on the table". The detail on my technical roles lives on vladtudor.com.

Why "what's the best stack?" is the wrong question

The question starts from the tool and hunts for a justification. A good decision runs the other way: it starts from your situation and lets the constraints eliminate the options.

The trouble with the tool-first approach is that it leaves you exposed to fashion. Every year a framework or a database arrives that everyone praises online, and founders pick it so they don't fall behind. Six months later they find the documentation is thin, they can't find people who know it, and every trivial problem costs a week of research. They optimised for how the decision looked, not for how it feels a year into maintenance.

The reframe is simple. Not "what's best", but "what's good enough and runnable with the resources I actually have". It's the same constraints-first logic I apply when we discuss whether something is worth building at all.

The four constraints you decide from

Almost any technology decision reduces to four questions. If you've answered them honestly, the choice nearly makes itself.

Who will maintain it

This is the first one and the most ignored. A technology nobody on the team knows isn't a choice, it's a debt. Ask who'll write the code this week, and who'll fix it at 2am a year from now. If the answer is you, alone, pick what you already know. If you have a small team, pick something you can hire for without a months-long search.

How fast you must ship

Early on, the speed of reaching your first users beats almost any technical consideration. A technology that ships in three weeks is better than a "superior" one that ships in three months, because the first gives you real feedback and the second gives you nothing but tidy architecture. Performance matters when you have users asking for it, not before.

Where it must scale

Ask the question honestly: do you actually need scale now, or are you assuming you will? Most products never reach the scale they prepare for on day one. It's fine to choose a solution that runs well up to your first thousands or tens of thousands of users, and to solve scale when you genuinely have it. Premature scale is a bill you definitely pay for a problem you might never have.

What you already know

Your existing knowledge is a real asset, not an excuse. If you know a particular set of technologies well, starting from there gives you speed and fewer surprises. New technology always carries a hidden learning cost, and you pay it at exactly the moment you have the least time to spare: the beginning.

Monolith or microservices

This is the architecture decision founders get wrong most often, and almost always in the same direction: towards microservices, too early.

A monolith is a single application that holds all the logic. Microservices split the application into many small services that talk to each other. Microservices solve a real problem, but it's an organisational one: it shows up when many teams trip over each other working in the same code. If you're one, two or five people, you don't have that problem. You have the opposite one, shipping fast with few people, and microservices make that harder, not easier.

The practical recommendation: start with a well-structured monolith with clear internal boundaries. When you genuinely feel the pain microservices relieve, you'll know where to cut, because the boundaries are already there. The reverse (starting with microservices and wishing you'd kept a monolith) costs far more.

Build or managed services

The second recurring decision: do you build a component yourself, or pay a service that hands it to you ready-made? Authentication, payments, sending email, search, database infrastructure. Each comes in both flavours, and the technical founder's instinct is often to build them, because they can. "Can" isn't the same as "should".

The rule I use: build what sets you apart, buy the rest. If user authentication isn't the reason customers choose you, there's no sense spending weeks building it and years maintaining it. Pay for a service and invest your expensive time in the part that actually matters. The reverse trap, buying the very component that is the heart of your product, leaves you without control over the thing you depend on most.

The two costliest mistakes

Almost every stack failure I've seen reduces to two patterns.

First: over-engineering for scale you don't have. Small teams building big-company infrastructure, "to be ready". Ready for what? They spend months on architecture for millions of users while the product doesn't yet have a hundred. It's the most expensive way to postpone the moment you find out whether your product matters at all.

Second: the full rewrite. It shows up when a team decides the current stack was a mistake and must be rebuilt from scratch. Large rewrites are among the riskiest projects in software, because you spend months rebuilding what you already have, adding no value for the user, while the old product still demands your attention. Joel Spolsky, co-founder of Stack Overflow and Trello, called the decision to rewrite code from scratch "the single worst strategic mistake that any software company can make" (Joel on Software, "Things You Should Never Do, Part I", 2000). There's almost always an incremental path that's less risky than the total rewrite.

Notice that both mistakes come from the same source: a technology decision made out of emotion or fashion, not constraints. One optimises for an imagined future, the other flees a present that's actually fixable.

Who should decide on a team

The final call is yours, the founder or lead, because you carry the consequences. But how you reach it matters.

Have the person who'll maintain the code defend the choice, and have them defend it against your constraints, not their preferences. "I prefer X" isn't an argument. "We ship faster on X and two of us already know it" is an argument. The difference between those two sentences is exactly the difference between a team decision and a team argument.

The hardest case is when you don't have a trusted technical voice in-house and the stakes are high. Then either the only voice in the room wins because it's the only one, or the loudest one wins because it's the loudest. Neither is a good way to decide something that ties you up for years. This is where an outside second opinion, from someone who has made this decision many times, pulls you out of the trap without taking the control out of your hands. If you're wondering who that someone should be, it's worth understanding the difference between a fractional CTO and a Tech Coach: one runs your engineering, the other helps you decide for yourself.

I don't pick the stack for you. I ask the questions that surface the constraints you hadn't put into words, help you separate the reversible decision from the one that locks you in, and leave you with a choice you can defend. You understand the technology. You make the call.