The Tech Stack BSH Trusts in 2026

Boring technology, chosen on purpose

People often ask what stack we use, hoping for a list of the trendiest tools. The honest answer is that our defaults are deliberately conservative, because the goal is software that runs for years with a small team maintaining it, not a showcase of this month's framework. At BSH Technologies we treat every technology choice as a long-term liability we will have to support, so novelty has to earn its place against the cost of being one of few people who understand it.

That does not mean we are stuck in the past. It means we adopt new tools when they solve a real problem better than what we have, not because a conference talk was persuasive. The question we ask is never is this exciting — it is will we be glad we chose this when we are debugging it in two years.

What we reach for by default

Across most engagements you will find a fairly stable set of choices:

• TypeScript everywhere we can — on the frontend and increasingly on the backend, because a shared language and type system removes a whole category of bugs and makes handovers painless.
• React and Next.js for web interfaces, paired with a sensible component approach so the UI stays consistent and accessible.
• Python for data work, automation, and anything touching AI or retrieval pipelines, where its libraries are unmatched.
• PostgreSQL as the default database, because a well-modelled relational store solves more problems than most teams expect before they reach for something exotic.
• GCP and AWS as our two clouds, chosen per workload rather than by allegiance, with infrastructure defined as code so environments are reproducible.

None of this is exotic, and that is the feature. A new engineer joining a project can be productive quickly because the building blocks are familiar, and a client inheriting the codebase later can hire for it without searching for a unicorn.

Where we deviate, and why

Defaults are a starting point, not a religion. When a client's workload genuinely calls for something else, we use it. A real-time collaboration feature might pull in a different data layer; a heavy analytical workload might justify a specialised warehouse; an AI feature grounded in private documents leads us into vector stores and retrieval frameworks. The discipline is that the deviation has to be justified by the problem and documented so the next person understands the trade-off.

The best stack is the one your team can debug at 3am, not the one that looked clever in the architecture diagram.

We are equally disciplined about what we refuse to add: every dependency is a thing that can break, ship a vulnerability, or get abandoned by its maintainers. Fewer, well-understood pieces beat a sprawling collection of half-used libraries. A dependency added to save an afternoon can cost a fortnight when it goes unmaintained.

How we decide to adopt something new

Because we are cautious by default, we have a rough internal test before a new tool enters our standard kit. It has to clear a few bars: it solves a problem we actually have rather than one we imagine; it has a healthy community and a credible chance of still being maintained in a few years; at least a couple of our engineers can support it, so it is not a single person's pet; and the cost of being wrong is recoverable. We will often trial a new tool on a low-risk corner of a project before letting it near anything critical. This is how a genuinely useful technology graduates from interesting to trusted, and it keeps our stack evolving without lurching from fashion to fashion.

Tooling around the code

The stack is more than the runtime. Our standard setup includes automated testing, continuous integration that runs on every change, linting and formatting that remove style arguments, and monitoring so we learn about problems before clients do. This surrounding tooling is consistent across projects, which is part of how our software-factory approach keeps quality even.

For our managed-services and security work, the toolchain extends into observability, hardening, and continuity — chosen with the same long-horizon mindset, because the systems we look after need to be dependable long after launch. The tools that watch a system in production matter as much as the ones used to build it, and we treat them with the same seriousness.

Choosing for the team that inherits it

There is one more lens we apply to every technology decision, and it is the one most easily forgotten in the moment: someone will inherit this. Sometimes that someone is a future engineer of ours; sometimes it is the client's own in-house team a year from now. Either way, the kindest thing we can do for them is to choose tools that are well documented, widely understood, and unlikely to surprise them. A clever but obscure choice imposes a tax on every person who touches the code after us, and that tax is paid in confusion, slow onboarding, and bugs that take far too long to understand. Conservative, well-supported technology is, in the end, an act of respect for the people who come next — and that respect is a large part of why our defaults look the way they do.

Work with BSH

If you want technology choices made by people who think about the next five years rather than the next demo, that is the kind of judgement BSH Technologies brings to every build. Bring us your project and we will recommend a stack you can actually live with — and explain every part of it.