Serbia and North Macedonia are the Western Balkans countries selected for the EU’s AI Factory antenna program - part of a €200 billion public-private initiative combining €50 billion in EU funding with €150 billion in private capital. Serbia reports that 97% of IT companies are using AI and 90% of IT professionals use it daily. More than half of startups are integrating AI into their products, up 10% year over year. Croatia reports that roughly half of companies use AI in daily work and more than €1 billion was invested in AI in 2023 alone. Slovenia is building a national AI Factory with 2,400 GPUs and has roughly €500 million in available venture capital. Albania jumped 16 places in the Global Innovation Index in 2025 while startup funding grew 50% year over year.

A few years ago, most of these numbers would have sounded aspirational.

Today, Southeast Europe is no longer debating whether AI matters.

At the inaugural SEE AI Summit 2026 in Novi Sad, the conversation had already shifted toward compute, deployment, regulation, commercialization, and production infrastructure.

National studies across the region capture the transition clearly.

But one number kept pulling me back.

Thirty-four percent.

That is the share of enterprises in Serbia actually using AI in business operations. Not experimenting with tools. Not individual employees using ChatGPT. Actual company use. Croatia’s research found that 75% of companies cite lack of knowledge as the primary barrier and only 5% regularly train employees on AI. A Goldman Sachs Small Business AI Adoption Survey from March 2026 found that while 76% of businesses claim to use AI, only 14% have integrated it into core operations. Chatbots and RAG systems still dominate production deployments, agentic workflows remain early, and there are still no truly AI-native companies emerging from the region at scale. High adoption at the individual level. Near-zero deployment at the organizational level.

That gap is the actual story.

What the numbers are measuring

The 97% figure is probably real and meaningful. It tells AI tools are accessible and that technical professionals in Serbia (and likely in the other Southeast European countries ) are adopting new ways of working faster than most expected. But it does not mean that organizations are changing.

A developer using AI-assisted coding tools every day is not the same thing as a company running AI-powered operations at scale. While one measures individual productivity, the other measures organizational capability. National studies across the region capture the transition clearly: the countries in SEE region are no longer asking whether AI matters - the challenge now is how to implement, finance, govern and scale it strategically.

Most SEE AI ecosystem activity is still optimized for events, accelerator programs, policy frameworks, while founder communities are largely organized around introducing AI rather than operationalizing it. Implementation still requires process change, organizational commitment, technical integration, and the kind of trust that takes time and repeated deployment to earn.

The implementation gap is a production readiness problem - the ability to move a working prototype into a deployed system that customers depend on, enterprises trust, and teams can operate within predictable cost constraints.

The infrastructure investment is real - and scale context matters

Across the region, governments are making their first serious compute commitments. Serbia’s National AI Platform completed a major hardware expansion in May 2026 - roughly €40 million, 720+ GPUs operational, with a roadmap to 2,000 by 2030 and 5,000 by 2035. North Macedonia’s VEZILKA initiative connects startups and researchers directly to EuroHPC infrastructure, offers free HPC access to companies in the proof-of-concept phase, and has begun training roughly 3,000 civil servants across government. Slovenia’s national AI Factory is under construction as part of the same European infrastructure program, adding 2,400 GPUs to the regional compute base. Serbia and North Macedonia were the only Western Balkans countries selected for the EU AI Factory antenna network — part of a €200 billion public-private initiative that is reshaping where serious AI infrastructure gets built in Europe. These are serious institutional bets backed by national budgets and implementation programs, not just policy documents.

But the scale gap is real and worth naming directly.

A single frontier AI training cluster at a major US or Chinese technology company can exceed 100,000 GPUs. The largest players are competing on capital expenditure, energy infrastructure, and compute density that most countries cannot realistically match - not just in SEE. IEA projections put global data center electricity consumption roughly doubling to around 945 TWh by 2030, driven by infrastructure buildouts that require sovereign-level resource commitments.

Sovereign compute may be worth building, but it is not sufficient as a strategy on its own.

An ecosystem can have sovereign compute and still run every production workload on hyperscaler platforms - training its developers on external models, designing governance structures that assume continuous API access to systems it does not control, and building companies whose critical architecture decisions were made elsewhere. The hardware exists. The dependency remains.

Infrastructure can create conditions, but it will not automatically create companies.

Where the SEE region has a genuine edge

National government initiatives in the region sound interesting, but the SEE’s real proof lies in its AI startups - specifically those few that secured seed funding or even a Series A before an acquisition. Croatian startups such as Daytona and SPLXAI demonstrate what this looks like in practice. One is building infrastructure for AI agents. The other focused on enterprise AI security before being acquired by Zscaler. Neither succeeded because they were regional companies. They succeeded because they competed globally at the critical infrastructure and security layers of AI.

The region’s unfair advantage is its technical depth paired with a powerful diaspora network. Decades of brain drain have inadvertently created a strong, unmapped network of global researchers, founders, executives, and engineers. From senior leadership at Nvidia to faculty positions at Stanford and UC Berkeley, the diaspora reflects a fifty-year tradition of technical and research excellence.

SEE ecosystem is incredibly difficult to replicate because the network is already live. The only missing piece is the organizational structure needed to help it compound globally rather than stay fragmented and personal.

The thesis

The next challenge for SEE AI ecosystems is converting its technical capability into production infrastructure, founder density, deployable market access, and durable commercial outcomes - before dependence on external platforms becomes the default.

The risk facing these ecosystems is often framed as falling behind. But I think the actual risk is different. An ecosystem can have rising AI adoption rates, active conferences, growing startup communities, and genuine infrastructure investment while simultaneously becoming more dependent on external platforms for every critical layer of the stack. The default cloud and deployment architectures come from elsewhere - and the best technical talent eventually exits to elsewhere.

None of that looks like failure, especially while individual adoption numbers are strong.

That is precisely why the conversion problem matters. Technical capability that does not become organizational capability and commercial density does not disappear - it migrates.

The SEE policy infrastructure, the technical talent, the diaspora reach, the early exits, and the growing international partnerships are real. The gap remains in the organizational layer between individual contributions and systematic capability-building.

