BIG BOX Hosting About № 00.01

24 years,
one company,
one jurisdiction.

A founder's note from Mikael Vainiomaa. Why Ljubljana in 2002, why we stayed, why we never expanded to the United States, and what two decades of operating email infrastructure taught the company. The text below is anchored in verifiable legal events — CCR 1258/2009, the CLOUD Act, Schrems II, the Microsoft France testimony, the OVH Canada ruling.

01  /  The opening

How this started.

The origin was a sysadmin job, not a strategy. The strategy came later, and only the parts of the strategy that were deliberate are worth telling. The rest was geography and timing.

I came to Big Box Hosting through the route most operators in this sector took in the late nineties: working on MTAs before Email Service Provider was a commercial category. qmail was at its peak. sendmail was still in production on most servers. Everyone who understood how SMTP actually worked ended up administering a hundred boxes for clients who could not figure out why their mail kept landing in spam. The work was unglamorous and steady. It paid the rent and it taught me what the major receiving networks were going to do five years before they did it.

I started Big Box Hosting in Ljubljana in 2002 because that was where I was living and because the cost of operating was structurally lower than Western Europe without sacrificing connectivity. The first server was in a closet at a colocation provider that would be acquired three times before the decade was out. The first client was a regional ESP that needed someone to operate their PowerMTA stack because their previous administrator had left without documentation. We migrated their fleet over a weekend and ran it for the next eleven years. They paid every invoice. The retention was the proof of concept.

The decisions that came afterwards — staying in Ljubljana, expanding to the other four jurisdictions, never entering the US market — were deliberate. The origin was geographic accident more than strategy. I want to be honest about that distinction because most company-history pages confuse the two, and the confusion produces marketing copy that the next ten years will not survive.

─────────────────────────────────────────────────────────────────────────
02  /  Why Ljubljana

Ljubljana, since 2002.

Three reasons we stayed. Constitutional architecture. Data centre market. Regulatory predictability. Each one has held up across two decades. Each one is verifiable against primary sources.

The reasons we stayed in Ljubljana after the company started growing are easier to articulate than the reasons we arrived. Three of them have held up across two decades. The first is the constitutional architecture of post-1989 Slovenia. The country emerged from dictatorship with a 1991 Constitution that put freedom of expression and the secrecy of correspondence in more explicit terms than most Western European frames written in calmer eras. Article 28 of the Slovenian Constitution is unambiguous about communications privacy. Article 30 is unambiguous about expression. The Constitutional Court has enforced both against subsequent legislative attempts at mass surveillance, most consequentially when it struck down the national transposition of the EU Data Retention Directive in Decision 1258/2009 — five years before the European Court of Justice did the same in Digital Rights Ireland.

The second reason is the data centre market. Ljubljana in 2002 had a handful of carrier-neutral facilities. Today the Slovenian Internet Exchange (SIX), run by ARNES, peers across two city sites — the Ljubljana Technology Park and the Jožef Stefan Institute — interconnecting Telekom Slovenije, T-2, Telemach and the regional carriers, with diverse Tier-1 transit running onward to Frankfurt and Vienna. Ljubljana sits on the Central-European fibre corridor, so latency to the major Western hubs stays low while the routing into the Adriatic and Western Balkans is short. The position is structural, not promotional, and it has held for the better part of two decades.

The third reason is the regulatory predictability. Slovenia joined the EU in 2007 and the GDPR applied natively from 2018. NIS2 transposed in 2024. The Data Act became fully applicable on 12 September 2025. Across two decades there has been no jurisdictional surprise — no lurch toward something other than the European frame, no equivalent of the United Kingdom leaving the EU and rendering its adequacy framework provisional in perpetuity, no equivalent of the United States cycling through Privacy Shield then its invalidation under Schrems II then the Data Privacy Framework now under challenge in three separate national courts. Stability is not a marketing claim. It is the absence of avoidable surprise across a decade of operation, and Ljubljana has had less of it than most of the alternatives we have watched our clients evaluate.

─────────────────────────────────────────────────────────────────────────
03  /  The structural decision

Why we never expanded to the US.

The most consequential decision in the company's history. The reasoning is technical and legal — and now, after CLOUD Act, Schrems II, Microsoft France, and OVH Canada, vindicated by events the company did not need to predict to benefit from.

The single most defensible decision in the company's history was the one I made not to enter the US market. The reasoning matters. I want to walk through it because it is also the answer to the most common question prospects from regulated industries ask us during due diligence.

The first version of the question came up around 2010, when the obvious next move for a profitable European email infrastructure company was to open a North American sales office and start chasing the larger market. Several of our competitors did exactly that. They opened offices in Boston or San Francisco, hired US sales staff, and registered Delaware C-corps to handle the contracts. The arithmetic was straightforward — the US ESP market was three or four times the size of the European one and the customer acquisition cost was lower because there were more buyers. I declined. The reason was a specific one and it has aged extremely well.

Operating an email infrastructure business with a US legal nexus means accepting that any data the company controls — wherever it physically sits — becomes reachable through US legal process. The legal mechanism that makes this true is older than the technology. The Stored Communications Act has been around since 1986. What changed in 2018 was the CLOUD Act, which clarified what most lawyers already suspected: a US-domiciled corporate entity can be compelled to produce data under its control regardless of where in the world that data physically resides. The relevant variable is corporate domicile. The location of the data centre is decorative.

