Scandinavian software values — what they actually mean for products

Software made in Scandinavia tends to feel different. Linear. Spotify in its early years. Klarna before the IPO push. Tobii. The design heritage that ran through Superhuman. Arc browser. Parts of Notion. iA Writer. There's a thread that runs through them — they feel quieter. They feel like someone considered the defaults. They don't shout.

None of this is uniquely Scandinavian — there's plenty of calm, considered software made elsewhere, and plenty of loud software made here. But the combination of values tends to show up in Nordic products more than the average, and the label gives us something to point at when we're explaining a trade-off. So when we say "Scandinavian software values," this is roughly what we mean.

Calmness over loudness

US-style enterprise SaaS is loud by default. Toast notifications fire on every action. Modal dialogs interrupt your flow to announce a new feature. Every empty state is an upsell. The product treats your attention as something it owns, not something it borrows.

Calm software inverts that. Notifications are a privilege, not a default. Confirmations are quiet. The sidebar doesn't pulse to remind you about an unrelated feature. When you log in, the product gets out of the way and lets you do the thing you came to do. If you want help, it's there. If you don't, it's not.

Defaults that work

A lot of enterprise software ships with a wizard. Twenty configuration screens before you can do anything useful. The implicit message: we're flexible enough to do anything, so you do the work of telling us what you want.

The Scandinavian instinct is the opposite. Out of the box, the product should solve eighty per cent of the use case without configuration. The defaults shouldn't be random — they should reflect what most users actually do. If you're in the other twenty per cent, you can change them. But the average studio should be able to sign up, create a class, and take a booking inside ten minutes, without consulting documentation.

For us, this is a constant exercise. Every default in Class Booking is a small opinion. When you create a new class, the booking deadline defaults to four hours before the class starts — because four hours is what most studios actually use. When you create a membership, the renewal email goes out three days before expiry — because that's the window where customers actually act on it. None of these are radical choices. They're just choices, made on your behalf, so you don't have to make them.

Plain language

A lot of admin UI reads like it was written by the engineering team for the engineering team. "Configure entity-level RBAC policies for tenant sub-organisations." Half the buttons are nouns lifted from the database schema.

Plain-language UI sounds like a friendly colleague. "Who can see this class?" instead of "Visibility scope." "What happens when someone cancels late?" instead of "Late-cancellation policy configuration." The words are shorter, the sentences are shorter, and the person reading them doesn't need a glossary.

"Saying no to features is harder than saying yes. Good software is partly what you don't add."

Honest pricing

What you see is what you pay. No "contact us for a quote" for the tier you actually need. No transaction commission hidden behind the headline price. No three-year contract that auto-renews unless you give ninety days' notice.

This sounds obvious until you've dealt with the alternative. Most legacy booking platforms quote a low monthly fee and then take one to two per cent of every transaction on top — sometimes more. Over a year, that can quietly double the real cost. We list our prices in euros. The headline number is the number. We don't charge per booking, per member, or per class.

And related — we don't have an upsell modal that pops up when you hit a tier limit. We email you. The email says what changed and what your options are. You can ignore the email. Nothing breaks.

Restraint with features

Saying yes to a feature is easy. There's a customer who wants it, an engineer who'd enjoy building it, and a sales person who could close a deal with it. Saying no is harder, and it's the harder thing that makes good software.

Every feature added is a feature that has to be maintained, documented, translated, and explained to new users for the rest of the product's life. It's a decision the next user has to make sense of in the settings screen. The cost isn't one-time; it compounds. So we say no a lot. To integrations we don't want to commit to. To configuration toggles for things three customers asked for. To complexity that earns us a deal but punishes the next hundred users.

This is unglamorous work, and it's hard to put on a feature page. But over five years, it's the difference between software that stays sharp and software that gradually buries its useful parts under a decade of well-meaning additions.

Long-term thinking

Bootstrapped over VC-fast. Postgres over the new shiny thing. Server-rendered HTML over the framework that's trending this quarter. The boring choice, in infrastructure terms, is almost always the right one — because the boring choice has been around long enough for the failure modes to be documented, and because the people maintaining your product in 2030 will thank you.

We picked Postgres. We picked Next.js because it's become boring in the right way — well-supported, predictable, easy to hire for. We're not chasing the framework that's on the front page of Hacker News this month. The boring choice is what lets us focus our energy on the parts of the product that actually matter to the user — the booking flow, the membership logic, the calendar — instead of on a quarterly migration to whatever's replaced it.

Real GDPR

GDPR has been law since 2018. A lot of US-built SaaS still treats it as a checkbox. They added a cookie banner, wrote a one-page privacy policy, and consider the problem solved. Then Schrems II happened, and they had to retrofit data-residency for European customers, which is the kind of thing that's very hard to do after the fact.

Building in the EU from day one means GDPR is in the architecture, not the footer. Data lives on EU servers. The data processing agreement is a real document, not a one-pager. We are the data processor; the studio is the controller; that distinction is built into how the system thinks about user data. None of this is heroic — it's just easier to do correctly when you start from scratch in Copenhagen than when you bolt it on to a system that was designed for Iowa.

A small concrete example

We have an admin AI assistant. It answers questions about your studio — "how many bookings did we have last week," "which class is selling badly," that kind of thing. It does not, mid-answer, suggest you upgrade to the higher tier. It does not generate marketing copy you didn't ask for. It answers the question and stops.

That sounds small, but it's a choice. A different design philosophy would say "we have your attention, let's monetise it." This one says "you asked a question, here's the answer, we'll be here when you have another one."

Honest about the framing

One last thing. "Scandinavian software values" is partly a marketing frame. We know that. There's nothing magic about a postcode in Copenhagen, and there's plenty of bad software made in the Nordics and plenty of beautifully considered software made in San Francisco. The label is a stylisation, and we use it knowing that.

But we like the frame because it gives us a constraint. When you've told the world you stand for calm defaults and honest pricing, it's harder to add a pop-up upsell to the dashboard, even when revenue is slow. The label is a public commitment, and public commitments make it easier to say no to the next bad idea. That's the part we want.

We want to be calm. We want to default well. We want to charge fairly. Saying so out loud — and putting a flag on it — is one of the ways we hold ourselves to it.