The Hiring-Constraint Principle
Pick technologies your future self can hire for. The hiring lens is a real engineering concern.
The Hiring-Constraint Principle
In one line: Pick technologies your future self can hire for — the hiring lens is a real engineering concern, not just a recruiting one.
Some technologies are easier to hire for than others. This compounds: hiring for a niche tech is harder, so candidates are scarcer, so you compete harder, so they're more expensive — and once hired, they leave more easily because demand is so high. The cost of "I picked Elixir because I love it" can be a permanent two-person engineering team.
Some technologies are easier to hire for than others. This compounds: hiring for a niche tech is harder, so candidates are scarcer, so you compete harder, so they're more expensive — and once hired, they leave more easily because demand is so high.
Hiring difficulty (rough 2026 estimates)
| Technology | Hiring difficulty |
|---|---|
| TypeScript / React | Easy (huge pool) |
| Python | Easy |
| Go | Moderate |
| Vue | Moderate (esp. US) |
| Rust | Harder |
| Elixir, Clojure | Hard |
| OCaml, Haskell | Very hard |
| Custom internal tools | Impossible |
The hiring lens is a real engineering concern, not just a recruiting one.
The counter
Sometimes a niche technology is the right choice — it lets you punch above your weight, attract passionate engineers, or solve specific problems better. Just know the trade-off.
Worth it: A 6-person startup uses Elixir/Phoenix because real-time messaging is their product and BEAM's actor model genuinely fits. They struggle to hire mid-level engineers, but the small pool of senior Elixir engineers is fanatically loyal. They make the trade work because the tech is core to their differentiator.
Not worth it: A B2B SaaS picks Haskell for the backend "because correctness." Two years in, they have one engineer who actually knows it well, three who can mostly work around it, and recruiting is a constant grind. The product would have worked just as well in TypeScript or Go, and they would have had three times the candidate pool. The decision becomes the most expensive item in their tech roadmap — not in dollars, but in velocity.
The lesson: niche tech is justifiable when it's central to your moat. It's a tax otherwise.
A single hire being twice as hard isn't 2x cost — it's worse:
- Slower fills → projects stall waiting for headcount.
- Higher comp → salary expectations compound across the team.
- Higher attrition → niche-skill engineers get poached more easily.
- Smaller pool → harder to diversify, harder to fill leadership roles.
- Less competitive offers from people who could leave to other niche-tech employers.
If you can't articulate a specific reason the niche tech is worth all of that, it isn't.
Common mistakes
- Treating "the team already knows it" as the whole answer. Today's six engineers know Elixir. The seventh hire and the manager you'll need to recruit next year don't. The hiring constraint is about who you'll need, not who you have — discount the current team's preference accordingly.
- Assuming AI-assisted coding erases the talent-pool gap. AI helps engineers move into unfamiliar languages faster, but the senior engineers who can debug a production incident at 2 a.m. in Haskell still have to exist somewhere. Niche-language seniority is still scarce regardless of how good the tooling gets.
- Picking the niche tech and then trying to justify it. Engineers fall in love with the tool first and reach for "but it'll attract passionate engineers" as the post-hoc reason. If your moat-related justification existed before the engineer's enthusiasm, fine. If it appeared after, you're rationalizing.
- Ignoring the hiring lens for internal tools. Custom internal frameworks ("our own auth abstraction," "our own ORM") have a hiring pool of zero — every new engineer pays the onboarding tax. That cost is invisible at five engineers and crippling at fifty. Internal tools are the most extreme version of the hiring constraint.
Page checkpoint
Did the hiring constraint stick?
RequiredWhat's next
→ Continue to A Decision-Making Checklist — ten questions to run through on any significant decision.