DEV Community: Yan Nerovny

Why most startup communities are trash (and what actually works)

Yan Nerovny — Wed, 02 Sep 2026 00:51:36 +0000

I started running events for founders because the ones I was going to were bad. Since then Unicorn Embassy has put on more than 180 of them across nine cities in seven countries, and around six thousand people have walked through the door. That is a reasonable sample of what makes a room work, and a much larger sample of what kills one.

Most founder communities die quietly. The chat slows down, then stops. The monthly meetup becomes quarterly, then stops. Nobody announces it. Six months later the group still exists and nobody has opened it since spring.

The pattern repeats because building a community is easy to announce and brutal to sustain. Everyone wants one. Almost nobody wants the part where you do the same unglamorous thing every month for three years.

The five failure modes

Every dead community I have seen went one of five ways. Most managed several at once.

The spam channel

Someone creates a WhatsApp or Telegram group, adds 200 people, and calls it a community. Within a week it is a stream of self-promotion: check out my new app, looking for a technical cofounder, anyone know a good lawyer in Dubai. Nobody responds to anyone else's posts. Two hundred members, zero conversations.

The moderator, if there is one, occasionally posts a motivational quote or shares a TechCrunch link. Every member has notifications muted by day ten. The group exists in name only.

LinkedIn theatre

You have seen this event. Startup Networking Night at a rooftop bar. A panel of four people who work in innovation at large companies discussing the future of entrepreneurship. The audience is mostly people trying to sell services to startups, plus a minority of actual founders who came hoping to meet each other.

Afterwards there is networking, which means standing in clusters, exchanging cards nobody will follow up on, and asking what are you working on. The event produces excellent LinkedIn posts and no relationships. The organiser adds it to their portfolio of community building.

The dead alumni network

An accelerator runs a three-month programme. Demo day happens, everyone claps, the organisers create an alumni Slack and promise lifelong community. Six months later it is a ghost town where the only posts come from the accelerator promoting its next cohort.

The reason is structural. The accelerator is paid to recruit the next batch, not to serve the last one, so the alumni network is a marketing asset that nobody maintains. Whatever relationships formed during the programme survive on their own merits, and the community adds nothing to them.

The sales floor

Some communities exist as lead generation for their sponsors. Keynotes come from a cloud provider or a dev tools company. The Slack has channels dominated by vendor announcements. Meetups are held at corporate offices and open with twenty minutes of product demo.

Founders who show up once do not come back, because they wanted peers and got pitched. The organiser can live with that, because the community's real customers are the sponsors. The whole thing is a funnel wearing the costume of a gathering.

The blind leading the blind

The most frustrating category: founder communities run by people who have never founded anything. Career community managers, corporate innovation consultants, aspiring entrepreneurs who worked out that organising events is easier than building a product.

They usually mean well. They also cannot recognise the real problems in the room, because they have never had those problems. The advice they facilitate is generic, the introductions they make are shallow, and the events they run optimise for how the evening photographs.

What makes a real community work

The harder question is what the good ones do differently. In my experience it comes down to five structural decisions, and most organisers refuse to make any of them.

Say no to most people

The most counterintuitive principle in community building is to keep it small enough to matter. Five thousand people who do not know each other are a mailing list. A hundred and fifty who recognise each other by name are a network.

That requires selection, and selection is uncomfortable, because it means turning away people whose presence would make your numbers look better. You need a clear picture of who the community is for and the discipline to hold it.

At Unicorn Embassy we screen members on intent rather than on net worth or stage. Are you actually building something, and are you willing to help other people who are? Two no's and this is the wrong room. That sounds harsh until you attend once and notice that every person you talk to is worth talking to.

Show up regularly, in person

Online is a supplement. The foundation is repeated physical contact on a schedule people can plan around.

Frequency is doing something specific here. The first time you meet someone you exchange pleasantries. The third time you start describing an actual problem. By the fifth you will ask for help, offer an introduction, or say something honest that costs you a little. You cannot skip to the fifth meeting.

We run events in nine cities and the local leads hold a cadence regardless of whether a sponsor is paying that month. Reliability is what converts an attendee into a member.

