Stockholm Worked from Barcelona Nordic region compute Same hour as us

Stockholm.
Cost per inference.

We are based in Barcelona and share your working hours exactly. Stockholm is the European city where the cost conversation happens first and hardest — partly because the companies here sell to consumers at thin margins, and partly because the cloud region on their doorstep is one of the cheapest and lowest-carbon in the EU, which makes the arithmetic worth actually doing.

Last reviewed 5 September 2026 · Engineering guidance, not legal advice.

WHAT IS ACTUALLY DIFFERENT HERE

A Stockholm cloud region, and it is cheap

Sweden hosts a major Nordic cloud region, drawing on a grid that is largely hydro and nuclear, and it has historically been among the lower-priced regions in the EU. Two consequences follow. Keeping data in Sweden is an ordinary configuration choice rather than a project. And for a workload that runs continuously, region choice is a genuine cost lever rather than a rounding error. Pricing and grid mix both change, so we take the current figures from the provider at design time rather than quoting them as fixed.

Ordinary regulator, unusually linked data

IMY supervises data protection under the same GDPR as everywhere else in the EU, which is the straightforward part. The Swedish complication is the personal identity number: records here join up across systems far more readily than in most countries, so a support transcript or a log line can be more identifying than it looks, and pseudonymisation that would be adequate elsewhere often is not. We look for that early, because it decides what may be sent to a hosted model at all.

Unit economics is the design constraint

Swedish product companies typically know their revenue per user or per transaction to the öre, and an AI feature has to sit under it with room left. That is not a procurement conversation, it is an architecture one: it decides model size, whether small models handle the common path, how much context is loaded per call and what is cached. We size that before building, and GPU sizing and cost is where the method is written down.

Two industries pulling opposite ways

Gaming wants very high volume at very low latency and near-zero marginal cost, and can tolerate an imperfect answer. Payments and fintech want an answer that can be explained to a supervisor months later, and cannot tolerate an unexplained one. Both are Stockholm industries and they produce almost opposite architectures. A studio that builds them the same way is building one of them badly.

THE WORK THAT COMES OUT OF THIS CITY

Payments and fintech. Stockholm exports consumer finance across Europe, and the AI problem that comes with it is transaction monitoring and fraud work where a flagged customer eventually asks why. Precision matters commercially, because every false positive is a real person blocked at a checkout, and explainability matters legally, because an automated decision that materially affects someone has to be accountable. The architecture that results keeps the model as one input to a decision rather than the decision itself, and that is what we describe under fraud and AML.

Gaming. A studio with millions of players has support volume in a dozen languages, around the clock, at a cost per contact that has to stay below what a player is worth. This is one of the few settings where deflection rate and cost per resolved contact are the only two numbers anybody cares about, and where the honest engineering answer is often a smaller model doing most of the work with a larger one held in reserve. It also produces the toughest evaluation problem we see, because player language is nothing like the polite corpus these systems are usually measured on.

Telecoms and industrial technology. The network and equipment companies in and around the city hold enormous technical documentation estates and field-service histories. Making those answerable to an engineer standing in front of a fault is straightforward retrieval work with a very high value per query, and it rarely requires the most expensive model available.

Product teams generally. Whatever the sector, a Stockholm client tends to arrive already convinced the feature is possible and wanting to know what it will cost to run and how they will know it still works after a model update. That is an evaluation question before it is a modelling one, and building the evaluation first is the only version of this that survives its second year.

HOW A STOCKHOLM PROJECT ACTUALLY RUNS

We come north for discovery

Barcelona to Stockholm is a longer hop than most of our European work — roughly three and a half hours direct — and still worth doing for the first workshop. Decisions here tend to be reached by the group rather than announced to it, so we ask for everyone who can veto the design in that first session rather than meeting them one at a time in month two.

Then remote, identical hours

Sweden and Spain keep the same clock all year, so there is no conversion and no truncated overlap. The one thing we do plan around is the Swedish summer: July is genuinely quiet, and a milestone that assumes otherwise will slip.

And back for handover, with the cost model

The ownership session includes the thing Stockholm clients ask for most and get least often: a working model of what the system costs to run at ten times current volume, with the assumptions visible so you can argue with them. After that the system is yours, in your repositories and your cloud accounts.

QUESTIONS

QUESTIONS — 5

No. We have one office and it is in Barcelona. We travel to Stockholm for discovery, for handover and for anything where being in the room changes the outcome. There is no Swedish entity and no Nordic partner firm behind us.

Yes, and it is easier here than in most of Europe. There is a major cloud region in Sweden, and open-weight models can be self-hosted inside your own perimeter, so a system where no personal data leaves the country is an ordinary configuration. The usual reason to look further afield is a specific hosted model that is not offered in the region, and that is a trade-off worth making explicitly rather than by default. Where a hosted model is used we document its retention and training terms at the time of writing, and you should confirm them against the provider's current terms.

Partly, and it is worth being precise about which part. We can measure what the system does — tokens processed, calls made, GPU hours consumed — and that is the half that actually depends on the engineering. Converting that into emissions relies on the provider's own disclosures for the region, which we can cite but cannot audit. So the honest deliverable is a defensible activity figure plus the provider's published factors, not a number of our own invention. If your company reports under the CSRD, that distinction will matter to whoever signs the report.

By deciding the budget per interaction before choosing a model, and by instrumenting the system so cost per outcome is visible from the first day rather than discovered in an invoice. In practice that usually means routing the common cases to a smaller model, caching aggressively, and keeping the expensive path for the small share of traffic that needs it. It also means being willing to conclude that a feature is not viable at the price, which is a legitimate finding and cheaper in week two than in month nine.

The same as anywhere else — the ranges are on the pricing page, in euros and exclusive of VAT. We do not price by postcode, and we do not price against Nordic consultancy rates.

Keep reading

30-minute technical call · no deck