What the SEE ↔ SF Bay Area bridge is actually worth

I am based in Berkeley.

After time spent in both ecosystems, one observation keeps resurfacing. The talent quality gap between Southeast Europe and the Bay Area is far smaller than most people assume. The density gap is real and the confidence gap is much larger.

While the technical work often holds up, the harder part is commercial fluency - how to enter a Bay Area market conversation, how to frame a company for US investors and customers, how to convert warm introductions into durable relationships, how to navigate markets where distribution frequently matters as much as technology.

I still believe that those capabilities exist in the region, but they are not yet distributed at scale.

And the diaspora bridge is one of the most underused assets still available. There are people from Southeast Europe working inside leading research labs, infrastructure companies, venture firms, universities, and technology companies across the US. Many maintain real connections to the region and countries where they are from. But only few ecosystems outside of the US have figured out how to systematically leverage those relationships - to run founders across that bridge in both directions, with real market access and infrastructure connections rather than just introductions.

The ecosystems that build that operational infrastructure will have an advantage that extends beyond any individual company or funding round. Not because of the connections themselves, but because of what systematic pathways produce over time.

Personal networks don’t compound, at least not at scale.

And the SEE ↔ SF Bay Area bridge is ultimately about that compounding:

• Converting technical talent into production companies.

• Converting infrastructure investments into commercial density.

• Converting diaspora reach into organized market access.

The ecosystems that solve these conversion problems will capture far more value than their size suggests.

The ones that don’t may find themselves contributing talent to the future without helping shape it.

From Berkeley. From inside the rooms.

And yet.

There are hundreds of startups running free pilots (the prototype phase), their demos are impressive. The “aha” moment is real, but the conversion rate to paid customers, real-world production? In too many cohorts, close enough to zero that it should change how startup accelerator programs are designed.

Here’s why.

The Window of Anxiety

Let me walk you through what actually happens inside an AI startup after a great demo.

An email marketing startup builds something genuinely impressive. Their AI drafts campaigns, analyzes results, and suggests improvements. They’re using the most powerful model available - GPT-4o or Claude, or something similar - for every single task. Fixing a comma, summarizing a thread, suggesting a subject line. It works beautifully.

Then the founder opens a spreadsheet.

At $20 per user per month, they start losing money the moment a user sends more than 50 emails a day. The math is brutal. So they need to switch to a smaller, cheaper, self-hosted model - something like Llama or Mistral - for 80% of the routine tasks with the question: will the cheaper model be good enough? Will users notice the difference?

Instead of moving from free beta to paid tier, the founders get stuck testing three or four different providers simultaneously - Groq versus Fireworks versus Bedrock - searching for the “trustworthy” balance between cost and quality. The go-to-market stalls and nobody converts.

That moment is the quiet window when a founder is deciding which infrastructure they can actually trust - and where one of the most overlooked conversion problems in the AI startup ecosystem now lives. I call it the Window of Anxiety.

This is the moment accelerators need to show up, and most don't. For an accelerator, real conversion will mean a company moving from Seed to Series A. But the AI startup ecosystem today is saturated with “Stitchers” - founders who are brilliant at assembling working demos - and under-served by “Architects” - founders who know how to build systems that will survive in the real business world. Most founders, if they want to succeed, will need to face the infrastructure trust problem in week 3, not week 12.

Two AI Startup Ecosystems, Different Failures

I spent over a decade running accelerator programs in Europe before moving to Berkeley. The contrast still surprises me.

In Europe, the legal framework, like GDPR, the EU AI Act, data residency rules, vendor diligence - forces founders to treat infrastructure trust as a day-one requirement. Data handling, security architecture, procurement risks and contractual accountability are not week-12 problems, they show up immediately. Programs there often structure the startup-corporate relationship like a long-term commitment from the very beginning.

That has some advantages, but it also incurs costs…. In Europe, the relationship is often over-structured before the product has earned that much structure.

In the Bay Area, the metric is velocity.

Programs here measure how many users signed up, how many API calls were made, how many tokens were burned. That’s not meaningless, but platform activation is too easily mistaken for conversion. Moving fast looks great on a dashboard. It doesn't tell you whether any of those startups are building something they can actually charge for.

The Linear Path Has Snapped

Most startup programs were built on a simple model: prototype at Week 4, find 10 early users by Week 8, convert them to paying customers by Demo Day at Week 12.

For most of startup history, that worked. Build something, get users, get revenue. Linear.

AI broke the line.

The problem now is that an AI prototype and an AI production system are not just different stages of the same product. They’re built for completely different purposes, with completely different priorities.

The Prototype runs on what is called a “Stitched Stack” - the most powerful frontier models, public APIs, fast integrations, quick workflows, enough interface to create magic. It is designed for the “aha” moment. The thing that makes Demo Day audiences lean forward.

The Production system runs on what is often called a “Hardened Stack”: smaller fine-tuned models, routing logic, private infrastructure, evaluation frameworks, security layers, observability, fallback paths, and real cost discipline. It is designed to be boring, but to assure reliability, cost predictability and security. Those things that make an enterprise comfortable moving forward in signing a contract.

Accelerators reward the magic - because magic makes a better story, a better slide, a better Demo Day. In doing so, they ignore the fact that the founder standing on that stage has nothing behind them that would survive a real enterprise procurement process.

The result: accelerators are teaching founders to sprint toward a demo, when they should be teaching them to architect for a commitment. By treating these two moments as the same, programs are accelerating startups directly into a wall of enterprise scrutiny they aren’t equipped to handle.

Activity Is Not Commitment

The cloud platforms have become extraordinarily generous with AI startups. And that generosity - as well-intentioned as it is - is quietly making the conversion problem harder to see.

The 2026 credit landscape has gotten serious.

Google Cloud for Startups offers up to $350,000 for eligible AI-first startups as of early 2026. They bundle in Vertex AI and specialized computing access, making it almost inevitable that a founder builds their prototype there.