Make real stakes flow through

There is a simple test for whether a community is worth anything: does real business happen inside it? Jobs filled, deals closed, investments made, partnerships formed.

Most communities fail this test and produce pleasant conversation instead. The good ones become infrastructure. A founder says they need a CTO who has shipped in fintech, and three people in the room have a name. An investor asks about a market segment, and someone who has operated in it for three years offers a call on Thursday.

This is downstream of the first two decisions. Real opportunities only enter a network when the right people are in it and they trust each other enough to hand something valuable over.

Build mutual obligation

In a functioning community people help each other because that is the norm, not because they are keeping a ledger. I will read your deck because someone read mine. I will make the introduction because someone made mine.

Most networking runs the other way, with everyone trying to extract. Here the expectation is that you contribute first. Members who only take get noticed quickly and drift out on their own, which is the immune system working as designed.

The strongest groups I have been in have an almost physical sense of reciprocity: people show up partly because they owe the room something. You cannot manufacture that with gamification or engagement tactics. It accumulates from small good interactions repeated over years.

Organizers with skin in the game

The people running a founder community should have built something. This is about recognition, not credentials. Someone who has raised a round, hired badly, lost a key customer and made payroll anyway will hear what a founder is actually saying under the sentence they said out loud.

Our city leads are founders and operators running their own businesses. They are building the community they wanted when they were starting out, which produces a different kind of event, because the organiser is also a user.

How Unicorn Embassy is built around these principles

We did not arrive at these by reasoning. We tried the conventional approach first, watched the parts that did not work fall off, and kept what survived.

Free events

We do not sell tickets. Charging for entry filters for people with an event budget rather than people building something. The community is the product; the event is how you get into it.

Screened membership

We review who joins. It is more work than an open door, and it is the reason a conversation at one of our events starts from a decent baseline instead of twenty minutes with someone selling marketing services.

Nine cities, local leads

Yerevan, Tbilisi, Batumi, Istanbul, Valencia, Barcelona, Belgrade, Dubai, Bali. Each city has a lead who lives there, builds there, and knows who is worth introducing to whom. A remote community manager watching a dashboard cannot do that job.

Recurring events

Pitch sessions, roundtables, ordinary meetups. Often enough that faces become familiar, which is where trust compounds.

Real follow-up

After an event we make specific introductions based on conversations we watched happen: founder to investor, founder to a possible hire, founder to another founder with the missing half of the problem.

Around six thousand people have come through those rooms. Not as names in a Slack, but as people who put on a jacket and turned up somewhere with other founders. The difference between those two numbers is the whole subject of this piece.

The community you actually need

You do not need a big one. Five founders who understand what you are currently going through beat five thousand names in a Telegram group.

A good community should leave you slightly uncomfortable, because the bar in the room is above where you are. You should walk out thinking you need to work harder or rethink something, rather than that it was a nice evening. A group that only ever affirms you is not helping you.

Four signals to check. Do the organisers know members by name? Do the same faces come back month after month? Have funding, hires or partnerships actually happened through it? Is it clear who the group is for? If most answers are no, you are in a mailing list. Leave.

What "building community" actually costs

The word has been diluted into nothing. Everyone is building a community around their product, or launching one for founders in some sector. A Slack workspace with channels is a distribution channel. So is a newsletter with a Discord link at the bottom, and a monthly webinar series. Useful things, all of them, and none of them a community.

Community is what happens when people turn up repeatedly, help each other without keeping score, and start to feel they owe the group something. It takes physical presence, uncomfortable curation, and years of doing the unglamorous version. The reason most people quit is that there is no shortcut in that sentence, and running the thing is one of the most thankless jobs in the startup world.

The people who stay do it because they think the room itself is the point, rather than a funnel or a line in a portfolio. A group of people who are measurably better off because they found each other is a strange thing to build, and it is worth more than almost anything else you can put in a city.

If that is the room you have been looking for, come to one and see whether it holds up.

Originally published at Unicorn Embassy.