Several events between 2018 and now have confirmed this reading of the law. Schrems II in July 2020 invalidated the Privacy Shield framework by holding that US surveillance law was incompatible with the GDPR's standard for adequate protection. The Court of Justice was direct about the mechanism. In October 2023 the EU and US negotiated the Data Privacy Framework as a successor — that framework is currently under challenge at the General Court and most European data protection lawyers I respect think it will not survive the appeal. In June 2025 Microsoft's legal director told the French Senate under oath that no contractual or technical arrangement could override a properly executed CLOUD Act demand on EU customer data held by Microsoft. The testimony made the structural problem unambiguous. In September 2025 a Canadian court ordered OVH to extract and produce customer data held in Europe by group entities outside Canada — a ruling that demonstrated the same mechanism applied through different jurisdictions. The lesson from each event is identical. Corporate ownership decides what process applies to the data. Geography decides nothing.

The decision in 2010 was the same decision in 2018, in 2020, in 2023, in 2025, and the case has only strengthened with each successive event. We do not enter the US market. We do not register a US subsidiary. We do not hire US employees whose discretion can be compelled by a US court. We do not contract with US-domiciled cloud providers in any path between our customer contracts and our customer data. The corporate counterparty for every Big Box Hosting customer is a Slovenian d.o.o. with no foreign group exposure. That is the architecture. We have refused to compromise it for revenue more than once across the last decade, and each refusal has cost us a deal that, with hindsight, we are pleased to have lost.

─────────────────────────────────────────────────────────────────────────
04  /  Three lessons

What 24 years taught us.

Three observations that hold across two decades of operating email infrastructure. None of them sound novel written out. All three have survived enough deployments to be worth the page space.

Three lessons from operating an email infrastructure business across two decades. They are not elegant. None of them sound novel when written out. All three have survived enough deployments to earn the right to be listed alongside the legal anchors and the technical specs that occupy most of this site.

Lesson one — senders fail by the same three things in 2025 that they failed by in 2002. List hygiene. Authentication. The discipline to send what they said they would send when the recipient signed up. Every other category of deliverability problem we have ever debugged for a client traces back to one of those three. The technology around the failure modes has changed — DKIM in 2007, DMARC in 2012, BIMI in 2021, the Yahoo and Gmail bulk sender requirements in 2024 — but the underlying behaviours that produce inbox failure have been remarkably stable. Senders who fix the three things stop having deliverability problems. Senders who do not fix them buy increasingly expensive products from increasingly clever vendors who promise to fix the symptoms without addressing the cause.

Lesson two — the relationship between a sender and a major mailbox provider is operational rather than technical. Gmail does not block your mail because of your DKIM signature. It blocks your mail because your last million sends produced behaviour that fits the pattern of a sender Gmail no longer trusts. The technical configuration is the floor. Necessary, not sufficient. The work that actually moves placement is the slow accumulation of consistent behaviour over weeks. Senders who internalise this run smaller campaigns more frequently to populations that engaged with the previous campaign. Senders who do not run larger campaigns less frequently to populations that no longer remember signing up, and they wonder why the bigger sends keep landing in Promotions. We see the difference in our customer base every quarter. We have stopped trying to teach it through documentation. The senders who learn it learn it from their own send logs after a year of watching the metrics.

Lesson three — managed services beat self-serve products for any sender pushing more than a few hundred thousand emails a month. We did not start as a managed-services company. The early Big Box Hosting was closer to a colocation provider with mail expertise — clients ran their own MTAs on hardware we provisioned. The pivot to fully managed PowerMTA and KumoMTA stacks happened around 2014, after we noticed that the clients who paid us to operate the stack had consistently better deliverability than the clients who ran the same software themselves on identical hardware. The technology was identical. The operational discipline was not. Today the company runs almost entirely on managed engagements, and the small fraction of self-serve accounts we still keep are clients who specifically want operational control and who have the team to use it productively.

─────────────────────────────────────────────────────────────────────────
05  /  What comes next

The shape of the company is not changing.

What we will not do. What this site is designed to be. What evaluating us actually involves.

The shape of the company is not going to change in any direction that compromises what produced the last 24 years. No free tier — shared infrastructure compromises the deliverability of every sender on it. No acquisitions — integration overhead pulls operational attention away from the existing book. No outside investment that would reset the timeline against which decisions are evaluated. The company is profitable. The team is small. What growth happens will happen on the slow timeline that has produced retention numbers I have not seen published anywhere else in this sector — and we are not going to compress that timeline for a quarter that wins applause and loses customers.

If you read the rest of this site, you will notice that the operational pages are denser than the marketing pages. That is on purpose. Email infrastructure is a technical purchase, and procurement teams in regulated industries do not buy from vendors whose technical pages do not survive the kind of scrutiny their own engineers apply. The pillar guide on email authentication is the deepest single document we have published. The location pages each anchor on the operative legal frame of that jurisdiction, with citations to the specific statutes and case law a compliance reviewer can verify. The compare pages are calibrated against the published pricing and feature documentation of the named alternative as of the date the page was last updated.

If you are evaluating us, the most useful thing I can offer is a 30-minute call where we walk through your specific exposure profile and tell you honestly whether what we operate fits what you need. About one in five of those calls ends with us recommending you stay where you are, because the migration cost would not be justified by the marginal improvement we could deliver. We have been doing this long enough to know the difference.

— Mikael Vainiomaa, founder. Ljubljana, Slovenia.

─────────────────────────────────────────────────────────────────────────

Want a 30-minute call?

The honest framing: about one in five of these calls ends with us recommending you stay with your current provider, because the migration cost would not be justified by the marginal improvement we could deliver. About one in six reveals a 30-50% saving most prospects had not modelled. The rest are conversations about which jurisdiction, which MTA, and which deployment model fits the workload. No sales pressure on any outcome.