AWS Activate publicly lists up to $100,000 at current program levels in startup credits, while GenAI accelerator and partner programs offer even larger packages. A founder can use those credits to test Claude, Llama, and Mistral simultaneously, across multiple use cases, without seeing a single bill.

Microsoft for Startups provides up to $150,000 in Azure credits, mostly focused on their Azure OpenAI Service - meaning a founder can activate a high-end GPT-4o instance for free, mistakes that activation for a business model, and then hit a wall the moment the credits expire and the real unit economics show up.

The program metrics are built on applications approved, accounts created, events attended, Demo Day participation up.

None of those metrics are useless. But they show what the program distributed - not what the program actually converted.

A founder with $100,000 in free credits will test two or three platforms simultaneously. Why wouldn’t they? It costs nothing. That experimentation is genuinely useful - it tells you something about documentation quality, API behavior, how the support team responds when something breaks. But free experimentation is not infrastructure commitment.

Infrastructure commitment happens at a different stage of the funnel. And most startup programs aren’t designed to see that moment, let alone influence it.

Here’s the uncomfortable truth: while these programs claim to have “no visible strings,” they create a kind of architectural gravity. The stack a founder builds for free tends to become the stack they stay on. The real infrastructure decision - the one that shapes the next 18 months of the company’s architecture - happens quietly, internally, usually without the accelerator, the cloud partner, or the program team anywhere near the room.

The generosity of free credits hides a harder truth: the startup is building on a foundation it may not be able to afford, secure, or sustain when the bill finally arrives.

Inference Makes Production Risk Visible Earlier

In the previous era of cloud computing, moving from demo to production meant working through a familiar checklist: compute, storage, uptime, security, deployment costs. Hard questions, but knowable ones. A strong technical founder could model the risk curve and make reasonable projections.

Inference-era workloads don't forgive deferred decisions the way earlier cloud architectures did.

The clearest version of this I've seen was at DigitalOcean’s Deploy SF 2026 event. One of the most useful frameworks there was the Inference Multiplier - a model showing what happens to token usage, and therefore cost, as AI products grow in complexity.

A simple chatbot handling hotel and flight searches: roughly 10,000 tokens per booking.

A smarter inference-centric assistant that actually plans your full itinerary, compares hotels, handles dietary preferences, and coordinates your calendar: roughly 100,000 tokens per booking. Ten times more.

A fully autonomous agentic workflow that handles everything end-to-end, with multiple specialized sub-agents working in parallel: over 1,000,000 tokens per booking. One hundred times the baseline.

Same task. Same outcome. Very different cost structures.

Production AI isn’t a single model call; it is a chain of model calls, database queries, routing decisions, state management, tool calls, latency tradeoffs, and observability needs… and costs compound in ways the prototype never revealed. Every design decision that felt free during development has a price tag in production.

This matters because the “Stitcher” founder is great at building the prototype precisely because they defer these decisions. Latency, cost modeling, concurrency handling, observability - those are “problems for later.” But in AI, they are the foundations of the present.

The 2026 data makes this concrete: according to Deloitte’s 2026 Tech Trends, only 11% of organizations have agents in production, while 38% are still piloting them. The gap is not mainly about model intelligence. It is about the harder work of turning AI into reliable operations, sustainable economics, and production infrastructure.

A working demo proves that something can happen once, but it does not prove the system can run economically, repeatedly, and reliably as usage grows.

The recent wave of AI cloud launches reflects how quickly the market is absorbing this reality. The shift is away from raw compute plus model access, toward integrated stacks that combine infrastructure, inference, data pipelines, and agent orchestration in a single operating model.

DigitalOcean’s AI-Native Cloud launch at Deploy SF 2026 is one example of that broader shift - moving from positioning around raw compute toward integrated infrastructure built specifically for inference, data, and agentic workloads.

At that same event, independent benchmarks from Artificial Analysis showed DigitalOcean delivering end-to-end AI responses in 11.8 seconds - fastest among 12 providers tested, including Google (12.8s), Amazon Bedrock (43.5s), and several specialized inference providers. For a founder trying to build a product users actually stay in, that gap is not a technical footnote. It’s a product decision.

Founders are starting to learn this. Many are becoming cautious about building on free-credit architecture - assembling a stack because it’s free, then discovering that the latency profile, unit economics, or operational complexity can’t survive real scale.

Raw compute will continue to matter. GPU availability still matters. But for early-stage AI companies, access is no longer the only scarce resource. The new bottleneck is operational confidence: the hard-earned certainty that a platform will scale predictably, stay within your cost model, and remain manageable under pressure when your team is small and your margins are thin.

That confidence forms early and often well before Demo Day. Often before any formal partner outreach begins. Which means the window to shape it is shorter than most partnership programs realize.

The Missing Layer Is Attribution

If startup programs want to function as genuine growth engines - rather than expensive brand activities - they need a sharper attribution chain.

Not just: who applied? Not just: who received credits, or who showed up to the workshop?

The sharper questions are: Which partner sourced this startup? What technical friction appeared early, and which intervention changed behavior? What stack was the founder building, and did usage actually convert into paid revenue?

With that chain, ecosystem teams can prove commercial contribution to their corporate partnerships - not just report on activity.

This is where partner strategy becomes more disciplined. A strong accelerator, university program, VC platform, or AI founder community isn’t valuable because its logo looks good on a partner slide. It is valuable if it consistently sources founders at the right decision moment - before the stack is chosen and before the trust is formed.

Partner ROI shouldn’t be measured by application volume or event attendance alone. It should be measured by milestone performance: qualified founders sourced, workloads activated toward production, production milestones reached, post-credit usage retained, paid usage expanded.

That is the difference between a sponsorship relationship and a growth channel. They require different conversations, different contracts, and different data.

Not All Friction Should Be Removed

The 2026 market has an abundance of free credits - AWS Generative AI Accelerator (GAIA) program now offers up to $1 million in AWS Activate credits for qualifying AI Startups specializing in foundational models, infrastructure, fine-tuning tools, and agentic workflows. But more credits just made it harder to see: what looks like a full, healthy cohort is often a collection of companies that are running free forever, unable or unwilling to commit to a real production stack.

