Every January someone asks me what stack they should build on this year, expecting the answer to have changed. It mostly has not, and that is the point. The stacks that ship products are chosen for hiring pools, operational maturity, and longevity, not for novelty. What changes each year is the temptation list.
The four questions that actually matter
- 1Can you hire for it, here, at your budget? A brilliant niche language with 12 available developers in your market is a bus-factor problem wearing a halo. Check your local job boards before you check the benchmark charts.
- 2Is it boring enough to run at 3am? Ten-plus years of production history means the failure modes are documented and the answers are searchable. Your on-call engineer will thank you.
- 3Will it still be maintained in 8 years? Custom software lives far longer than anyone plans. Favour technology with multiple major backers and a decade of momentum.
- 4Does it fit the problem, or the resume? Be honest about which one is driving the shortlist. Resume-driven choices are the most expensive line item nobody puts in the budget.
What we build with, and why
Our defaults are deliberately unexciting. TypeScript across the stack, because one language for frontend and backend halves the context-switching and widens every hire. PostgreSQL for almost everything, because it does relational, JSON, full-text search, and queueing well enough that most projects never need a second datastore. Managed cloud services over self-hosted, because a mid-size team’s scarcest resource is attention.
| Layer | Our default | The reason |
|---|---|---|
| Language | TypeScript end to end | One hiring pool, shared types, huge ecosystem |
| Backend | Node.js with a proven framework | Mature, fast enough, easy to staff |
| Frontend | React | Largest talent pool, longest support horizon |
| Database | PostgreSQL | Handles 95% of workloads, decades of production history |
| Infrastructure | Managed containers, infrastructure as code | Small ops surface, reproducible environments |
| AI features | Hosted model APIs first | Ship in weeks, own fine-tuning only when data proves the need |
None of these are sacred. A data-heavy pipeline may earn Python. A high-throughput ingestion service may earn Go. The defaults exist so that every deviation is a conscious trade, argued for in writing, rather than a preference smuggled in during setup week.
The 2026 temptations, sorted
AI coding tools are the real shift of the past two years, and they quietly strengthen the case for mainstream stacks: the tools are dramatically better in ecosystems with abundant training data. TypeScript and Python get the best assistance. Your niche language gets autocomplete and hallucinations.
- LLM features: genuinely useful, now table stakes in several categories. Start with hosted APIs behind your own abstraction so you can swap providers as pricing moves.
- Edge runtimes: great for content-heavy global products. Unnecessary complexity for a B2B app whose users live in two time zones.
- Microservice-first platforms: still premature for most mid-size teams. We wrote up the full trade-off in monolith or microservices.
- Exotic databases: reach for one when PostgreSQL measurably fails at your workload, not when a benchmark blog says it might.
Deciding as a team, once
Write the decision down. A one-page architecture decision record per major choice: the options considered, the trade-offs, the reason for the pick. It takes an hour and saves the same debate from being re-litigated every time a new engineer joins. Revisit the records annually, not every sprint.
The stack we chose for our own product, fluxems, follows exactly this playbook, and it has carried the platform from prototype to daily use on live construction projects without a rewrite. If you are starting a build and want a second opinion on your shortlist, our custom software team will give you a straight answer, including "your current plan is fine."