Should the source code be mine?

Yes, and the contract should say so explicitly, along with the form of handover and the documentation. Without that clause you aren't buying software: you're renting access to it, with the supplier as your only way out.

Are ISO certifications really relevant for an SME?

They're relevant whenever the supplier handles your customers' or employees' data. A certification doesn't guarantee nothing will go wrong: it guarantees that documented procedures exist, verified by an external body, and that an incident meets a defined process rather than improvisation.

How do I tell whether a software house is too big or too small for me?

Look at who would actually work on your project, not the headcount. In a large firm the risk is being a minor project in a queue; in a small one it's dependence on one or two people. In both cases the useful question is the same: who answers when something breaks?

Updated September 2026

Guide

How to choose a software house: criteria, questions and contract

Choosing a software house comes down to five things, in this order: whether they have already solved a problem like yours, who your technical contact will be and what language they speak, how data security and compliance are handled, what the contract says about code ownership and service levels, and how you get out if it doesn't work. Price is the last criterion, not the first: a low quote built on vague requirements is the most common way to spend twice.

Talk to an expert

The evaluation criteria

Experience with the problem, not the technology

Ask for a project where they tackled a process like yours. The stack matters less than it seems; understanding your domain matters far more.

Who your contact is, and where they sit

A technical point of contact who speaks your language and knows the project changes day-to-day delivery more than any stated methodology.

Team composition

Check whether functional analysis, development and QA are distinct roles or the same person. Neither is wrong: it changes the risk, and the risk should be known up front.

Security and data handling

The most frequently forgotten criterion, and the most expensive one when it's missing. Ask how the data you hand over is protected, not whether it is.

How they work after go-live

A software project doesn't end at release: ask how corrective and evolutionary maintenance are handled, and with what response times.

Transparency about the estimate

Anyone who gives you a firm price without having looked at your processes is selling you a bet, not a project.

The questions to ask before signing

Eight questions that separate a prepared supplier from one who improvises. How readily the answers come matters more than the answers themselves.

Who will my technical contact be, and how many hours a week do they spend on my project?
Is the source code mine? In what form do you hand it over, and with what documentation?
What infrastructure does my data run on, and where does it physically reside?
Who on your team can access production data, and how is that access logged?
What happens if the project stops halfway? What do I keep?
How do you handle change requests mid-flight, and how do they affect timeline and budget?
What response times do you guarantee for a production outage?
Can I speak to a client of yours with a project like mine?

Contract, SLA and code ownership

Also read closely: the boundary between maintenance and new development, the data processing agreement under GDPR art. 28, ownership of third-party components, and renewal terms. A contract that never mentions code ownership hasn't left something out — it has already answered.

Source code ownership

It should be yours, with documented handover rather than read access. This is the clause that decides whether you can change supplier without starting over.

Explicit service levels

Separate response times for blocking bugs, non-blocking bugs and enhancements. An SLA that doesn't distinguish severity isn't an SLA.

Exit terms

Return of data and artefacts in a reusable format, within defined timescales. Negotiate this at the start, while the relationship is good — not at the end.

Security and certifications as a selection criterion

Certifications aren't a badge for the window: they are evidence that a documented process exists and has been verified by an external body. When you hand a supplier your customers' or employees' data, that process is the difference between a promise and a verifiable obligation.

Our certifications

ISO/IEC 27001

Is there an information security management system, with risk analysis, documented controls and periodic audits?

ISO 9001

Is process quality managed and measured, or does it depend on individuals?

ISO/IEC 27017 and ISO/IEC 27018

If the project lives in the cloud, are cloud-specific controls and the protection of personal data processed as a processor both covered?

GDPR compliance

Who is controller and who is processor, how long is data retained, and what happens when the relationship ends?

Access and environments

Are development, test and production separate environments? Is access assigned by role and revocable?

Frequently asked questions

It matters, but it's the last thing to look at. A low quote built on vague requirements almost always turns into mid-project change orders: the final cost rises, and you've lost months in the meantime. Only compare quotes once every supplier is pricing the same requirements.