Copenhagen buyers search in Danish, and the product has to answer in Danish
Almost all of the demand reaching this market is expressed in Danish, and that is a useful signal about the audience rather than a detail of the tender. If your users are local, an English interface with a Danish translation layered over it will read as imported, and the words most likely to feel wrong are the ones nobody reviews: error messages, empty states, notification text and the confirmation copy in a payment flow.
Decide early who writes the Danish, and make it a named role rather than an assumption. If you are an international buyer commissioning here, ask each supplier whether they write the local copy themselves or subcontract it, and insist that the first screens are drafted in Danish rather than translated at the end. Layout follows from that decision, because compound words are long and the buttons that fitted in an English mockup will not fit once the real strings arrive.
Identity and payment integrations drive the timeline more than the screens do
A consumer or public facing mobile app here is usually expected to work with the national identity scheme and with the payment habits people already have. Integrating MitID is not a weekend of work: there is an onboarding process with the provider, a broker to choose, test environments to be granted, and rules about what your service may do with the result. The same applies to payment initiation and to the card and wallet arrangements Danish users expect.
Treat every integration as a task with an external dependency and a queue in front of it. Ask each candidate which of these they have shipped, not merely evaluated, how long approval took last time, and what they would start first if the contract were signed tomorrow. A supplier who has done it will talk about the sequence of applications before they talk about screens. A supplier who has not will place the integration in the middle of the plan, where it will quietly become the reason you miss your date.
The design bar is higher here than most briefs admit
People in this market use well made digital services daily, from banking to public administration, and that sets an expectation your product inherits whether or not your budget planned for it. A mobile app is judged against that standard on the first screen. The consequence is practical rather than aesthetic: fewer steps, clearer defaults, restrained visual noise, and interaction that behaves the way the operating system behaves rather than inventing its own conventions.
When you compare portfolios, look past the presentation images to whether the candidate can explain why a flow has the number of steps it has. Ask what they removed during a previous project and why. Studios that treat design as decoration will show you visuals. Studios that treat it as the product will show you a before and after, and will be able to say what changed in behaviour once the simpler version shipped.
Consent, tracking and what the mobile app is allowed to collect
European data protection rules apply in full, and enforcement attention has been steady enough that buyers should treat the consent design as part of the specification. Every analytics tool, crash reporter, advertising component and marketing integration arrives with its own collection behaviour, and each one has to appear in the privacy disclosure that the platform owners require before your submission is approved.
Ask candidates for the list of third party components they intend to include and what each transmits. Ask whether the product functions for someone who declines tracking, because a mobile app that degrades into uselessness after a refusal will be refused by most of your audience. Ask where personal data is stored and processed, and get the answer in writing if your buyer is a public body or handles sensitive categories, since that question is the one that stalls approvals.
Accessibility is now a commercial requirement for consumer products
Public sector digital services here have had accessibility obligations for years, and the newer European rules extend similar expectations to a wide range of private consumer services. For a mobile app that means screen reader labelling, respecting the user's chosen text size, sufficient contrast, keyboard and switch access, and not conveying meaning through colour alone.
This is cheap when it is part of design and expensive when it is a remediation project after launch. Put it in the brief with a named standard, ask each supplier how they test it and with which assistive technologies, and ask for an example of a product they have taken through an audit. Vague reassurance at tender stage reliably becomes a change request later.
Working culture affects your project management, not just the atmosphere
Teams here are flat, direct and comfortable disagreeing with a client, which is an advantage if you want to hear about problems early and a friction point if you expect deference. Decisions are made in the room rather than escalated, meetings are short, and the working day ends when it ends. Plan your own availability accordingly: a supplier who responds within office hours and not after them is not being unhelpful, it is how the market works, and it produces teams that are still functioning in month nine.
Use that directness deliberately. Ask each candidate what they think is wrong with your brief. The useful answer is a specific objection, and the firms most worth hiring will give you one during the tender rather than after the contract.
Turning a Copenhagen longlist into a decision
Brief three mobile app studios with the same document and compare their questions, assumptions and exclusions before their totals. Confirm that the App Store and Play Console accounts, signing keys and push credentials will be registered to your organisation, that the repository is yours, and that maintenance is priced separately and covers annual platform releases as well as store rejections.
Keep adjacent scopes as separate tenders rather than bundling them, whether that is custom software firms in this market, local web development suppliers or marketing support for launch. The regional picture, including neighbouring markets such as Stockholm and Helsinki, sits in the mobile application development directory. When your integrations, languages and ownership terms are written down, send the same brief to several verified studios at once.