Choosing a tech stack is one of the few technical decisions a non-technical founder is forced to make early, usually under pressure, usually based on whoever they hired first telling them what they like. That's a bad process, because the person who benefits most from an exotic, cutting-edge stack is the developer building it, not the business that has to run it for the next five years.
I've inherited enough of these situations to know the pattern. A founder hires an enthusiastic engineer, that engineer picks a framework they personally enjoy or want on their resume, and eighteen months later the founder can't hire anyone else who knows it, can't get a second opinion on a bug, and is functionally hostage to one person. This isn't a story about bad developers. It's a story about a decision the founder wasn't equipped to evaluate and delegated entirely.
You don't need to understand the technical merits of one framework over another to make a good decision here. You need three proxies that any founder can judge without writing a line of code.
You can't judge frameworks, but you can judge proxies
Nobody expects a founder to have an opinion on the internal architecture of a web framework, and if a developer is trying to get you excited about the technical elegance of their choice, that's a signal to slow down, not speed up.
What you can judge, reliably, without technical background:
- How many local developers know it. Ask a recruiter, or just check job listings in your city. If almost nobody in your hiring market lists it as a skill, you will pay a premium for every hire, forever, and you will have a very short list of people to call when something breaks.
- How old and boring is it. A framework that's been stable for five-plus years has had its worst bugs found and fixed by someone else's money, not yours. Newness is a cost you pay, not a feature you get.
- Who else runs it at a scale near yours. Not a shining example. Businesses roughly your size, in your industry or adjacent, quietly running the same stack for years without drama. Boring success stories, not conference talk case studies.
If a proposed stack fails all three, that's not necessarily wrong, but it means you're taking on technical risk you should at least be told about explicitly, not risk that gets buried inside "we're using modern best practices."
The one-developer trap
The single most expensive mistake I see is a founder greenlighting a stack chosen by one enthusiastic developer without asking who else could pick this up if that person left tomorrow. It always feels unnecessary to ask this in month one, when the relationship is great and the developer is clearly talented. It becomes the only question that matters in month eighteen, when that developer gets a better offer and takes the only working knowledge of your system with them.
This is directly connected to the choice between build vs buy: an exotic custom stack built by one person is effectively a "build" decision you didn't realize you were making, with all the maintenance risk of a bespoke system and none of the vendor support a bought product would give you.
Ask, before any stack decision is finalized: "If this person is gone in six months, how hard is it to find a replacement, and how long would it take them to get productive?" If the honest answer is "very hard" and "a long time," you need a very good reason to accept that risk, not just enthusiasm.
The questions that protect you
Run these before signing off on any stack decision, your own or a contractor's:
- Is this stack used by companies our size, doing roughly what we do? Not FAANG-scale reference architecture. Your scale.
- How many developers in our hiring market (or remote-friendly market) already know this? Ask a recruiter for a real number, not a guess.
- What happens when the current developer leaves? Get a specific answer, not reassurance.
- Is there a boring, older alternative that does 90% of the same job? If yes, what's the actual reason we're not using it?
- Who is the vendor or community keeping this alive, and are they still actively maintaining it two years from now? Check the project's actual activity, not its marketing.
None of these require you to understand code. All of them require you to insist on a real answer instead of accepting "trust me."
Boring is a business strategy, not a compromise
Founders sometimes worry that choosing an older, more common stack signals a lack of ambition or technical sophistication. It's the opposite. The businesses that scale well treat their tech stack the same way they treat their accounting software: reliable, well-understood, replaceable if needed, invisible when it's working. The hidden cost of legacy systems is real, but that's a different failure, systems that were never maintained, not systems that were merely unexciting when chosen.
The businesses I've seen get burned chose excitement over reliability at the foundation layer and paid for it in hiring difficulty, bus-factor risk, and slow bug fixes for years afterward. The businesses that scaled smoothly made a boring choice early and spent their actual innovation energy on the product, not the plumbing.
The takeaway
You will never be equipped to judge a framework on its technical merits, and that's fine, it's not your job. What is your job is asking whether other businesses like yours run this stack successfully, whether you can hire for it locally, and what happens the day your current developer leaves. Get honest answers to those three questions before any stack decision gets locked in, and if you want a second opinion on a proposal already on your desk, that's exactly the kind of conversation worth having at /partner.