The two underlying problems are attribution and workload retention.

What startup programs need at the front door is what I would call motivating friction: structured questions that are specific enough to reveal whether a founder has actually thought about what it costs to run their product in the real world.

Instead of tracking for company name, funding stage, problem statement, try these:

1. How much of your first real workload is training versus inference?

• In 2026, inference - running the model to serve real users - accounts by most estimates now accounts for 65–90% of a model's lifetime compute cost. If a founder is 100% focused on training, they’re building a model. If they’re focused on inference, they’re building a business. You need to know which one you’re dealing with before they hit the Inference Cliff when the credits run out and real traffic arrives.

2. What parts of your stack are already committed - databases, APIs, frameworks, cloud services?

• This identifies architectural debt early. A startup locked into a proprietary cloud-native database is harder to sell to enterprise buyers who want multi-cloud flexibility. Asking this question reveals how much of their current stack is permanent versus swappable.

3. Which infrastructure providers are you testing right now, and what are you learning?

• This one reveals technical maturity fast. A tourist founder says “We use OpenAI.” An architect founder says “We’re A/B testing Groq for speed versus Bedrock for reliability on our retrieval layer.” That difference tells you almost everything about where the founder is in their thinking.

4. Which cost variable are you least confident you can model at scale?

• In 2026, the most common margin killers are multimodal concurrency and token-heavy retrieval pipelines. If a founder can’t name their least confident variable, they haven’t modeled their scale. They’re still in free credit mode.

5. When does the free exploration phase end - and by what date do you need to make your production infrastructure decision?

• This is the question that ends the “workload fugitive” cycle - the pattern where a startup stays on free credits indefinitely, testing indefinitely, deciding nothing. It forces the founder to name the moment when experimentation stops and commitment begins. If they can’t name it, they don’t have a go-to-market strategy. They have an extended beta.

For a serious technical founder, these questions should feel like a green flag, not a burden. They signal that the program is no longer measuring “How many companies graduated?” It’s measuring “How many companies are production-ready?”

In a market where 80% of pilots never reach production due to infrastructure trust issues, that’s the filter that matters.

The Scorecard Has to Change

The competition for AI-native startups is no longer about who can issue the largest credit package and become the default platform.

What’s actually being contested is which platform a team keeps using when the product has to work - when real users depend on it, when the cost of switching becomes real, and when a CFO is asking uncomfortable questions about the infrastructure bill.

Founders today often run a primary cloud for general services while routing AI inference through a specialized provider when the performance and cost calculus warrants it. That switch happens at the production gate, not before. Sponsoring a Demo Day gets startups into the room. It does not make a platform the default once the credits expire.

The real competition is won on unit economics, architectural integration, and the quality of the relationship built before the architecture decision was made.

Put simply, the math isn't complicated, just honest:

Margin = (Revenue per Inference) minus (Compute Cost + Data Egress + Orchestration Overhead)

It’s won by offering integrated infrastructure that helps a CTO answer three questions before they have to answer them under pressure:

• What does this cost at 10x my current scale?

• Can a team of three operate this without a dedicated infrastructure hire?

• What happens when something breaks at 2am?

That’s the difference between a startup ecosystem running as a brand activity and a startup ecosystem running as a growth engine.

Everything else is just activity.

Nenad Moslavac from Berkeley, California - May 2026

Sources: Deloitte 2026 Tech Trends, DigitalOcean Deploy SF 2026, Artificial Analysis Independent Benchmarks (May 2026), OpenRouter State of AI 2025, McKinsey - Open Source Technology in the Age of AI 2025.

In English, the noun “surprise” is often used as a modifier (specifically an adjective or noun adjunct) to describe another noun: especially when something doesn’t fit the predictable patterns. In Serbian/Croatian language pronunciation, even the name itself (Nenad; in Cyrillic script: Ненад) shifts depending on different use and context: i.e. the name ending changes when addressing me directly: “Hello, Nenade” - you would say: Hello NEH-nah-deh.

For most of my life, this was nothing more than a fact so ordinary it did not seem to qualify as a fact at all. It was simply my name, resting among other familiar things, understood without effort because everyone around me already possessed the code required to understand it. No one had to stop to ask what it meant or how to pronounce it. The name arrived complete because the world around it already knew where to place it.

In the Bay Area, thinking of my name stopped being linguistic trivia and became something larger: the same name, the same experience, the same work - but once placed inside a different system, none of it arrived whole. What had once been immediately legible became explanatory. What had once entered the room with settled meaning now had to be unpacked and translated, framed and sometimes defended before it could begin to count as real. And from that small shift - from the simple fact that even a name may lose its natural ease when removed from the world that taught others how to read it - there emerged for me a broader thought, and then gradually grew into my working thesis.

Credibility does not travel intact

This is difficult to accept at first, especially for those of us who have spent years believing, not unreasonably, that the work should speak for itself. The work remains the work, after all. The outcomes happened or they did not happen. Built teams held under pressure, capital moved, programs delivered, decisions carried consequences in the lives of our own or other people. One imagines that such things possess a weight that can survive distance. And yet the longer one moves between systems, the more one begins to see that truth, however solid in its place of origin, does not circulate in pure form. It circulates through recognition. And recognition is coded locally, conditioned by habit, trained by systems, and shaped by the pace at which those systems are forced to decide.

Building trust, in most places, takes time and is slow.

However, the Bay Area, whatever else one may think about it, is not governed by slowness.

It moves with the impatience of a place that has learned to treat time not as medium, but as pressure. Too much is in motion here equally, capital, ambition, density of talent, and they are all trying in one manner or another to alter the scale of what already exists. Under such conditions, the full reconstruction of what you bring becomes too expensive - in time. No one can afford, or believes they can afford, to begin here from zero each time. So the system, almost inevitably, develops ways to compress the time usually required to build enough trust to make decisions and move quickly.

And once compressed, trust begins to reside inside signals.

This is not, in itself, dishonest. Nor is it necessarily superficial in the way critics of prestige systems often prefer to imagine. It is functional. It is what fast systems do when they can no longer bear the cost of full inquiry. They convert trust into shorthand, and shorthand into speed.