Unicorn Embassy runs founder events in nine cities across seven countries: Yerevan, Tbilisi, Batumi, Istanbul, Valencia, Barcelona, Belgrade, Dubai, Bali. 180+ events, 6,000+ people through the door, zero paid acquisition. More writing at unicornembassy.com/en/insights.

Written by Yan Nerovny, founder of Unicorn Embassy. nerovny.com

Mercury rejected you. Here is the math behind it, and what to do next

Yan Nerovny — Tue, 01 Sep 2026 00:24:03 +0000

The email arrives. "Mercury will not be able to support your business at this time. We will not be able to provide additional details about this decision." You spend the next two weeks building an appeal: residence permit, business plan, tax registration, customer contracts, the whole file. You attach a polite cover letter explaining that you are not in Russia, not a sanctioned individual, fully compliant. Mercury either does not respond or sends the same boilerplate back. By week three you have decided you did something wrong, that your business is somehow tainted, that you will never get a US bank account.

None of that is true. The reject was a system response, and once you can see the arithmetic driving it, the next move gets obvious and the spiral stops.

The math behind an auto-decline

OFAC violation penalties start at roughly $1 million per transaction. The annual revenue from a single diaspora-founder account at Mercury sits somewhere between $50 and $500. On top of that sits reputational risk: one Bloomberg story about "the fintech serving sanctioned Russians" damages the next funding round, strains banking partner relationships, and invites regulatory attention.

Run those numbers and an auto-decline on an RU or BY passport signal becomes the rational move for the fintech, even when the overwhelming majority of flagged applications are perfectly legal. The downside of a single miss outweighs the upside of correctly clearing every legal applicant. What you are looking at is a company optimising against an asymmetry: maximum downside, minimal upside, per application. There is no judgement of you anywhere in that calculation.

How the decline actually happens

A KYC submission includes a passport scan, residence permit, and business documents. The decisioning system flags an RU or BY passport regardless of where you live, how the company is structured, or where the revenue comes from. Human review exists, but it triggers only when the signal-to-noise ratio is exceptionally clean, and most diaspora-founder profiles never escalate that far. The signal stays on the passport.

Why appeals do not work

When you appeal, your file lands with a human reviewer working inside the same policy framework as the algorithm. The reviewer is not asking whether you are legal. They are asking one question: can I defend this decision in a single sentence if a regulator calls. Your residence permit, your contracts and your tax records do not answer that question, so the system risk stays exactly where it was. The reviewer rejects again, usually faster than the first decision, because they are not rerunning the evaluation. They are confirming the flag was applied correctly.

That is why founders who have appealed three times keep getting the same email. Better writing will not move it. The framework has no path to yes for the profile.

What works instead

Three options, in the order most founders should think about them.

1. Use a second passport, if you have one

Israeli, Armenian, Georgian, Kazakh, Ukrainian (still workable on some applications), or any non-RU/BY document. Submit that one as your primary KYC. A lot of diaspora founders picked up a second citizenship over the past five years, and this is the moment it pays for itself.

2. Skip Mercury

For US LLC banking in 2026, Relay Financial is the most active replacement. It accepts most non-US founders, including a meaningful share of RU and BY passport holders with non-sanctioned residence. Novo is the bootstrapped option: free tier, about a week to set up. Bluevine works if you have an SSN or ITIN. (The earlier piece on Stripe Atlas vs Firstbase vs doola covers the incorporation side.) The Mercury-shaped hole in your stack has working alternatives that skip the appeal dance entirely.

3. Ask whether you need a US LLC at all

If you live in Tbilisi, Yerevan or Belgrade and are not raising US VC in the next 18 months, Georgian Small Business Status, the Armenian 1% IT turnover tax or the Serbian pau≈°al will almost certainly serve you better than any Delaware structure. (The earlier piece on local sole-proprietor regimes has the comparison.) Plenty of founders only worked this out after spending $400 on Firstbase and three weeks on a doomed application, with the local option sitting there the whole time.

The seven days after the email

Day 1: do not appeal, and do not write the perfect cover letter. From Mercury's policy standpoint the reject was correct, and your time is worth more elsewhere.

