How to Choose a Software Development Partner

In Norway, every company that is required to file annual accounts sends them to the Register of Company Accounts in Brønnøysund. The accounts are public, and anyone can download them free of charge.¹ Brønnøysundregistrene itself describes them as an important tool for anyone who wants to get to know a potential contract partner. That means one of the most useful checks on a software vendor, whether it is financially sound and heading in the right direction, is available to every buyer before the first meeting.

Most of the rest of the decision can be checked too, if you do things in the right order. This guide sets out that order. First, define the problem. Then choose how you will buy. Then find vendors, verify them, test how they work, and settle ownership and data protection before anything is signed. The method works in any market. The worked examples throughout, including registers, standard contracts and regulators, come from Norway.

Free to reuse under CC BY 4.0 with a link to this article. Download

Summary

• Define the outcome, the constraints and what you need to own before you talk to vendors. A vague brief invites each vendor to fill the gaps with its own preferences, and the proposals you get back will not be comparable.
• Choose the contract model early, because it decides who carries which risk. Public standard contracts make a good reference for balanced terms. Norway's state standard agreements for IT (the SSAs) are free and public.²
• Verify vendors in public registers: in Norway, Enhetsregisteret for status and roles, and the Register of Company Accounts for financials.
• Treat certifications, case studies and reviews as claims to check, not as evidence in themselves.
• If the vendor will process personal data for you, you need a data processing agreement, and it is your job to choose a processor that offers sufficient guarantees.³⁴
• Agree who owns the code, the data and the documentation, and how you would leave, before you sign.

Start with the problem, not the vendor

The most expensive mistakes in software projects are usually made before any vendor is involved, when the buyer has not decided what success looks like. Before you contact anyone, write down:

• The outcome. What should be different once the software is in use, and for whom? "Customers can book and pay without calling us" is an outcome. "A new booking portal" is a solution.
• The constraints. Deadlines that genuinely cannot move, a budget range, systems it must integrate with, and regulatory requirements (personal data, sector rules, accessibility).
• What exists today. Current systems, data, and who uses them. Vendors will price the unknowns, so fewer unknowns means more comparable proposals.
• What you must own. The source code, the data, the domain and the cloud accounts. Decide this now, not in the contract negotiation (see Ownership, handover and exit).

Then ask whether you need custom development at all. The guidance from the Norwegian Agency for Public and Financial Management (DFØ) on choosing an SSA is written for public buyers, but it is organised around a question every buyer should ask. Are you buying standard software you set up yourself, a standard system delivered as a service, a standard system that must be adapted, or something built specifically for you?⁵ Each answer leads to a different kind of vendor, and to a different contract.

Decide how you will buy before you decide who

The contract model decides who carries the risk if the scope turns out to be wrong. That is why it should come before the vendor, not after.

Fixed scope or agile

DFØ's descriptions of its two main development agreements make the trade-off unusually clear:

• Under SSA-T (the development and adaptation agreement), the supplier has the main responsibility for making sure the solution meets the requirements specification and for keeping to the timetable in its bid. DFØ notes that this reduces the risk of cost overruns.⁵ The agreement also includes a phase in which supplier and customer work together to specify the delivery in detail.⁶
• Under SSA-S (the agile agreement), the customer must take an active part in every phase, and the customer has the main responsibility for progress.⁵

Free to reuse under CC BY 4.0 with a link to this article. Download

Buying capacity rather than a delivery

Sometimes you do not want a vendor to deliver a defined system. You want experienced people to work inside your own team. The SSAs separate these cases too. SSA-B covers consultancy assistance, where you specify the competence and the amount of help you need. SSA-O covers assignments where the customer has specified what is to be delivered and the consultant takes independent responsibility for it.² The difference matters when something goes wrong: under assistance, the outcome stays your responsibility.

Use a public standard contract as a reference