Think of it the way you encountered my name at the beginning: five letters, immediately decoded by anyone who knows the code. But if you have never encountered that code before, you need two paragraphs just to understand who I am and why I am writing this at all.

Because my five-letter code arrives from outside of your local signal system.

The Encoding Gap

I’ve built systems where external actors drove measurable outcomes, not just engagement.

There are, for instance, at least two ways I can describe the work I have done when faced with the familiar question, “So what do you do?”

One version is compressed into metric:

“Co-founded a multi-sided platform that supported 400+ startups, representing roughly two-thirds of new fast-scaling company formation in an emerging European market.”

Another version is closer to the actual labor from which those numbers emerged:

“Built from 0 to 1 a founder-centric accelerator and cross-border ecosystem connecting” startups, investors, institutions, and corporate partners across different markets.

The first statement possesses the advantage of number. Numbers travel better because they seem to require less patience. They present themselves as already distilled. But even there, one number from one system does not automatically calibrate inside another. Scale in the Bay Area is measured against its own mythology of scale. A real number may still arrive looking strangely sized, too small or large to dismiss, too unfamiliar to trust at once.

The second statement is, in some ways, more faithful. It contains more of the formula to hidden architecture: the stitching together of actors whose incentives do not naturally align, the building of trust where none existed, the constant translation between founders, institutions, markets, and logics that do not move at the same speed or answer to the same pressures. But because it is more faithful, it is also slower to absorb – it requires time and attention. And time, in a fast system like this one, is precisely what is most jealously rationed.

Many people who build across borders find themselves living inside that distance longer than they expected. They are not lacking in substance, more often they are just simply unread. Their work has not yet been encoded into forms that the new market knows how to trust quickly. And because the market confuses speed with clarity more often than it admits, anything that cannot be grasped immediately risks being treated as though it lacked force from the beginning.

Translation helps, of course, but it is never free. It costs time, compression, surrender of nuance, repeated acts of simplification that sometimes clarify and sometimes distort. One learns quickly that the more explanation a piece of work requires, the weaker its opening signal becomes, no matter how substantial the work itself may have been.

I did not always understand this as clearly as I do now. That, too, is part of this story.

The Badge

I have stood on both sides of the badge. I have carried one, and later I have looked for it in others. It taught me things that being on the side of aspiration never could. It taught me, among other things, how easily one can mistake familiar signals for durable competence.

Most of the important turns in my own career came through open calls, not through intimate access to power. When I entered roles that stretched what I knew, I treated the gap not as a threat to conceal but as a responsibility to address. I went back for a postgraduate degree while working full time and raising two young daughters, because I believed - and still believe - that ignorance inside responsibility is not something one waits passively for the ecosystem to forgive.

That pattern repeated itself often enough to become my principle. Learn quickly. Own the gap. Earn the position forward. Celebrate and share success.

And yet when I later began hiring for the success of my own company, I discovered in myself an assumption so common that for a long time it passed as common sense. I believed that people who came from stronger brands, clearer institutions, more recognizable systems, would require less translation and move faster once inside the innovation. I believed, in other words, that the badge was carrying the person.

I was wrong more often than I was right.

Once that structure is removed, once the person no longer stands inside the institutional architecture, the brand that helped make them legible, things become clearer very quickly. The old language is no longer enough. Once the terms shift, the familiar references stop translating and the resources thin. No one nearby is quietly lending credibility to the moment anymore. And then the question presents itself in its simplest form: what remains when that brand recognition falls away?

What travels across institutions, markets, roles, and borders is not the badge, but the person behind it.

Why Trust Doesn’t Travel

There are moments when you arrive somewhere new and realize that what once seemed enough to open a door now barely introduces itself. What once passed as obvious must now explain why it deserves to be understood.

In time, this becomes its own kind of discipline, almost its own craft: not self-promotion exactly, and not performance, though it occasionally resembles both, but something closer to translation under pressure. One learns to place one’s work into a new setting carefully, patiently, repeatedly, until it begins to make sense there not as imported prestige, not as a foreign object asking indulgence, but as something that can live within the receiving system’s own logic without surrendering its original truth entirely.

Systems continue to move. Markets revise what they reward. What is legible today may become noise tomorrow. A person can spend years building a language for their work, only to discover that the audience has learned a different dialect in the meantime.

Trust cannot be manufactured through transaction alone, however often modern systems try. Nor can it be permanently outsourced to a logo, an institution, or a status marker, however efficient that may seem in the short term. Such signals can create motion, compress hesitation, and accelerate contact. But the deeper forms of trust - the ones that matter once circumstances change, once pressure arrives, once the room is no longer being instructed by prestige how to interpret what stands before it - are built elsewhere, and more slowly.

They are built in repeated moments.

The repeated moments are the conversation after the official meeting is over, celebrating time when something works in production and everyone involved knows how much invisible labor was required to get there.

That is the part that travels.

It is not perfect, I know. And it is not quickly.

But it will get you further than the badge.

Surprise….

From Berkeley. Working inside the systems. Encoding.

That all works.

In fact, many accelerators hand startups something remarkable early on: access to hundreds of thousands of dollars in free infrastructure credits from different service providers, and no strings attached. I mean, it is great what startups get from the partnership, once they enroll in an accelerator programs - founders start experimenting at no cost, and the best teams emerge for the right infrastructure partner.

That certainly works to build strong startup engagement and it is an attractive pull into the accelerator program, but it doesn’t necessarily translate into what infra providers actually care about.

There is a gap that shows up later - after the acceleration program ends - because startup engagement in the program doesn’t necessarily mean the commitment to use a specific infrastructure. And the activity in the program may not always lead to actual partner revenue, which is the actual driver for platforms building partnerships with accelerator programs.

So, over the past few weeks, in my meetings with founders, operators, and partners instead of asking how much they were raising, I switched to asking three simple question:

- What infrastructure are you running?

- When did you decide?

- How did you know which platform to choose?

The answers were more revealing than I expected.

The decision is no longer human-first