Day 2: work out whether your actual business needs a US LLC, or whether local incorporation solves the same problem with a fraction of the friction.

Days 3 to 5: if you need the US LLC, apply to Relay or Novo with realistic expectations and clean documentation. If you do not, plan the local setup instead.

Days 6 and 7: if you have decided against the US LLC and already formed one through Firstbase or Stripe Atlas, contact them about closing it out. Both have refund or pro-rata mechanisms in the first 30 days for most situations.

This is structural

Fintechs are doing the arithmetic their compliance teams force on them. The email reads impersonal because the decision was impersonal: OFAC penalties dwarf the revenue from a founder account, and the policy math has no yes-path for your profile. Nothing about your business is tainted and nothing about your profile is broken. You do not owe proof of legitimacy to a system that never asked for it. Plan around the math.

Originally published at Unicorn Embassy.

Unicorn Embassy is a founder community across nine cities and seven countries: Yerevan, Tbilisi, Batumi, Istanbul, Valencia, Barcelona, Belgrade, Dubai, Bali. 180+ events, zero paid acquisition. More founder-ops writing at unicornembassy.com/en/insights.

Written by Yan Nerovny, founder of Unicorn Embassy. nerovny.com

AI-powered PM vs AI-native PM: what the difference is, and who survives it

Yan Nerovny — Mon, 31 Aug 2026 23:10:26 +0000

"I can prompt ChatGPT" is not AI-native. It's AI-powered, and in a year or so it'll be like knowing how to use Jira: table stakes, not what you get paid for. I look at hiring product people from both sides at once - I'm looking for a Head of Product role myself, and I interview people for my own projects. And I watch the market start to separate two kinds of PM that still get lumped together under the buzzword "AI PM." The difference isn't cosmetic. In a couple of years it'll decide who gets called for Head of Product, and who gets asked what makes them faster than a junior with a Claude subscription.

Let me lay out how I tell them apart. Then a self-check, then how to move if you land on the wrong side.

AI-powered vs AI-native: where the line runs

An AI-powered PM bolts AI onto a process that hasn't changed. Same specs, same discovery, same roadmap - ChatGPT just writes the PRD in twenty minutes instead of two hours, and call notes summarize themselves. The work stayed the same, the tool got faster. It's a real upgrade, I'm not knocking it. But it's old work, sped up.

An AI-native PM rebuilds the process itself around one fact: generating is almost free now, and judgment is the scarce thing instead. When a prototype comes together in days, the bottleneck stops being "can we build it" and becomes "are we even right about the market." That doesn't change how fast the work goes. It changes what the work is.

I tell them apart on four things. This is the core - take it with you.

Where the bottleneck is. AI-powered speeds up the hands: writing, designing, summarizing. Its ceiling is how much it can produce. AI-native treats the hands as a near-solved problem and moves the scarcity up - into how often it's right. Its ceiling isn't "how fast I write a spec," it's "am I building the right thing."
What you hand to the machine. AI-powered hands off tasks: write a draft, research competitors, fix the tone. AI-native hands off whole chunks of the process - not "write me this spec," but "run twenty versions of the feature and show me which three survived the check." You're not handing off typing. You're handing off the search.
How you decide. AI-powered decides on gut and spec: feels better, wrote it up, sent it to build. AI-native runs two passes: one part (often the AI itself) generates options, the other slams them against what's actually known, and a decision survives only if it passed. A hypothesis doesn't ride onto the roadmap until it's marked - what I know here, and what I just want.
The relationship to build. AI-powered orders a prototype from engineers and waits. AI-native builds a clickable version itself - in days, with agents - so a real prototype exposes the real problem faster than any document. Not to replace engineers. So discovery runs at the speed of thought, not the speed of a sprint.

Notice which of those has no word "tool" in it. Who opened ChatGPT and who opened Cursor misses the point entirely. The difference is where your bottleneck is, and whether you moved it on purpose.

A five-minute check - which one are you

This isn't a quiz for engagement, it's a self-check. Answer honestly, by your last real project, not by who you'd like to be.

