Choosing a software development partner in Switzerland
Seven criteria that separate a supplier from a partner for Swiss tech companies: DACH experience, technical depth, compliance posture, and how exit is handled.
Selecting a development partner is usually run as a procurement exercise, scored on rate card, certifications and reference count. Those three predict very little about how the engagement actually goes.
What predicts it is a different set of questions, most of which do not appear in a standard RFP.
Why Swiss companies look outside in the first place
Worth being clear about the motive, because it should shape the criteria.
For most Swiss SMEs it is not cost. It is that the profiles needed — cloud architecture, data engineering, MLOps — are scarce locally, slow to hire, and often needed for a defined period rather than permanently. Creating a permanent role for a temporary need is expensive in both directions.
If cost is the motive, be honest about it internally, because it leads to different trade-offs and a different kind of relationship.
Seven criteria that actually predict the outcome
1. Experience in the Swiss or DACH context
Not “has European clients”. Specifically: has the partner worked under revDSG, GDPR, or FINMA outsourcing expectations, and can they describe what changed in their delivery because of it?
A partner who has only ever delivered into unregulated markets will treat compliance as your problem, which is technically true and practically unworkable.
How to test it: ask what they do differently for a client with Swiss data-residency requirements. A vague answer is the answer.
2. Technical depth, demonstrated rather than claimed
Certifications indicate exposure, not capability. What indicates capability is the ability to discuss a failure.
How to test it: ask them to describe a project that went badly and what they changed afterwards. A partner with no such story either has not done enough work or is not being straight with you — and both are disqualifying.
3. Compliance and data security, at the level of access
The question most often asked is where data is stored. The question that matters is who can reach it.
Specifically: which of their staff, in which countries, under what controls? Which sub-processors sit behind them? What happens to your data and their access when the contract ends?
Storage location appears in marketing material. Access control appears in the contract, or it does not exist. This distinction is covered further in cloud vs on-premises: what makes sense for SMEs.
4. Communication, tested before signature
Most engagements that go wrong go wrong here rather than technically.
What to look for: do they ask questions that reveal they understood the problem, or do they reflect your brief back at you? Does the person in the sales conversation appear again afterwards? How do they behave when they disagree with you — during the sales process, when they have every incentive to agree?
A useful signal: a partner who pushes back on part of your brief before signing is more likely to tell you the truth afterwards.
5. Named people, not a pool
This is the single strongest predictor of quality in this market, and the one procurement processes are worst at capturing.
A named team accumulates knowledge of your systems. A pool resets it with every rotation, and you pay the specification cost again each time. Ask who specifically will work on this, whether they are available, and what happens if one of them leaves.
The maturity dynamics behind this are set out in building a global capability centre to Swiss standards.
6. Knowledge transfer built in, or dependency by design
Some partners are structurally incentivised for you not to understand your own system. It is rarely deliberate and it is easy to detect.
How to test it: ask what documentation you receive, who holds the deployment credentials, and what would need to happen for your own team to take the system over. A partner comfortable with that question is a different proposition from one who deflects it.
7. Contracting party and exit
Two structural questions that decide how bad a bad outcome can get.
Who contracts? If accountability sits in a different jurisdiction from the obligation, enforcement is theoretical. A Swiss contracting party for a Swiss obligation is worth a great deal.
What does exit look like? Code ownership, data export, credential handover, a notice period that lets you actually transition. For FINMA-supervised clients a documented exit is a requirement rather than a precaution.
What to weight less than you probably do
- Headcount. A large supplier means capacity exists somewhere, not that it is assigned to you.
- Reference count. Three relevant references beat thirty irrelevant ones. Ask for the ones closest to your situation, and ask them what went wrong.
- Rate card. Rate is not cost. Cost is rate multiplied by the time taken, plus the coordination overhead you absorb.
A short evaluation sequence
- Write down what you actually need and for how long — permanent capability or defined work
- Ask the access and exit questions before the technical deep-dive; they are disqualifying and quick
- Meet the named people who would do the work
- Start with something small and real, rather than the largest item on the roadmap
- Agree what handover looks like before it is needed
Step 4 is worth insisting on. A first engagement with a defined end tells you more than any procurement process, and it costs less than discovering the same thing on the main programme.
Related reading
- Maximising engineering ROI: the CFO’s guide
- Dedicated engineering teams
- Palisis and Zeus Bioscience — the two European engagements we would put forward first
If you are running a selection and want a second opinion on the shortlist, book a call. No obligation.