Norway's SSAs are a useful example wherever you are buying. They are published openly by DFØ and can be downloaded free, and SSA-T is also available in English, updated in 2026.⁶ Even if you sign on a vendor's own terms, it is worth comparing their contract with the relevant SSA to see what is missing.

Source: DFØ, Statens standardavtaler (SSA) and Velge SSA for IT-kjøp.²⁵

One detail from DFØ's guidance deserves attention on its own. It advises buying maintenance at the same time as the system, because often only the supplier of a system can maintain it.⁵ Once the system is live, your bargaining position on maintenance is much weaker.

Build a longlist from evidence

Five to eight candidates is enough for a longlist, and three is enough for a shortlist. Where the names come from matters more than how many there are.

• Peers who have shipped with the vendor. Ask what went wrong and how the vendor handled it, not only whether they were happy.
• Case studies that name the client. A named client can be contacted. "A leading Nordic bank" cannot.
• Public procurement. Public buyers announce procurements on Doffin, the national notice database for public procurement.⁷ If you are buying something similar to what the public sector buys, the notices show which vendors compete in that field.
• Public technical work. Maintained open-source repositories, engineering writing and conference talks show how a team thinks. They are harder to fake than a sales deck.
• Third-party review platforms. Useful for finding names, but weak evidence on their own (see Reviews).

Industry rankings and directories can help with discovery. Read their methodology before relying on the order. If a ranking does not explain how it was compiled, or whether placement can be paid for, treat it as advertising.

Check the basics in the public registers

This takes little effort, and it rules out candidates before you invest time in them. Start with the company register in the country where the vendor is registered. In Norway, that means two registers run by Brønnøysundregistrene.

Enhetsregisteret

Look up each candidate in Brønnøysundregistrene's company information service.⁸ Check:

• that the organisation number matches the one on the proposal and in the contract
• the registered business activity, and whether it matches what the vendor says it does
• the roles: who is general manager and who sits on the board, so you know who you are dealing with
• whether there are any bankruptcy, liquidation or compulsory dissolution entries

The Register of Company Accounts

The same service gives free access to filed annual accounts.¹ For a software vendor, look at three years if they exist:

• Revenue trend. Growth, stability or decline, and whether a sudden change needs explaining.
• Operating result. A vendor that loses money on every project may be underpricing, which tends to show up later as pressure on scope or staffing.
• Equity. Low or negative equity is a reason to ask questions, especially for a long engagement.
• Headcount. The notes to the accounts often state the average number of full-time equivalents. Compare it with the size of team the vendor is proposing.

Two caveats. First, the filing deadline is 31 July,¹ so in the first half of the year the latest accounts on file may be well over a year old. Ask for more recent management figures if timing matters. Second, not every kind of entity has to file accounts, and some vendors sit inside larger groups. If the accounts are missing, or the contracting entity is a thinly capitalised subsidiary, ask why and consider whether a parent company guarantee is needed.

Verify claims rather than collecting them

Free to reuse under CC BY 4.0 with a link to this article. Download

Case studies and references

Ask each shortlisted vendor for two references from projects similar to yours in size and type, and ideally delivered by the people who would work on your project. When you call:

• What was delivered, compared with what was agreed?
• What went wrong, and what did the vendor do about it?
• How were changes in scope handled and priced?
• Is the system still in use, and who maintains it now?
• Would they hire the same team again?

Certifications and partner status

Ask for the certificate itself, not a logo. For accredited management-system certifications such as ISO/IEC 27001, check validity in IAF CertSearch, which describes itself as the official global database for accredited certificates.⁹ If a certificate is not listed there, confirm it with the certification body named on it. Then read the scope statement. A certificate covers a defined scope, which may be one office or one service, and not necessarily the service you are buying.

Cloud and platform partner tiers (AWS, Microsoft, Google Cloud, Shopify and others) can be checked in each platform's own partner directory. The vendor's website is not enough.

Reviews

