High delivery costs force a different kind of scoping in Oslo
Norwegian salary levels are among the highest anywhere, and everything about how software gets bought here follows from that. Nobody staffs a large team to explore a vague idea. Scope is cut hard before work begins, the first release is deliberately small, and features are justified individually rather than accepted as a package. Buyers arriving from cheaper markets often read this as a lack of ambition. It is the opposite: when an hour of engineering is expensive, deciding what not to build becomes the most valuable part of the process.
Use that to your advantage when briefing. Ask each candidate what it would remove from your requirement list and why, and treat a firm that agrees to everything as a warning rather than a convenience. Ask which parts of the software genuinely need building and which are configuration of something that already exists, because integrating a proven service is frequently the correct answer here where in a lower cost market a bespoke build would win on price.
National digital infrastructure you will have to integrate with
This is the most underestimated part of building software for the Norwegian market, and it is where local suppliers are worth their rate. Identity is handled through the national electronic identification scheme rather than through passwords you invent, which means onboarding, consent and signing flows are constrained by how that scheme works. Consumer payment expectations are set by the dominant mobile payment service, and a checkout that ignores it will underperform regardless of how well it is built. Reporting to public authorities runs through a shared government portal, and business data comes from public registries that have their own interfaces and rules.
Ask every candidate which of these they have integrated in production, not in a prototype. Certification, test environments, merchant agreements and approval steps take calendar time that has nothing to do with development effort, and a team that has been through it will put those weeks in the plan while a team that has not will discover them at the worst moment.
Universal design is a legal requirement, not a preference
Accessibility obligations here are enforced rather than encouraged, and they reach private sector services aimed at the public as well as government systems. WCAG 2.1 is the reference used in practice, and public bodies expect a declaration describing the current state of the solution. The cost difference between designing for it and retrofitting it is large, and it falls on the buyer either way.
Put it in the requirement document explicitly, name who tests it and how, and ask for an example of a delivered service that meets the standard. Suppliers with public sector experience will produce one immediately. This is also a fair question to ask of design candidates: component libraries chosen in the first week determine most of the outcome, long before anyone runs a test tool.
Energy, maritime and industrial buyers dominate the serious budgets
Outside consumer services, the substantial software spend in the region sits with offshore energy, shipping and subsea operations, process industry, and the engineering companies that serve them. That produces a software supplier market comfortable with sensor data, operational technology, long lived systems and safety cases, which is quite different from a market shaped by ecommerce. If your project resembles that world, prioritise domain evidence heavily; the difference between a team that has handled time series data from equipment and one that has not is measured in months.
If your project does not resemble that world, be equally deliberate. A firm whose portfolio is industrial may quote your consumer product with industrial process attached to it, and you will pay for rigour you do not need. Ask directly what proportion of current work looks like yours.
Mixed teams, language and the working agreement
Because local capacity is expensive, most software firms here combine a local lead with delivery staff elsewhere, and the good ones say so on the first call. The model works. What breaks it is ambiguity about responsibility, so establish who holds the requirement, who is liable for delivery, and who you escalate to when something slips. Ask which language the specification, the code comments and the internal documentation are written in, since a system specified in Norwegian and built by a team working in English produces a translation layer that nobody owns.
Customer facing language deserves the same attention. Supporting both written standards of the national language is a real requirement for public sector work and a reasonable expectation elsewhere, and it affects content modelling rather than just translation. Settle it in the specification instead of discovering it during user acceptance.
Comparing the software companies in Oslo on your shortlist
Keep the shortlist short and make the comparison genuinely like for like: the same first phase, the same deliverables, the same assumptions about who supplies design, content and test data. Ask for the running cost after launch as a separate figure, covering hosting, third party services and the support arrangement, because in this market the support agreement is often where the long term relationship and the long term spend actually live.
Ask what happens if you want to leave. Repository ownership from day one, deployment documented well enough for another team to follow, and no credential held exclusively by the supplier. Firms here are generally professional about this and will not resist a clear exit clause. When you are ready to compare written offers, describing the requirement once and sending it to several vetted development firms together saves repeating the same briefing call. If the work is more about reaching customers than building systems, marketing specialists in the same market and search specialists are listed separately, and the full index of software development companies by location covers markets beyond this one.