Choosing a technology stack for a Swiss SaaS product

Stack decisions are made in a week and lived with for a decade. That asymmetry is the whole problem, and most selection processes do not reflect it.

The question is not which technology is best. It is which one you can still hire for, afford and change three years from now.

Three criteria that outrank the technical comparison

Can you hire for it in Switzerland? A stack with a small local talent pool means every hire is slower and more expensive, in a market where hiring is already the binding constraint. This weighs more heavily here than in larger markets — a preference that is defensible in a large European tech hub can be a serious limitation in the Swiss market.

What does it cost to run at ten times current load? Some architectures scale linearly in cost, some do not. The difference does not show at prototype scale and dominates by year three.

How hard is it to leave? Every stack creates some lock-in. The question is whether it is at the level of a library (weeks to replace) or a data model (a rewrite).

If a technology wins on benchmarks and loses on all three of these, it loses.

The components, and what actually matters in each

Languages and frameworks

For most Swiss SaaS products the honest answer is that the mainstream choices are all adequate, and the differentiator is the ecosystem around them rather than the language.

What to weigh:

• Hiring pool locally — the strongest criterion, and the most often ignored in favour of technical preference
• Library maturity for your domain — payments, document handling, whatever your product actually does
• Long-term support — how long does a version stay supported, and what does upgrading cost?

What to weigh less: performance benchmarks. Very few SaaS products are limited by language execution speed; they are limited by database design and network calls.

Backend-as-a-service

Managed backends genuinely accelerate the first six months. The trade-off appears later and in a predictable place.

Use it when: you are validating a product, the team is small, and the data model is simple.

Be careful when: your data is subject to revDSG or GDPR constraints and the service processes outside a jurisdiction you can accept, or when your access patterns become unusual — at which point you are working around the platform rather than with it.

The question to ask early: if we had to leave this service, what would we be rewriting — the integration layer, or the data model? The first is a project; the second is a rebuild.

Low-code platforms

Low-code has a real and narrow place: internal tools, admin interfaces, workflows that change often and are used by few people.

Where it goes wrong is the customer-facing product. The first 80% is fast, the last 20% is where the platform’s assumptions and your requirements diverge, and the escape hatch is usually a rewrite in the stack you skipped.

A workable rule: low-code for what supports the product, conventional code for the product itself.

Open source

Open source is the default for most components and it is not free. The costs are real and manageable if they are acknowledged:

• Maintenance. Somebody has to track versions and security advisories. If nobody owns it, you will discover the gap during an incident.
• Licences. Copyleft terms matter for a commercial SaaS product. This is a legal review, not a developer preference, and it is much cheaper before adoption.
• Project health. Commit frequency, maintainer count, release cadence. A dependency maintained by one person is a risk with a name.

Swiss-specific constraints

Three that change the shortlist rather than just adding work.

Data residency and access. Under revDSG/nDSG and GDPR, you need to know where data sits and who can reach it. This constrains managed services more than self-hosted components, and it is decided by the architecture rather than by configuration. Settle it before choosing, not after.

Customer procurement questions. If you sell into Swiss or German enterprises, expect questions on sub-processors, data location, exit paths and certifications. A stack built on a long chain of third-party services makes those questions harder to answer, and a slow procurement answer costs deals.

Currency and cost predictability. Usage-priced services introduce variability into a cost base that a Swiss CFO would prefer to forecast. Not a blocker, but it deserves a deliberate answer rather than a surprise.

A decision sequence that works

1. Write down the constraints first — data residency, hiring reality, expected scale, exit requirements
2. Eliminate anything that fails a constraint. This usually removes more options than the technical comparison would.
3. Compare what remains on ecosystem and hiring, not on benchmarks
4. Prototype the riskiest integration, not the easiest feature
5. Write down what would make you change the decision, and revisit at that point

Step 5 is rarely done and is the one that makes the decision reversible. A stack choice recorded with its assumptions can be re-examined when the assumptions change; one recorded as a conclusion becomes permanent by default.

Related reading

• Outgrowing off-the-shelf software: a build-vs-buy guide
• How Swiss startups can scale tech teams without delay
• Software engineering

If you are making this decision and want it pressure-tested, book a call. No obligation.