Reviews on third-party platforms are better than testimonials on a vendor's own site, but they are still weak evidence. Look at how many there are, how they are spread over time, and how specific they are. Twenty detailed reviews over five years say more than five enthusiastic reviews in one month.

Test how they work before you commit

A proposal shows how a vendor sells. You also need to see how it works.

• Meet the people who will do the work. Ask for the names and roles of the team, and how much of their time your project will get. Put those names in the contract, along with what happens if someone is replaced.
• Start with a small, paid first phase. A short discovery or specification phase with a clear deliverable is the cheapest way to see a vendor's work before committing to a large contract. SSA-T includes a phase of this kind, in which supplier and customer detail the delivery together.⁶
• Ask technical questions and expect specific answers:
  • How is code reviewed and tested before it reaches production?
  • How are deployments made, and how often?
  • Who has access to production systems and data, and how is that access controlled and logged?
  • How are vulnerable dependencies found and updated?
  • How is progress reported, and how are estimates revised?
  • What documentation will we receive, and when?
• Ask to see real work. Many vendors cannot show client code, but they can show open-source projects, anonymised architecture documents or a technical walkthrough of a past system.

Data protection and security belong in the selection

If the vendor will process personal data on your behalf, for example by hosting or operating the system or by having access to production data for support, you are the controller and the vendor is a processor. Datatilsynet's guidance is explicit: the relationship between a controller and a processor must be governed by a data processing agreement, and GDPR Article 28 sets out what it must contain.³ The GDPR applies across the EU and the EEA. In Norway, it applies through the Personal Data Act (personopplysningsloven).¹⁰

Article 28 also places a duty on you at the selection stage. A controller may use only processors that provide sufficient guarantees that they will implement appropriate technical and organisational measures.⁴ That makes the vendor's security practice part of the selection, not a contract appendix to sort out later.

In practice:

• Ask for the vendor's standard data processing agreement early. DFØ publishes a data processing agreement template and a checklist, and the checklist can be used to review a supplier's standard agreement.²
• Ask for the list of sub-processors: cloud providers, monitoring, email, error tracking and support tools. Under Article 28, a processor may not engage another processor without the controller's prior written authorisation.⁴
• Ask where personal data will be stored and processed, including by sub-processors. Transfers outside the EEA are subject to separate rules, and Datatilsynet has guidance on them.¹¹
• Ask how the vendor builds privacy in. Datatilsynet has published guidance on software development with privacy built in, developed together with security specialists and developers from the private and public sectors.¹² A vendor that has never read it is telling you something.

Ownership, handover and exit

Most disputes at the end of a software relationship are about things that were never written down at the start. Agree these points before signing:

• Source code. Code lives in repositories that you own, or that you can access at any time, from the first day. Not delivered at the end, and not held by the vendor as leverage.
• Accounts and infrastructure. Cloud accounts, domains, app store listings and third-party services are registered to your organisation, with the vendor given access, not the other way round.
• Rights. Who owns what is built for you. What licences apply to the vendor's reusable components and to open-source dependencies. DFØ has published a separate guide on rights to data under the SSAs, which is useful background for this conversation.²
• Documentation. What is documented, to what standard, and when you receive it.
• Maintenance. Agreed at the same time as the development contract, as DFØ recommends,⁵ with response times and prices.
• Exit. What help and documentation you are entitled to if you move to another supplier. SSA-D's approach to ending an operations service, which covers assistance, documentation and transfer to a new provider, is a good model even for development contracts.⁵

Compare proposals like for like

Proposals are only comparable if they answer the same questions. Ask every vendor to respond to the same structure, then compare:

Before you sign

• Outcome, constraints and ownership requirements written down
• Contract model chosen, and compared with the relevant SSA
• Organisation number, status and roles checked in Enhetsregisteret
• Latest annual accounts read (revenue, result, equity, headcount)
• Two references called
• Certificates and partner tiers checked with the issuer, including scope
• The team named in the contract
• Data processing agreement reviewed, with sub-processors and data location confirmed
• Code repositories, accounts and domains registered to your organisation
• Maintenance agreed alongside development
• Exit and handover terms agreed

