Web app development for Danish businesses

What Danish teams ask us to build

Most requests fall into three groups: a portal where customers or members log in to see orders, documents or bookings; an internal tool that replaces a spreadsheet and some email; and the first version of a product. Each starts with a written scope of users, roles, data and the three or four journeys that matter. If the scope is unclear, we recommend a paid discovery phase before a full quote.

Our web app development service has the process. For product companies planning a subscription tool, see SaaS development.

Danish requirements in the data model

Hosting, security and Datatilsynet

Datatilsynet enforces GDPR in Denmark. For an application that stores customer data, that means a data processing agreement with the hosting provider, a list of sub-processors, encryption in transit and at rest, and a plan for reporting a breach within 72 hours when the law requires it. We host in an EU region on request and keep production data out of development environments.

India has no EU adequacy decision, so our team's access to personal data rests on standard contractual clauses and a transfer assessment. In practice we develop against synthetic data and use time-limited, logged access for support. Your lawyer should review the final arrangement.

Accessibility, language and design

A customer-facing application selling to consumers can fall under the European Accessibility Act, which has applied since 28 June 2025. Even where it does not, we build with semantic HTML, keyboard support, visible focus and form errors that tell people what to fix. Interfaces are written in Danish first, with strings kept in translation files so English or another language can be added without code changes.

Internal tools get the same care. A tool that staff dislike will be replaced by a spreadsheet within a month, so we test with the people who will use it.

Build, buy or configure?

Custom code is not always the right answer. Before quoting a build we check whether a configured off-the-shelf tool would cover most of the need at lower cost. Booking, simple CRM and document sharing are all well served by existing products. Custom development makes sense when your process is a competitive advantage, when existing tools force awkward workarounds, or when you need to own the data model and integrations.

• If an existing tool covers about 80 percent of the need, configure it and automate the gap.
• If the logic is unique but the screens are standard, a low-code or headless setup may be faster.
• If you need your own login, roles, reports and integrations, a custom app usually pays back.

We say which route we think fits, even when it means a smaller project for us. Our fixed price vs time and materials comparison explains how we handle scope.

How a build runs from India

1. Scope and quoteA call in the Danish morning, a written scope, and a fixed quote within one working day.
2. Clickable prototypeKey screens in Danish, reviewed with the people who will use them.
3. Two-week sprintsA demo at the end of each sprint on a staging link, a changelog, and one named lead.
4. Testing and launchAutomated tests on core flows, a security review and a production checklist.
5. SupportMonitoring and fixes for the first weeks, then hourly or monthly support.

Calls fall between 09:00 and 14:30 Danish time in winter, or 15:30 in summer, which suits both teams.

Price

Projects start at $1,500, with extra work billed at $30 an hour. A simple internal tool is near the start of that range. Several user roles, payments, integrations and reporting add scope. The web app cost guide shows typical ranges, and the RFP template helps you write a brief that gets comparable quotes.