This may sound obvious to many if you are a tech person, build in the Bay Area. I come from the operator side, not the engineering side — but for most of my entrepreneurial career I’ve built with and around developer communities.

Most early-stage teams I spoke with are running across two or three cloud providers at once. Today, this is not by strategy – it is because each one offered credits through established accelerator partnerships, and there’s no reason to SAY NO when and if something is free.

When I asked CTOs how they chose which platform for what workload, the answer (as you can guess) that kept coming up was simple: they asked Claude Code or similar. AI coding tools read the documentation, test APIs, generate working code examples, and narrow the options down. The CTO simply follows the recommendation given by the AI coding tool without spending much time on evaluation and future projections.

This is how decision gets made in 2026 - the first pass happens well before a human engineer gets deeply involved.

For any infrastructure partner provider, the implication is direct: if your documentation is locked behind a login, uses inconsistent formatting, or lacks working code examples, you may not make it into the AI-generated shortlist at all. How quickly infrastructure platform demonstrates real value to what the startup is building has quietly become a new competitive variable in the market of platform providers – it is not just about competing for developer experience, but for whether the platform gets evaluated in the first place.

On the other side of the coin, almost no early-stage founder I spoke with is thinking about infrastructure cost beyond the free credit period. I mean, they are too early and have other priorities. They optimize for speed and certainty, so they are not considering infrastructure cost as a potential problem. The thinking is to solve it later with capital, which they haven’t even raised yet.

Don’t get me wrong, I am not saying this as a criticism – it’s the right thinking and it’s just where their attention has to be at that stage where they are at.

But what this creates is a predictable gap in partnerships between accelerator programs and infrastructure platform partners serving them.

Where the partnership is lost

1. Free credits create activity, but not architecture commitment

Accelerator programs are mostly designed for building cohort energy. Founders are given credits to use and explore, remove friction and test different infrastructure options. That all makes a lot of sense and builds a strong value proposition from the accelerator’s side.

The question from the platfrom partner is: when is the real infrastructure decision actually made?

It happens later - when something begins to work, the team needs to push toward production, and CTO has to make a real call about where this system holds. But is that moment within the acceleration program’s objectives and outcomes?

That decision is quiet, internal, technical and time-sensitive. Often completely disconnected from acceleration program timeline.

2. The relationship ends before the partner value shows up

Most acceleration programs are designed around startup entry:

· onboarding

· workshops

· demo day

But the critical phase - the one that matters most for defending and justifying infrastructure partnerships - sits somewhere in the middle of the startup journey:

· first deployment

· first real usage

· first failure under production load

When the acceleration program ends, the structured relationship fades. Slack channels go quiet. And with it, any visibility into what actually happened to those free credits.

This is where platform confidence is either built or lost. Most acceleration programs disappear at exactly the moment when the right infrastructure wins.

This is not just an accelerator problem. Venture partners face the same visibility gap. They refer portfolio companies into programs, credits get issued, and then the trail goes cold. The accelerators that build durable infrastructure partnerships are the ones that close this loop - giving venture partners clear signals of how their portfolio is actually adopting and using the platform. That’s what turns a VC referral into a repeatable channel, not a one-time introduction.

3. Startup stage segmentation

Accelerators mix cohorts of different startup stages to build their numbers: pre-product, post-MVP, and early-revenue - and these are fundamentally different conversations for building on the right platform.

· Pre-product teams are exploring and don’t make real infrastructure commitments.

· Post-MVP teams are still validating what holds.

Only a narrow segment - usually early-revenue startup teams with something working that needs to scale – is actually positioned to commit to the right infra platform.

When acceleration programs treat all three startup stages equally, activity looks strong but conversion stays low. This leads to partnership questions that are hard to answer. So even when the pipeline looks healthy, the number that actually matter for partnership longevity is the number of those startup workloads still running after free credits expire.

What actually moves the partnership outcome

1. Startup activation vs. conversion

The first partnership milestone is typically evaluated by platform accounts created. The next is credits activated and used. But the key milestone for evaluating whether the partnership is working is a real workload running on the platform.

If a team doesn’t deploy something meaningful early, the probability of long-term adoption drops sharply. If that doesn’t happen early, the decision drifts.

2. The first deployment vs. real usage

Demo day is not the finish line. It’s actually where the proof of partnership really starts and gets evaluated.

Accelerators that build a structured layer of startup tracking after the cohort ends bring partners strong technical engagement, which is tied to where the product actually is - and not just generic check-ins on fundraising progress.

Accelerators must be present in that post-program phase to justify and better negotiate infrastructure partner deals. They need to be there when the CTO makes the decision about which platform production will run on - not just at the kickoff when all the options are still on the table.

This is where most program tracking disappears - in the gap between first deployment and sustained usage. First deployment is about whether a CTO builds confidence or goes back to searching. But the real moment that matters for partnership negotiations is when that workload converts into real, repeated platform usage.

3. Metrics that reflect reality of a good partnership

So in conclusion, the fact is that most accelerator partnerships are tracked on what is easy to measure:

- Total credits issued per cohort

- Number of startups onboarded on the platform

These inputs don’t necessarily indicate what makes a successful partnership between an acceleration program and infrastructure partner.

The metrics I would say actually matter are:

· When did the startup commit to the platform, not just sign up on it - adoption vs. activation

· The growth of infrastructure usage after credits expire - efficiency vs. subsidy

And while these two are strong indicators of real adoption, they are most powerful when combined with broader health indicators:

· Startup Net Revenue Retention (NRR): whether existing customers stay and increase spending on the platform

· CAC Payback Period: how quickly the cost of acquiring a customer is recovered

· Startup’s Burn Rate / Runway: how quickly cash is being spent

These aren’t always metrics the accelerator directly owns - but they are the only ones that indicate whether the partnership with an infra providee truly worked.

Everything else is activity.

The shift that is already happening

Running a multi-sided accelerator platform for over a decade - activating more than a thousand founders, supporting hundreds of startups, and building the partner relationships that had to justify themselves without large credit budgets or brand alone - I learned early that an accelerator is not just an educational program. It is, in essence, a marketplace: an intermediary creating value between two sides that need each other but can’t easily find each other alone.