What this guide does not cover

This guide does not cover what software costs, which depends on too many variables to handle properly here, or the procurement law that public-sector buyers must follow. In Norway, DFØ's anskaffelser.no is the authoritative source for the latter. It does not recommend specific vendors either.

Frequently asked questions

How can I check whether a Norwegian software company is financially stable?

Look it up in Brønnøysundregistrene. Enhetsregisteret shows its registration details and roles. Annual accounts filed with the Register of Company Accounts are public and can be downloaded free, so you can read revenue, operating result and equity for several years before you shortlist a vendor.

Can private companies use Norway's state standard agreements (SSA)?

The SSAs are written for public-sector IT purchasing, but DFØ publishes them openly, and SSA-T is also available in English. Even if you use a different contract, they are a useful reference for what balanced terms on responsibility, maintenance and exit look like.

Do I need a data processing agreement with my software vendor?

Yes, if the vendor processes personal data on your behalf, for example by hosting or operating the system or by having access to production data. GDPR Article 28 requires the relationship to be governed by a contract, and Datatilsynet has published guidance on what it must contain.

Should I choose a fixed-price or an agile contract?

It depends on how precisely you can describe what you need and how much of your own time you can commit. In DFØ's description, SSA-T places the main responsibility for meeting the requirements and the timeline on the supplier, while SSA-S expects the customer to take part in every phase and carry the main responsibility for progress.

How do I verify a vendor's ISO/IEC 27001 certificate?

Ask for the certificate, then check it in IAF CertSearch or with the certification body named on it. Read the scope statement too: a certificate covers a defined scope, which may not include the service you are buying.

Sources

1. Brønnøysundregistrene, "Om Regnskapsregisteret", last updated 12 September 2025. https://www.brreg.no/om-oss/registrene-vare/om-regnskapsregisteret/ ↩ ↩² ↩³

2. DFØ, "Statens standardavtaler (SSA)". https://www.anskaffelser.no/avtaler-og-regelverk/statens-standardavtaler-ssa ↩ ↩² ↩³ ↩⁴ ↩⁵

3. Datatilsynet, "Databehandleravtale", last changed 27 July 2023. https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/hvordan-lage-en-databehandleravtale/ ↩ ↩²

4. Regulation (EU) 2016/679 (General Data Protection Regulation), Article 28. https://eur-lex.europa.eu/eli/reg/2016/679/oj ↩ ↩² ↩³

5. DFØ, "Velge SSA for IT-kjøp", last updated 4 December 2025. https://www.anskaffelser.no/avtaler-og-regelverk/statens-standardavtaler-ssa/velge-ssa-it-kjop ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷

6. DFØ, "SSA-T (Utviklings- og tilpasningsavtalen)". https://www.anskaffelser.no/verktoy/mal/ssa-t-utviklings-og-tilpasningsavtalen ↩ ↩² ↩³

7. Doffin, the national notice database for public procurement. https://www.doffin.no/ ↩

8. Brønnøysundregistrene, Virksomhetsopplysninger (company information search). https://virksomhet.brreg.no/nb/oppslag/enheter ↩

9. IAF CertSearch. https://www.iafcertsearch.org/ ↩

10. Lov om behandling av personopplysninger (personopplysningsloven), LOV-2018-06-15-38. https://lovdata.no/dokument/NL/lov/2018-06-15-38 ↩

11. Datatilsynet, "Overføring av personopplysninger ut av EØS". https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/overforing-av-personopplysninger-ut-av-eos/ ↩

12. Datatilsynet, "Programvareutvikling med innebygd personvern". https://www.datatilsynet.no/rettigheter-og-plikter/virksomhetenes-plikter/programvareutvikling-med-innebygd-personvern/ ↩