When did AI last kill your idea instead of speeding it up? If it only produces for you and never cuts, you're AI-powered. AI-native runs hypotheses against AI on purpose, so the weak ones fall off before they reach the build.
Do you hand off tasks or chunks of the process? "Write a PRD" is a task. "Generate twenty versions and reject most" is a chunk. If you're still handing out tasks one by one, you sped up typing, you didn't rebuild the work.
Can you build a clickable prototype of your own idea by the end of the week, without a ticket to engineers? If every check runs into someone else's sprint, your discovery runs at the speed of someone else's calendar.
What do you hold onto when you defend a decision: "I feel it," or a layout that shows what's proven and what you just want to be true?
What do you do with what the AI gives you? If you take plausible for correct, you're a keyboard operator for now. Telling a good answer from a convincing one is the new job.

Three or more answers leaning "tasks / gut / waiting on engineers" - you're AI-powered. It's not a verdict. It's a start, and the move is shorter than it looks.

Why this decides a PM's career for the next couple of years

The logic is simple, no made-up stats. When design and code get cheap - and with real agents they're getting cheap fast - value drains out of the hands. Producing specs fast stops being rare. What gets rare is being right about the market before months are spent.

Hiring will follow with a lag - companies still count the old way, but the pain has already moved. A team no longer needs a fifth person who writes a PRD faster, AI closed that. It needs the one who won't let it build the wrong thing perfectly. AI-powered competes with a skill that's getting cheaper. AI-native competes for judgment, which AI doesn't close - it exposes it. When building is cheap, being wrong is expensive, and all the risk moves onto whoever decides what to build. More on that - why judgment becomes the work - here.

How to move from AI-powered to AI-native

The applicable part. Four moves, in order - you can start each this week.

Rebuild discovery around cheap generation. The old move is to pick one idea and write a PRD. The new one is to generate many and run them cheaply, since generating is almost free. You're after not the idea you like, but the one that survived the check. What that looks like end to end, I wrote up here, on how I run product with agents.