One side is building a product - startups serving as the supply. The other is understanding and building the right partnerships - the demand.

Accelerators are intermediaries that thrive on network effects, where the value of partnerships increases as more high-quality participants join on either side. The fundamental differentiator between top-tier accelerators — those that drive real engagement and revenue — and lower-tier ones is operational design: the ability to foster, test, and act on clear signals of startup commitment, rather than relying solely on brand reputation or cohort size.

The moment where infrastructure matters is getting shorter and more consequential. Once something works in production, switching becomes harder. If partners are not tracking where the infrastructure decision lands, they are not operating a growth channel — they are measuring traffic that doesn’t translate into measurable revenue.

From Berkeley.

From inside the rooms.

Still learning, still adapting - but not starting from zero.

Nenad Moslavac

There is a question that keeps surfacing in rooms like the one I was in last week in Berkeley - rarely asked directly, but present in almost every conversation.

The event, hosted by Berkeley Quantum Nexus and Berkeley Gateway Accelerator within the UC Berkeley ecosystem, moved across how quantum algorithm works, what is the infrastructure, and where are the very early applications, all making one thing clear: the technology is advancing in ways that are real and measurable. Quantum sensors are already generating biological datasets that did not exist before, opening new paths in areas like cancer research and drug discovery. At the same time, the question of where quantum creates a clear commercial advantage over classical systems remains open.

So the uncertainty is not about whether progress is happening.

It is about what that progress becomes.

Listening to that conversation, I kept returning to a pattern I have been seeing over the past year while working with European deep-tech founders moving through the Bay Area, where the transition from research to company consistently turns out to be less a question of capability and more a question of timing.

The issue is not technical strength. Across Switzerland, Germany, the Nordics, and increasingly Central and Eastern Europe, the research is serious and holds up in any global context. But strength at the level of research does not resolve the question of when and how that work becomes legible as a company in a venture-driven environment.

In the Bay Area, there is an implicit expectation shaping most investor conversations: by the time a founder is in the room, the company has already moved beyond exploration. Not only technically, but commercially. There is a clear view of where it enters the market, who cares about it, and why it matters now.

European systems extend the phase before that point. There is more room for exploration, more institutional support, and longer validation cycles through research partnerships and public programs. That environment allows the technology to mature, but it also stretches the timeline for making market-facing decisions in ways that do not translate cleanly when founders step into a different context.

What follows is not a failure of quality, but a misalignment of timing.

Often an European founder arrives with everything in place: prototypes, patents, years of serious work. The conversation holds until it shifts toward the first customer, the initial market wedge, or the commercial trajectory over the next year. The answers become less defined, not because the thinking is weak, but because those questions are arriving earlier than the company is used to.

In many other cases, the situation here is reversed. A U.S. company has already spent years building, with working products, pilots, partnerships, and sometimes revenue, but within systems that reward longer cycles and broader validation. By the time it reaches the Bay Area, it is no longer early, but it is also not aligned with what this market expects: speed of distribution, clarity of entry, and a defined thesis on where and why it wins.

At that point, the challenge is no longer about proving the technology works, but about adjusting how the company operates, which is significantly harder because it requires undoing patterns that are already established.

There is a concept in quantum cybersecurity often described as “harvest now, decrypt later,” where data is collected today with the expectation that it can be unlocked in the future. What I see with European deep-tech founders is almost the inverse. The window to establish a position in the U.S. market often opens before the technology feels fully ready, and closes before the company fully recognizes that it needed to move.

From the outside, being too early and being too late can look similar. In both cases, the company does not meet the market at the moment when the market is ready to engage.

Having spent more than a decade building within European ecosystems and now being based in Berkeley, this contrast is difficult to ignore. European systems are structured to support founders and extend development timelines, while the Bay Area is structured to accelerate markets and compress them.

That difference shapes how companies evolve, and what investors expect to see when a founder walks into the room. It is also why places like Berkeley are worth watching closely right now, with programs like SkyDeck and Berkeley Gateway, and institutions like CITRIS and Bakar Labs, working at the interface between research and commercialization, not only connecting founders to capital, but forcing earlier clarity on what kind of company is actually being built, and whether it is ready for the market it is entering.

The underlying question is the same across all of these conversations, even when it goes unspoken: not whether the technology will work, but whether it arrives at a moment when the market is ready to respond.

Most deep-tech failure is framed as a problem of technology or capital.

More often, it is a problem of timing.

I am based in Berkeley, working at the intersection of European startups and Bay Area capital - specifically the gap between how these companies develop and what investors actually look for when founders walk in the room. If you are navigating this from either side, I would be glad to talk.

What does it mean to speak Bay Area native? And how can “rare” become a wanted asset in a crowded room - rather than just a polite way of saying “equal as invisible”?

It took me some time to understand: I thought fluency in the specific terms and vernacular that shift across industries was the finish line. Learn the vocabulary, internalize the pitch format, decode the thirty-second introduction, show up in the right rooms with the right questions.

Most of us Europeans would agree that being “rare” sounds like a compliment. Especially if you are - like me - coming from the Western Balkans, we always think being rare is what makes us so special. It isn’t. At least not here.

Rare, in the Bay Area, means something very precise and often uncomfortable: valuable in the abstract, invisible in practice. Think of it like an expensive, authentic spice from abroad on a shelf next to salt and pepper

.

As Stevo would say in Little Secrets of Great Culinary Masters: “... and one tablespoon of Vegeta!”

The spice is real. The quality is real. But if you are not from the Balkans, you likely do not know what to cook with Vegeta, do not have time to find out, and are already moving toward another, more familiar food seasoning you used before.

The problem here is the missing label. The missing recipe. The missing context that transforms rareness into wanted.

The problem is the lack of experience.

This is another challenge nobody warns you about - and in some ways it is more disorienting than the vocabulary friction I wrote about last time. Yes, you can solve a vocabulary problem. But what comes after it is harder, less documented, and almost nobody is writing about it from inside the room.

So let me try.

Four Rooms. Four Different Problems.

In the past few weeks I have been in four different rooms where founders were pitching, networking, and trying to find their footing in the Bay Area: Swissnex. Innovit. European Startup Embassy (ESE). Berkeley SkyDeck. Each room had a different relationship to the same language. Here is what I observed.

The Swiss Room: Leading Without Translation

A founder stands up. Deep health-tech, serious engineering, institutional backing from a respected Swiss university. The slide deck is built with precision. The pitch runs five minutes. Technology architecture, regulatory landscape in Switzerland, academic partnerships, roadmap through 2028.

There is no ask.

Not because they forgot. As a European founders we build the case first and expect the ask to emerge naturally from the evidence. Europeans don’t lead with the ask. But not asking is missing an opportunity to engage with the audience.

In a Bay Area room, that approach reads as noise. Not in a bad sense - not because the content is weak - it is stronger than most of what walks through accelerator doors here. But the Bay Area operates on a different protocol: you need signal before context, ask before architecture, and you will have only thirty seconds to earn your next thirty seconds.

I have a decade of experience working with European founders backed by Swiss government programs and innovation initiatives. They all build great products. But here, like so many other Europeans, Swiss remain untranslated. And untranslated, in this ecosystem, is functionally the same as silent.

The Bridging Room: The Code Without the Key

One of the most interesting rooms I have been in recently is the European Startup Embassy (ESE). It brings together a rare mix of operators, ecosystem builders, advisors, investors, and CEE European founders in a way that most Bay Area rooms simply do not. That diversity is exactly its strength.

Which is why one moment stood out.

A European founder walks up. Smart, ambitious, clearly done the research. Their opening question: “Hi, so what do you do - are you an investor, a founder, or operator?”

The words were perfectly chosen. The understanding behind them was not.

That night, the room was full of European operators, ecosystem builders, advisors, connectors - people whose value does not fit into Bay Area investor, founder, or what are you building. By importing the typical YC triage question into a bridging room, the most useful people in it get quietly excluded.

The damage is invisible to the person causing it. And that invisibility - that gap between speaking the code and holding the key to it - is the most common and most costly mistake I observe in European founders trying to operate here.

They have learned the vocabulary. They have not learned what the vocabulary is doing.

The Italian Room: Leading With Brand

This one surprised me. Over 20 years I have been naturalized Italian in many ways, but being born and raised in Serbia I keep that bias carefully aside. What I observed is genuine.

Italian founders, like so many other Europeans, also don’t translate. They have a hard time compressing. But they naturally carry something else into the room: brand.

They have the ability to make something feel considered and inevitable at the same time. Design intelligence. Craft. Aesthetic clarity.

So it clicked to me right away - think of your brand as positive friction. The kind that makes someone lean in rather than step back. Every European founder arrives here with an original sub-brand, but we quickly forget about it in trying so hard to look and sound like a Bay native.

Your signal enters the room before you do. You can shape it or ignore it — but you cannot stop it.

The SkyDeck Room: Bay Area Native

In a Berkeley SkyDeck room, the code is internalized. The thirty-second introduction is not a summary of your background - it is a designed object. Every word is load-bearing.

Opening with the problem first.

Solution comes quickly, without evidence yet.

Ask is early, before the actual roadmap.

Velocity is high and signals: “I respect your time, I know what I am here for, and I am not going to make you work to understand me.”

Signal maximized. Friction minimized. Latency — the delay between what you say and what the person in front of you understands — is zero.

Fluency is the entry ticket. Not the finish line.

What the Words Are Actually Doing

Let me try to decode four terms I heard in almost every room. I believe the gap between how Europeans hear them and what they actually compress is where most of the friction lives.

Signal.

In engineering, signal is the meaningful information in a transmission. In Bay Area rooms, it is applied to people, pitches, and presence. When someone says “that’s a strong signal” they are not complimenting clarity. They are saying: this input is meaningful enough to act on. High signal means low noise. If what you say requires further explanation, it is not signal yet.

Noise.

Everything after your first intro that requires further clarification means your signal is harder to receive. Unnecessary context, defensive qualifications, features before problems, credentials before relevance. Multiple asks at once, stories that require the listener to hold too much. Most of us European founders are trained in contexts where thoroughness is a virtue — so when we arrive in Bay Area rooms, we are naturally perceived as producing noise while we believe we are producing signal.

Friction.

The resistance between where you are and where you want the conversation to go. Sometimes, the friction is positive — the European brand can create productive friction, the kind that makes someone curious rather than impatient. But the sooner you exit from it, the better. Most friction is negative: it requires time for someone to think hard to understand you, to perform a translation they did not sign up for. Zero friction does not mean zero substance.

Latency.

The delay between your introduction and the room understanding your value. In a Bay Area network, high latency means slow processing. If it takes three weeks of LinkedIn silence after you met someone, you know you lost it. The goal here is zero latency: immediately legible, immediately actionable, immediately worth a follow-up. Or at least within the first day or two.

These are not Bay Area buzzwords. They are the operating system. European founders who internalize this — not just intellectually but in the way they enter a room — operate at full capacity here.

The rest keep wondering why the meetings do not convert.

The Real Question: How Much Indigenous Do You Have in You?

I am not saying European founders should change what and who we are. We have to change our “how.”

We are a rare spice — not salt and not pepper. We stay rare. But there is real work on our label. What we need to do is the translation work beforehand, so the room does not have to.

That is not dilution. That is craft. That is real work. The room here has a different operating system. Your job is not to replace yours. Your job is to write the interface layer.

What Comes After Fluency

Honestly, I do not have a clean answer. I am living it in real time.

What I noticed so far: it requires presence.

It requires building context that makes your credibility legible here. It requires people who understand both ecosystems and can bridge them. Most importantly — it requires showing up in the same rooms repeatedly until the room returns to expect you.

Don’t take “Rare” as a compliment. It is a brief description of the distance still to travel.

I am traveling it.

From Berkeley.

From inside the rooms.

Staying indigenous to my roots - and clear about why I am here.

— Nenad Moslavac

Berkeley, California

March 2026