Set up a "know / looks like / want" layout. Every hypothesis - yours and the AI's - goes through three buckets before the roadmap: know (there's data, behavior, a pattern that holds), looks like (there's a signal, not proof), want (you just want it true). Anything in "want" gets a test: confirm or kill. Nothing rides into the build unmarked - your gut first. It's cheaper than any failed sprint and takes the worst error off your plate - building the wrong thing perfectly.

Learn to build the prototype yourself. Not a metaphor. I came into product from engineering - started in 2017 on JavaScript and React, about nine years in tech - so "build a clickable version over the weekend" is just opening Expo and an agent for me. If you don't have the background, agents collapse that barrier more than you'd think: a clickable prototype today comes together without deep code. The craft isn't the point. The point is that checking a hypothesis stops waiting on someone else's sprint.

Run two passes instead of one. Don't use AI as one head you trust. Use at least two: one generates options, the other slams them against the same layout and hunts for where it falls apart. I run this on two of my own things. Yan OS - my own set of agents with orchestration and checking - isn't finished, the client is still me, honestly. MERIDIAN - an app about your map of where you've been, which agents built into a clickable prototype in days the same way: one proposes, the other cuts, the survivor goes to build.

All four moves are about one thing - dragging your bottleneck off the speed of your hands and onto how often you're right. Do that and you're already on the other side, whatever your title says.

So the question isn't whether you can use AI. In a year everyone will, and it'll stop meaning anything. The question is whether you moved the bottleneck. AI-powered types the old work faster. AI-native changed what the work is. The market will stop confusing them soon - check which side you're on before it checks for you

Originally published at nerovny.com.

I'm Yan Nerovny - AI-native Technical Product Lead and Head of Product, founder of Unicorn Embassy (180+ events, 9 cities, 7 countries, zero paid acquisition). I write about product, AI and emigration at nerovny.com. Telegram @nerovny_blog.

Ran the five-minute check? Tell me which side you landed on - I'm curious where the market actually is.

I handed AI agents almost the whole product. Except one part - and that part is the job

Yan Nerovny — Sat, 01 Aug 2026 20:18:17 +0000

Recently an agent built a working prototype of MERIDIAN in a couple of days. A live page - where I've been, where I am, where next - plus a world map the app draws itself from the EXIF in your photo library, on-device, with zero manual input. Expo, React Native, a black SVG map. What would have taken a week of dense frontend a year ago was ready to screenshot-test the same day.

Here's what that speed did. It didn't remove the risk - it moved it. While code was expensive, the main question was "can we build it." Now building costs almost nothing, and one expensive question is left: am I even building the right thing. The risk moved off "make it" and onto "decide what to make."

So I rebuilt how I run product. Not around who writes the code - there's unlimited code now. Around who decides which code is worth writing at all. I barely write myself - I hand tasks to agents, check, and cut. Below is how it's wired. Not "look at my system," but something you can copy.

What the agents do, and what I hand to no one

The work is split into pieces. Each piece has an agent that carries the volume, and a piece I keep. The line between them is the whole job.

Discovery. Agents comb the market, competitors, user conversations, my own note archive - and pull out what I physically can't read in time. I keep one question for myself: which of these patterns am I willing to believe, and which just sound good.
Hypotheses. An agent spits out twenty versions of a feature faster than I write one. The volume is its. The taste is mine: which two of the twenty are even worth touching.
Decisions and priorities. Here the agent is a sparring partner, not a judge. It sorts hypotheses against what I actually know, argues, looks for holes. The final cut - what goes on the roadmap, what goes in the bin - is mine. It's irreversible, you don't delegate it.
Build. Claude Code and agents write the code, the design, the schemas. I read their output the way a senior reads a junior's PR: not "does it work," but "is the estimate lying, did they cut a corner that blows up in a month." I came into product from engineering - I started on JavaScript and React, then tech lead and eng management - and that's a tool now: I catch lies in code because I wrote code.
Review. A separate agent attacks what the first one built. Its job is to find where it falls apart. More on this below - it's the heart of the whole thing.
Orchestration. The layer holding the other five: which agent on which task, in what order, with what context. That's Yan OS - a layer on top of Claude Code: projects, agents, schemas, hooks, scheduled runs, a handful of MCPs. One conductor. Me.

Notice what I did NOT hand to agents: deciding what to believe, the final roadmap cut, and checking someone else's work for lies. Everything else is volume, and volume is cheap now.

How one agent catches another one lying

An agent left alone lies with confidence. It generates a hypothesis, justifies it, and serves it as fact - in the same tone it would use for the truth. So the one that generates and the one that checks are different in my setup. And between them sits a simple sort. Every claim - mine, a user's, an agent's - lands in one of three buckets:

know - real data, behavior, a pattern that holds.
looks like - a signal, not proof.
want it true - a wish, unconfirmed for now.

Anything in "want it true" gets a test attached: confirm or kill. Nothing rides into the build unmarked - and my own gut gets the hardest check, because it's the loudest.

Where this actually saves me. An agent proposes a feature and writes "users want X." The second one goes to the source and finds that "want" is one thread in one chat. That's "looks like," served as "know." Without the second agent that "want" would have rolled onto the roadmap dressed as data. With it - it gets a test and waits. Costs pennies, and catches the most expensive class of error: confident lying that looks like fact.

What the speed exposed on MERIDIAN

Back to the prototype, because the whole point is in it.

Before MERIDIAN I killed the previous hypothesis - Nomad Bridge, a two-sided marketplace for nomads. It didn't survive my own teardown: two sides, both needed from day one, the classic cold start that kills marketplaces, and the only paying demand I could find was by analogy, not by evidence. Inside that dead product sat a small feature I never took seriously - a profile page with a map of the countries you'd been to. I threw it out with everything else.

Then I spent a month looking for the next thing. Around 350 ideas, nine runs with agents, and in almost every run one motif kept surfacing - that same movement map. The feature already in my hands, that I hadn't seen.

Here's the trick. The agent built the prototype in days - and that speed is exactly what showed the hard part was never the code. The hard part was that I spent a month scoring 350 ideas on a spreadsheet and nearly missed what was in my pocket. When code was expensive, slow building masked the error in my head - you build so long you never notice you're building the wrong thing. When building got fast, the one real job was left naked: decide what's even worth building.

Where it breaks (without this part it's an ad)

Honest now, or everything above is just a nice shop window.

The client of this system is me. One user, who's also the developer, who's also the one who needs it. Which means the gains aren't proven by numbers - only that it suits me better, which is the weakest proof there is. Yan OS isn't finished and, honestly, by its nature never will be.

Next - an agent loves its own ideas. A second agent grown from the same model tends to love the first one's ideas a little more than it should. So I keep the final knife, not the second agent: it lowers the lying, it doesn't zero it.

Context costs money and attention. For an agent to judge well you have to feed it the right context, and gathering and keeping that context fresh is work nobody counts until it quietly eats the speed gain. A system that saves hours on the build easily returns them through the back door, on wrangling context.

And the main thing - I can't be replaced exactly where there's nothing to check against. An agent is brilliant when there's a reference to compare the answer to. When there's nothing to compare - when the question is "am I building the right thing" and the market hasn't answered yet - taste decides, appetite for risk, and willingness to carry a product for years. That doesn't hand off yet. The whole thing stands on it - more on that here: when building gets cheap, judgment becomes the job.

What a team buys when it hires a person

Put it together. When design and code are almost free, a team hiring a product person stops buying a pair of hands to execute a spec. There are unlimited hands now, and they're cheaper than any hire.

What gets bought is exactly what I didn't hand to agents: deciding what to believe, the discipline to kill your own hypotheses, and a nose for lying that sounds like fact. Not the person who writes a PRD faster. The one who runs the agents that write the PRD - and knows which one is worth building.

I built this alone, with agents - the same way I ran Unicorn Embassy for three years with zero ad spend. Building dropped to nothing. The price of judgment is the only thing that went up

I'm Yan Nerovny - product lead and founder of Unicorn Embassy. I write about product, AI and building from anywhere at nerovny.com/writing.

Running product with agents yourself? The part worth stealing is the three-bucket sort - known / looks-like / wanted-to-be-true. Tell me where it breaks for you: Telegram or LinkedIn.

180+ events, 9 cities, 7 countries, zero ad spend - here's what I learned about growth

Yan Nerovny — Sat, 01 Aug 2026 18:35:44 +0000

Kadıköy, Istanbul, a Sunday in 2023. The second floor of a Turkish guy's coffee shop, about thirty people packed in, someone standing in the aisle - strangers pitching each other their startups. My first event.

A year earlier I'd flown in from Russia - first time abroad in my life, first flight ever, not a soul I knew in the city. I built this room over that year myself, by hand, without spending a cent on ads. And over the next three years that same scene repeated 180+ times across 9 cities in 7 countries - still zero paid acquisition. This is Unicorn Embassy, and it's the cheapest way to gather an audience I know.

What follows is how it's done, step by step - not a memoir about how great I am. Behind the no-ads numbers sits a simple sequence I ran in every new city. And it's about growth in general, not just meetups.

Why community, not ads

I left Russia in 2022. Istanbul was the first country - you land and get a residence permit on the spot, you can't do that in Europe. I touched down without a single contact.

And I started showing up at other people's events. Other people's tech meetups, startup gatherings, Russian-speaking hangouts - anywhere they let me in. After a couple of months I noticed one thing: the people who show up in a community regularly end up with everything - projects, jobs, cofounders, investors. Not the smartest ones. The ones in the room.

So I decided to build the room myself. It's one of the most important decisions I've made, and I made it for a simple reason - not to be alone in a foreign country. The payoff came later: through those same communities I'd go on to find projects, cofounders, and work.

How I entered a new city, step by step

Here's what I actually did. Not theory - the sequence I repeated in Istanbul, then Belgrade, Dubai, Tbilisi, Yerevan. The city changed, the mechanics didn't.

Walk every local event. First you're a guest at other people's events. It's recon and networking at once: you see who speaks here, and you meet the people you'll invite later.
Pull speakers straight from there. A good talk at someone else's meetup is a ready speaker for yours. You don't hunt speakers in a vacuum, you take them off stages that already work.
Find a venue in parallel. You don't wait for the perfect one - you take what's free and lets you in. In Istanbul it was a coffee shop with a second floor, already a favorite of Russian clothing swaps and leetcode groups.
Start a Telegram chat and announce the first speaker. Announce a specific person, not "come to our event." A name in the announcement is the first reason to show up.
Keep walking other communities and invite people in person. A cold post doesn't fill a room. "Hey, I'm doing a thing on Sunday, come by" to someone's face does.
Find other people's chats and cross-post there. Someone else's audience that your topic fits is your first traffic. Free.

Now the key move, the one without which none of this scales. When you arrive in a new city, you don't carry it all yourself. You find a local - someone who already has an audience and an interest in the scene - and you make them an offer. Not "help me," but "here's what this gives you": organizer status, a network, visibility in the community. People who got a kick out of it stepped in and ran the location themselves. That's how the same mechanics traveled the world without me being in every spot at once.

What compounds, and what burns off

Not everything you do in a community turns into an asset. Some of it just burns off. The point is knowing what stays.

The format compounds. I started with masterminds - everyone pitches a project, the rest give feedback. Then speaker talks got added. Then shared dinners after, sometimes till morning. The format wore smooth against people and became portable: you arrive in a new city and bring a ready structure for an evening you already know how it'll go. You can hang an "event" sign in one night; a working format takes years.

The rhythm compounds. The Istanbul venue was free on Sundays - so I made Sunday my thing. There's no magic in Sunday, it's the predictability that works. People know when to find you. Regular beats flashy.

Reach is the one thing that doesn't compound instantly. Organic is slower than paid, no illusions there. Ads would have filled the room for the first event. Organic filled it by the third. But a room that came for ads scatters when the ads stop. A room that came because a live person from the community invited them stays and brings the next ones. Money buys attendance. Your own room you don't buy - you build it.

The numbers it added up to

Over three years, with no grand plan and not a single "turning point" - I just moved around the world and ran meetups as a way of life:

180+ events
50+ pitch sessions
150+ startups pitched
6,000+ people, in person, not followers
9 cities across 7 countries: Armenia, Georgia, Turkey, Spain, Serbia, the UAE, Indonesia
zero paid acquisition

One idea sits under those numbers - a bridge for post-Soviet founders into the global market. Someone from Minsk, Almaty, or Tbilisi who knows no one outside their bubble gets, through community, access to people, projects, and money they'd otherwise reach in years. Right behind that, those same founders hit the next wall - where to actually base the company, which I covered separately in founder visas for Spain, Portugal, and France. I was building for myself the thing I didn't have when I landed in Istanbul alone.

What carries over into product

I don't call this growth instead of meetups by accident. Community taught me three things I now apply to product directly.

First - cold start is solved not by scale but by the first live person. A marketplace dies on cold start because both sides need the other side from day one. Community teaches the opposite: you launch one room that's worth something even to the thirty who showed up, and the network grows on top of that. Value for one before any network effect. I built the same principle into my product - how I test its hypotheses.

Second - growth isn't a department that switches on after launch. I spent three years building traffic by hand and I know it from the inside: a channel you built yourself is cheaper and sturdier than any you bought. Knowing where your first and hundredth user come from is the CPO-level work, and "ship a feature" isn't even half of it.

Third - trust is a currency, and it isn't for sale. The room trusted me because I showed up every Sunday for three years, and ads had nothing to do with it. Same in product: retention is built on predictability, not on a launch.

So when people ask which channel to buy more of, I answer with the one nobody sells: the room that fills even the week you stopped paying for it

I'm Yan Nerovny - product lead and founder of Unicorn Embassy, the community described above. I write about product, AI and building from anywhere at nerovny.com/writing.

Building distribution without a budget? The six-step sequence above is the part worth stealing - run it in your own city and tell me how it goes. I'm on Telegram and LinkedIn.