After postponing more times than I care to admit. After mass-panic Discord messages at 2am. After one full month of crunch that turned my hair even greyer than it already was.

Omea’s free demo is live.

Go to omea.ai. Play a Viking survival horror story. Talk to NPCs who actually listen. Make choices that actually matter. Experience what happens when AI stops being a chatbot and starts being a Game Master.

This thing almost didn’t ship. Three times.

And I want to tell you exactly why.

If you’ve been wondering where I disappeared to for the past month - no Substack posts, no LinkedIn updates, total radio silence - this is why. Sometimes you have to choose between talking about building and actually building.

I chose building.

The Viking Who Almost Wasn’t

The demo story was supposed to be small. Simple. A quick proof-of-concept to show what Omea can do.

It turned into something else entirely.

A survival horror sandbox set in a frozen Viking world. Memorable NPCs with actual personalities. Easter eggs hidden in places you won’t find on your first playthrough. Or your second. Genuinely unlimited freedom - sneak, talk, fight, run, manipulate, befriend, betray. The AI doesn’t care which path you choose. It adapts.

This happened because our Game Director Darek kept pushing for “just one more thing” and our QA testers kept finding ways to break it (and then ways to make the breaking interesting), and our coders kept fixing bugs in real-time while the game designers kept adding depth.

Skunk Works in action. Small team. Fast iteration. Ship and fix and ship again.

But none of that matters if the servers can’t handle it.

And boy, did we have server problems.

The Inference Stack From Hell

Warning: full nerd mode engaged. If you’re here for the vibes, skip to “The Grind” section. If you want to know why we spent three weeks fighting FlashInfer version incompatibilities, buckle up.

Phase 0: vLLM (the baseline disaster)

We started where everyone starts: vLLM.

vLLM 0.15.1 on 8x B200 GPUs. Our NIA model (that’s Narrative Intelligence Architecture - our custom 350B+ parameter MoE beast). The results?

• 75 tokens per second per user

• 16 second time-to-first-token

• 641 tok/s total at 15 concurrent users

For context: 16 seconds TTFT means the player asks a question and waits... and waits... and waits... before the AI even starts responding. Unplayable.

The core problem: no speculative decoding. MTP (Multi-Token Prediction) crashed with a segfault on the first forward pass with FP8 MoE on B200. Old vLLM. No NIA-specific optimizations.

Dead end.

Phase 1: Stock SGLang (broken in new ways)

Tried SGLang with EAGLE speculation on 4x H200. Different hardware, different framework, different problems.

Short prompts? Worked fine.

Long prompts (14K+ tokens)? The model produced degenerate garbage. Complete nonsense. Like it had a stroke mid-sentence.

Root cause: FlashInfer attention backend bug on Hopper architecture. Nothing to do with EAGLE - same degeneration without it.

Another dead end.

Phase 2: The Breakthrough

We found an experimental SGLang fork optimized for B200 hardware. Some very helpful friends from San Jose pointed us in the right direction.

Three things made it work:

1. The right attention backend. B200’s default is trtllm_mha. Flash Attention 3 throws a ValueError on sm_100 (Blackwell’s architecture). Flash Attention 4 exists and is Blackwell-native (2x faster than FA3 for prefill), but it’s prefill-only - and EAGLE’s draft worker inherits the prefill backend. So FA4 + EAGLE throws “EAGLE is not supported in attention backend fa4”.

We’re stuck with trtllm_mha. It works.

2. Architecture-specific fusions. NIA is a Mixture-of-Experts model with shared experts that run on every token. Stock SGLang runs these as separate operations. The fork fuses shared expert computation into the MoE routing pass - eliminating redundant memory transfers. This alone gave +23.7% TTFT improvement.

Plus QK-Norm-RoPE fusion (three separate kernel launches become one), and async transfer that overlaps data movement with computation during MoE routing. That last trick hides PCIe/NVLink latency behind GPU compute - up to 1 second TTFT reduction. A friend from a robotics company shared that insight. Wasn’t my idea.

3. The correct reasoning parser. The reasoning parser is broken in this SGLang build. It never detects the </think> tag, causing infinite generation until max tokens. We had to use the deepseek-r1 parser instead, which works because NIA uses the same <think>...</think> format as DeepSeek-R1.

Yes, really. Production inference serving hacked together with a parser swap.

The Version Hell

Beyond the fork itself, getting a working stack required pinning exact dependency versions. And I mean exact.

FlashInfer 0.6.2 - Not 0.6.1 (broken MoE routing). Not 0.6.4 (breaks the trtllm_mha API). Exactly 0.6.2.

transformers 4.57.3 - Not 4.57.1 (crashes the tokenizer with “ValueError: Converting from SentencePiece and Tiktoken failed”). Not 5.0.0 (silently destroys EAGLE acceptance rate from 0.82 to 0.25 - no error message, just degraded performance). Exactly 4.57.3.

MNNVL stubs - FlashInfer 0.6.2’s MNNVL module uses the old cuda-python API (from cuda import cuda) which fails with cuda-python 12.x. We wrote 12 stub classes and wrapped all MNNVL imports in try/except blocks. Single-node inference doesn’t need multi-node NVLink, but the imports crash without the stubs.

The result after all this: 2.2x per-user TPS (165 vs 75) and 4.6x lower TTFT (3.5s vs 16s) versus vLLM on the same hardware.

Worth every hour of debugging. Barely.

EAGLE Speculation: Where the Magic Happens

EAGLE (Early-exit Augmented Generation for Large language models Efficient decoding) in SGLang is actually the same algorithm as NEXTN - they’re aliases. The model’s built-in MTP head serves as the draft model.

Our configuration:

SGLANG_ENABLE_SPEC_V2=1
--speculative-num-steps 3
--speculative-eagle-topk 1  
--speculative-num-draft-tokens 4

3 speculation rounds per step, top-1 candidate per round, 4 draft tokens total. This is the sweet spot. More steps didn’t improve acceptance rate and added overhead. topk > 1 increases memory without meaningful throughput gains.

Measured acceptance rates:

• BF16 KV cache: 78% acceptance, average 3.28 tokens/step

• FP8 KV cache: 67% acceptance, average 2.66 tokens/step

That 14% acceptance drop with FP8 KV? It matters. A lot. More on this below.

Here’s something wild we discovered: EAGLE has a profound effect on reasoning behavior. Without EAGLE, NIA generates 2,000-10,000 reasoning tokens per request. With EAGLE, reasoning consistently collapses to approx 500 tokens. And that is before Pena’s magic…

We believe EAGLE’s token acceptance patterns effectively “shortcut” the model’s reasoning chains - speculated tokens that match the model’s likely next output get accepted in batches, preventing the model from going down long deliberation paths.

This is why NVFP4 without EAGLE was 5x worse on TTFT - without the speculation shortcutting, the model’s reasoning explodes.

The counterintuitive discovery: BF16 KV is faster on Blackwell

This one broke my brain for a day.

Weights: FP8 (almost 400GB on disk). Aggressive - 8-bit for a 500B+ parameter MoE model.

KV cache: BF16 (16-bit).

Wait, what? Shouldn’t FP8 KV be faster? Half the memory bandwidth for cache reads?

On H200/H100: yes. FP8 KV is +12.6% faster on H200, +27.7% on H100. Those architectures are memory-bandwidth-bound.

On B200/B300: FP8 KV is 18.8% slower than BF16.

The reason: Blackwell’s faster memory subsystem shifts the bottleneck from bandwidth to compute. The FP8 quantize/dequantize kernels add extra 23 microseconds per layer. With NIA’s 92 attention layers, that’s approx 2.1ms of pure overhead per token. At 150+ TPS, this compounds fast.

Confirmed independently by SGLang issue #17526 (Blackwell B300 benchmarks): BF16 KV achieved 6,018 tok/s vs FP8 KV’s 4,886 tok/s - a 23% gap.

Lesson learned: don’t assume what worked on Hopper works on Blackwell. Benchmark everything.

What Didn’t Work

NVFP4 - NVIDIA’s FP4 quantized checkpoint (44% smaller). No EAGLE support - MTP weights are missing. Without EAGLE, TTFT goes from 3.5s to 17.9s. Required patches to modelopt_quant.py. TP=4 crashes with cuDNN GEMM errors. Even at TP=8: 117 TPS vs 165 with FP8+EAGLE. Dead end.

FA4 + EAGLE - Already mentioned. Prefill-only, draft worker incompatible.

thinking_budget + EAGLE - SGLang’s MoeThinkingBudgetLogitProcessor uses output_ids to count reasoning tokens, but EAGLE draft tokens aren’t committed to output_ids until verified. The processor never sees enough tokens to trigger the budget cap. Broken.

The TTS Stack

Nerd mode: slightly lower intensity

Our voice system needed to serve 100 concurrent streams with RTF (real-time factor) below 0.25 on a single B200.

We had a starting point. It was slow. It needed love.

Plaza came in and pushed GPU, TensorRT, and Triton inference server to their absolute limits. Good benchmarking was everything - you can’t optimize what you can’t measure.

The funny mishap: today, on launch day, we were burst-testing the production server. The Triton inference server handled it like a champ. But we accidentally killed our FastAPI/REST server. Multiple times. Uvicorn just... gave up.

Panic was involved. Production server. Launch day. Classic startup moment.

We fixed it. Shipped it. Moved on.

RTF 0.22 / 1st user, approx 0.5 under heavy load. Single B200. 100 concurrent streams. BF16 precision. It works.

The Grind

One full month of constant crunch. For most of the team.

The last few days were the hardest. Daily releases. Sometimes multiple releases per day. Every morning a new list of bugs. Every evening a new build.

There were multiple moments of “this will NOT ship today”. And “this will NOT ship tomorrow”. And “are we sure this is going to ship at all?”

Startup life. Bootstrapping with limited funding means always being on the bleeding edge. You don’t have the luxury of “let’s wait until it’s perfect”. You ship when it works well enough to not embarrass yourself, and you fix the rest live.

We have custom monitoring dashboards for everything now. NIA metrics: total throughput, EAGLE acceptance rate, active requests per minute, TTFT. TTS metrics: concurrent inferences per second, RTF. When something breaks at 2am, we know exactly where to look.

It broke at 2am more than once this month.

What’s next?

The demo is live. Go break it: omea.ai

Tell us what sucks. We’ll fix it tomorrow. That’s the deal.

The Viking story is just the beginning. One story, one world, one proof of what NIA can do. But we have plans. Many plans.

B300 experiments are on the roadmap. NVFP4 might be salvageable if we can get EAGLE weights working. FA4 might become usable for non-EAGLE workloads.

But right now? Right now we ship. We watch the metrics. We fix the bugs users find. We iterate.

Less talking, more building.

Max

The humans who made this possible

Michal Pena (a.k.a. Cyb0org) - cofounder, MLOps wizard, DevOps firefighter, the guy who deals with our programmers when they (or me) want to burn everything (or everyone) down. Golden supporter from day one. The aggressive fine-tuning and clever reasoning cut-down methods I (didn’t) mentioned? His work. Proprietary magic.

Justine - my wife, my sanity anchor, and also (plot twist) a data scientist who ended up debugging game-designer related stuff. When I disappeared into GPU kernel hell for weeks, she kept everything else running. Everything.

Darek - Game Director. Led the charge on the Viking story. “Small and simple” became “sandbox with unlimited freedom” because he refused to ship anything he wasn’t proud of.

Przemek Kuśmierek - constant, relentless support. Even while running Migam. Even while dealing with his own chaos. Always there.

Plaza - for turning our TTS stack from “it works, kinda” into “100 concurrent streams on a single GPU”. The Triton optimization work was clutch.

Pawel Morkisz - the first person to kick my fat ass into taking things (a.k.a. TRT) seriously. Sometimes support doesn’t look like code reviews or investor intros. Sometimes it’s just showing up for a steak or salad in San Jose and reminding you to be a better man. That matters more than you’d think.

And to everyone else who believed in this before it was real - the investors who took meetings when we had nothing but slides, the advisors who answered late-night questions, the friends who just showed up when it mattered.

You know who you are.

This one’s for you.

PS. The website? Built with Claude, not WordPress. Obviously.

PS.2 If you want to go even deeper on the technical stuff - the exact FlashInfer version pinning, the MNNVL stub hack, the reasoning parser swap - hit me up. I have opinions. Many opinions.

Omea’s first public demo goes live. Free access. One story. Anyone can play. No gatekeeping, no waitlists, no “apply for early access and we’ll get back to you in 6-8 weeks”. You show up, you play.

I’m terrified.

Not the impostor syndrome kind of terrified - I’ve written about that enough times that it’s become a familiar companion, like a roommate who never does the dishes but at least pays rent on time. This is a different flavor. This is the terror of showing people something you’ve poured everything into and watching them interact with it for the first time. Like handing your diary to a stranger and saying “so, what do you think?”

So many things can go wrong. The servers might buckle under traffic (I’m betting they will). Edge cases we didn’t catch will surface within the first hour (they always do). Someone will find a way to break the narrative in a way we never anticipated (looking forward to that one, actually - players are magnificently creative destroyers).

But before we get to next week, I want to tell you how we got here. Because the story of Omea starts with a question asked over drinks after a long day of teaching people about technology they didn’t yet realize would change their lives.

The question that started everything

2023. I’d just wrapped up a full day of corporate training - back when teaching people about large language models was still a niche thing, before it became the default LinkedIn personality trait. Artur Kurasiński and I were decompressing. If you don’t know Artur, he’s my co-founder and CMO at Omea now, but back then he was just my friend. A fellow nerd. A fellow traveler in the same weird corner of geekdom that I’ve inhabited since I was young.

We’re both pen-and-paper RPG players. Have been for decades. And before I go further, let me explain what that means for anyone who hasn’t experienced it, because it’s central to everything Omea is trying to do.

Pen-and-paper RPGs - think Dungeons & Dragons, but that’s just the most famous one - are collaborative storytelling games. A group of people sit around a table. One person is the Game Master (GM). The GM creates the world, controls the non-player characters, describes the environment, manages the plot. Everyone else plays a character in that world - makes choices, interacts with the story, pushes the narrative in directions nobody predicted.

The GM is part writer, part improv actor, part psychologist, part god. They hold the entire narrative in their head. They know the backstory, the plot threads, the emotional arcs. But here’s the crucial thing: they can’t script what happens. The players have free will. Someone will always do something unexpected. The GM’s job is to adapt, in real time, while maintaining coherence and emotional impact.

When a great GM is running a session, something magical happens. You stop thinking about rules and dice and character sheets. You’re in the story. You feel genuine tension during a heist. You care about NPCs who only exist in someone’s imagination. You remember sessions from years ago like they actually happened to you.

That’s what Artur asked me about.

“When will LLMs be powerful enough to be a Game Master? Not a chatbot that feels like a game of Mad Libs - an actual storyteller. Someone who builds narrative, paints believable characters, surprises you with fresh ideas instead of clichés.”

I thought about it for maybe five seconds.

“Nowhere soon. Years. Maybe a decade.”

How spectacularly wrong I was.

The three problems nobody was solving

Here’s the thing about being a tinkerer with ADHD (my superpower and my curse, as documented in a previous essay): when someone poses a question that interesting, my brain doesn’t file it away for later consideration. It latches on. That night, instead of doing the sensible thing and sleeping next to my better half, I started experimenting. Small stuff at first. Then bigger. Then I sold my car.

But I’m getting ahead of myself.

The more I dug into the problem of AI storytelling, the more I understood why nobody had cracked it. There were three fundamental issues, and all three were showstoppers.

The narrative coherence problem. Ask any frontier LLM to write you a paragraph of fiction. It’ll be good. Maybe even great. Ask it to write a few pages that hang together. Probably still works. Now ask it to maintain a coherent, emotionally satisfying narrative across hours of interactive play. Off the rails. Every time. The model forgets what it set up earlier. Plot threads dissolve. Characters lose their personalities. The Hero’s Journey - the fundamental narrative structure I wrote about a few weeks ago - gets abandoned for a cycle of “what should the player do next?” followed by whatever the model’s attention mechanism happens to prioritize.

LLMs are incredible at generating plausible next sentences. They’re terrible at holding a story.

There’s a deeper issue here, too. In the standard LLM paradigm, you have a “user” and an “assistant”. They take turns. Ping-pong. The user asks, the assistant responds. This architecture leaks into any storytelling attempt built on top of it. The player becomes a god-like figure issuing commands from above, and the AI becomes a dutiful servant trying to please. That’s not how stories work. In a great narrative, the player isn’t a user with admin privileges - they’re an actor inside the world. One of many. Subject to the same rules, the same consequences, the same narrative forces as everyone else. The moment you give the player god-mode, you kill the stakes. And without stakes, there’s no story.

The emotional intelligence problem. For a narrative to work - really work, the way it does when a great GM is running a session - the AI needs to understand emotional dynamics. Not just of the player, but of the characters it portrays. NPCs need to feel like people, not cardboard cutouts dispensing quest information. They need motivations, contradictions, fears. Here’s something fascinating I learned from Tomek Kolinko: the same emotional rules that govern believable characters also apply to locations and objects. A haunted mansion isn’t just a physical description - it has emotional weight, history, presence. Getting this right requires something deeper than what standard LLMs offer.

The memory problem. We wanted players to live stories that span hours, not minutes. Think about what that means in terms of context. You need to remember everything: what the player said in the first scene, the promise they made to an NPC three hours ago, the subtle shift in a character’s loyalty that happened because the player chose to lie about something seemingly insignificant. We’re talking about ten million tokens of coherent, structured memory. Not just a giant context window - you can’t just dump ten million tokens into a prompt and pray. And standard retrieval systems don’t cut it either. Simple indexing and cosine similarity - the backbone of most RAG systems - can’t grasp the intricate connections between emotions, timeline, and cause-and-effect chains. “The player was kind to the merchant in chapter two” and “the merchant’s daughter is now in danger in chapter seven” are semantically distant in embedding space but narratively inseparable. Memory for storytelling isn’t a database lookup. It’s emotional, temporal, interconnected. What matters to the story changes over time. What was trivial in act one becomes pivotal in act three. The memory system needs to understand that.

Three problems. Three reasons why every AI storytelling attempt before us felt like a party trick that got old after five minutes.

The roads not taken (and the one we did)

So how do you fix this?

The obvious answer in 2025 and 2026 is agents. Build a multi-agent system. One agent handles narrative planning. Another manages character consistency. A third handles memory retrieval. A fourth does emotional modeling. Then you realize you also need a sentiment analysis agent. And a writing style consistency agent. And a coherency-in-time judge that tracks cause-and-effect chains. And a continuity checker. And... you see where this goes. You can add agents endlessly, each one solving a real problem, each one adding another layer of complexity to the stack. Coordinate them all with an orchestrator, and boom - you’ve solved it.

Except you haven’t. You’ve created a Rube Goldberg machine. Every agent adds latency. Every coordination point is an opportunity for errors to compound. You’re burning a hundred tokens behind the scenes for every token the player actually sees. And it’s slow. Interactive storytelling demands responsiveness. When a player makes a choice, they need to feel the story react. A multi-second delay while your agent swarm argues about what should happen next kills the magic faster than a bad plot twist.

It’s like using a battle rifle to shoot a mosquito during a quiet night. You can, technically. But should you?

The second option was to train our own model. This was the direction that made sense to me - the Skunk Works approach. Don’t rely on someone else’s general-purpose tool. Build the specialized thing yourself, designed from the ground up for the specific job you need done.

But that road had its own walls. We started in the early days, when the best open-source options were Alpaca and Vicuna - early Meta Llama derivatives that feel almost quaint now. We quickly learned that even with specialized datasets - and I’m talking about over 155,000 carefully curated and annotated novels and scripts - a standard Transformer architecture just predicting the most probable next token wasn’t going to develop narrative intelligence on its own. You can feed it Shakespeare’s complete works and it still won’t understand why Hamlet delays.

We explored the landscape. The dominant GPT-style architecture - autoregressive, left-to-right, always guessing the next token in sequence - was clearly insufficient for our needs. BERT-style architectures looked more promising at first. Masked language modeling, where the model learns to understand context from all directions rather than just predicting forward, felt closer to how narrative comprehension actually works. But BERT wasn’t designed for generation, and adapting it created its own set of headaches.

Neither approach was enough on its own. And we weren’t the only ones realizing that standard Transformers had limitations. Look at what NVIDIA did with Nemotron, or IBM with Granite - marrying Transformer architectures with Mamba (a state-space model) to get the best of both worlds. Different teams, different solutions, all arriving at the same conclusion: the vanilla Transformer isn’t the end of the road.

We went our own way. What we built isn’t a regular LLM. You won’t find it as a model card on Hugging Face. It’s a hybrid architecture born out of specific narrative requirements, not general-purpose benchmarks.

The third piece, and the one that changed everything, was understanding narrative itself. Not from an AI perspective - from a storytelling perspective. How does the Hero’s Journey actually work as a structural framework? Why did ancient playwrights divide stories into acts? What makes a player feel like a participant rather than a passenger?

We needed someone who understood storytelling at its bones. That someone was Casey McBeath, who became our Creative Director and who brought over a decade of LA-based cinematographer experience to the founding team. That’s not a decoration on his resume - it means Casey has spent years understanding how stories move audiences, how scenes are structured for emotional impact, how pacing and tension work not in theory but in practice, on real productions. You can teach an AI to recognize patterns in text. You can’t teach it taste. Casey brought the taste.

Blood, sweat, and GPT-2

So we combined all three approaches, because of course we did. (One project at a time was never really my style - greybeard speaking)

First iteration: experiments with GPT-2 combined with LSTM networks and a mutated architecture of our own design. We started training on our curated datasets. Small models, 13 billion parameters.

We failed.

But - and this is the part that doesn’t show up in the startup mythology - the second iteration of that approach showed promise. Not quality you’d ship. Not quality you’d show anyone except your co-founders at 3 AM when everyone’s sleep-deprived enough to see potential in garbage output. But the thesis was working. The architecture was doing something that standard approaches couldn’t: it was maintaining narrative awareness across longer sequences. It was, in its clumsy newborn way, trying to tell a story instead of just predicting words.

Let me be clear because I refuse to sell bullshit from any stage, virtual or otherwise: the output was bad. The quality was low. If you’d played it, you would have been unimpressed. But we could see the shape of what it could become, and that gave us wings.

Burning the boats

Long story short, I put everything I had into this project.

Everything.

And let me be specific about why this costs money, because people outside of AI sometimes don’t grasp the economics of what we were doing. Training models isn’t cheap - you’re renting expensive GPU clusters by the hour, and a single training run can eat through thousands of dollars before you know if it worked. Building proper datasets requires buying source material - those 155,000 curated texts didn’t materialize from thin air. You need to pay coders, because even a small Skunk Works team needs to eat while they’re building the impossible. And through all of this, you’re not drawing a salary from your own company. You’re the one throwing more money on the fire at every stage, not the one pulling it out.

Oh, and it’s generally helpful to not be homeless and to have something edible in the fridge. Basic requirements that become surprisingly non-trivial when your R&D budget is also your grocery budget.

Sold cryptocurrency. Took on more work, worked harder, earned more, and poured every extra zloty into keeping the research alive. Let go of the dream of building a home in Poland. And at one point - I’m not being dramatic here, this is just what happened - I sold my car to make it to the next month of compute costs.

Bootstrapping an AI company with heavy R&D requirements and no early customers to show traction is not the romantic adventure that startup Twitter would have you believe. There’s no “building in public” content strategy when your primary public activity is figuring out how to pay the cloud bill. There’s no “fail fast” when every failure costs you money you don’t have.

I needed to be sure we could pull this off before taking investor money. That might sound backwards to the “raise first, figure it out later” crowd, but this is a Skunk Works principle I’ve written about before: know your numbers. Know what you’re building. Know that the impossible thing is merely very difficult before you ask someone else to bet on it with you.

Those were hard days. Anyone who tells you bootstrapping is about “enjoying the journey” has never sold their car to fund a training run.

The breakthrough

And then, after a while, we pulled it off.

I won’t go deep on the technical architecture here - that essay deserves its own dedicated space, and I promise it’s coming. But the short version is this: our Narrative Intelligence Architecture (NIA, because every good project needs a name that sounds like a person) combines our custom-trained model with a deep understanding of narrative structure. It doesn’t use an agent swarm. It doesn’t burn hundreds of tokens in hidden coordination. It’s an orchestration system built on zero-agent approaches - one model, carefully tuned, doing the work that others try to accomplish with sprawling multi-agent infrastructure.

The result is faster, more coherent, and cheaper to run than the alternative. Not because we’re smarter than everyone else. Because we asked a different question. Instead of “how do we make LLMs better at storytelling?” we asked “how do we build a system that understands storytelling and uses LLMs as one component?”

Everyone in AI right now is racing toward more agents, better IQ, higher benchmark scores, more parameters, more data. The arms race is about making models smarter.

We made a bet that the blue ocean wasn’t IQ. It was EQ - Emotional Intelligence.

Not another state-of-the-art super-large LLM with an IQ higher than mine and better coding skills than I’ll ever have. The world has enough of those, and more are coming every quarter. What the world doesn’t have is AI that understands emotional dynamics, narrative structure, the human experience of being inside a story.

That’s what we built. That’s what you’ll get to try next week.

Standing at the edge

So here I am. Standing in front of you, just before the big shot toward the moon.

The demo will be free. One story, accessible to everyone. It’s a test for everything: the product, the technology, the narrative design, the infrastructure, the storytellers, the coders. Everything and everyone.

Will things break? Almost certainly. Will someone find an edge case that makes me want to hide under my desk? Probably before lunch on day one.

But that’s why we’re launching. Not because it’s perfect - it’s not, and anyone who ships a perfect v1 is either lying or hasn’t shipped. We’re launching because the only way to know if this works is to put it in front of real people and watch what happens. Ship and iterate. Kelly Johnson would approve.

I strongly believe we’ve built something unique. Not unique in the “our landing page says we’re unique” way, but unique in the “try it and tell me you’ve experienced this before” way. The UVP isn’t a marketing claim. It’s a feeling you’ll get when the story surprises you in a way that feels earned, not random.

Come play. Break things. Tell me what worked and what didn’t. That’s how we get better.

Less talking, more building. See you on the other side of launch.

Max

PS. In other news: I got married! Justine and I made it official, and it’s been awesome. Though honestly? For us, basically nothing changed except we have rings now. We loved each other before the ceremony, we love each other after. The best kind of non-event.

PS2. Here’s something I’ve been sitting on: NIA - our narrative intelligence system - is currently being used by two companies from completely different industries than gaming. Turns out the need for high Emotional Intelligence in AI isn’t limited to interactive storytelling. We might have built something bigger than we originally aimed for. Are we going to kill OpenAI or Anthropic? Definitely not. Are we going to succeed? I believe so, with everything I’ve got.

PS3. Yeah, I know. Three PS sections. My ADHD has entered the chat. But I wanted to say - if you’re reading this and you’re a pen-and-paper RPG player, a Game Master, a storyteller of any kind: come try this. You’ll understand what we’re doing faster than anyone, because you’ve been doing it manually your whole life. We just taught a machine to join your table.

So here I am, slightly feverish, freshly married, writing about the thing I probably should have written about years ago.

ADHD.

If you have it, this essay is for you.

If you don’t have it - or think you don’t - keep reading anyway. You might recognize something. Or you might recognize someone you work with, live with, love. Approximately half of my close work friends have ADD or ADHD. In the founder and engineering world, we’re everywhere. Often undiagnosed. Often struggling in silence.

This is the essay I wish someone had written for me twenty years ago.

The broken years

For most of my life, I thought I was broken in a way that couldn’t be fixed.

Not broken like “needs improvement”. Broken like defective. Like there was something fundamentally wrong with the wiring, and I just had to live with it.

The symptoms were there, obvious in retrospect:

Swinging moods. Not just good days and bad days - violent swings between manic productivity and crushing despair. Depression could hit hard, out of nowhere, and stick around for days or weeks.

Couldn’t finish things. Projects started with explosive enthusiasm and abandoned at 80% completion. Ideas multiplied faster than I could execute them. The graveyard of almost-done work growing larger every year.

All over the place. Conversations where I’d interrupt constantly because the thought would evaporate if I didn’t say it NOW. Meetings where my mind would wander to three different problems while someone was talking directly to me. The inability to focus on what mattered when something shinier appeared.

Or the opposite. Hyperfocus so intense I’d forget to eat, forget to drink, forget to sleep. I ended up in the hospital more than once - avitaminosis, dehydration, exhaustion that bordered on dangerous. When I locked onto something, I couldn’t unlock. The world disappeared.

The bad moments were unbearable. Not just difficult - unbearable. The kind of dark where you don’t see a way forward.

And through all of it, I wasn’t fair. To coworkers who had to deal with my chaos. To co-founders who couldn’t predict which version of me would show up. To employees who deserved better leadership. To my family.

To Justine, most of all. Who stayed anyway. Who just married me anyway.

I spent over twenty years of my professional career being a flaming wreck. A pain in the ass to everyone who tried to work with me or love me.

I should have done something about it so much earlier.

Step One: get diagnosed

This is the first and most important thing I can tell you:

Get diagnosed.

I know. It sounds obvious. It sounds like the kind of advice that makes people roll their eyes. But I lived for decades - DECADES - thinking I was just broken. Thinking this was my personality. Thinking I had to white-knuckle my way through life because that’s just how I was built.

The diagnosis changed everything.

Not because it fixed anything immediately. But because it gave me a framework. A name for the thing I’d been fighting. Evidence that I wasn’t uniquely defective - that millions of people have this, and there are strategies, treatments, support systems.

The diagnosis itself was almost anticlimactic. A conversation with a psychiatrist. Some questionnaires. A history review. And then:

Yes, this is textbook ADHD.

Textbook. The thing I’d been struggling with my entire life was textbook. Documented. Understood. Treatable.

If you’re reading this and recognizing yourself - if the swinging moods and the inability to finish things and the hyperfocus and the chaos sound familiar - please, please get evaluated. It might not be ADHD. It might be something else. But knowing is better than guessing, and guessing is what I did for twenty-plus years.

It gets worse with time. It gets worse with stress. And startup life is nothing but stress. Do it now. Don’t wait until you’ve burned through your relationships and your health like I did.

Step Two: don’t give up on treatment

Here’s what nobody told me about medication: the first thing probably won’t work.

My journey through ADHD meds was not a straight line. It was a mess.

First attempt: Nothing. Felt like sugar pills. No change.

Second attempt: Worse. My libido went to ashes. I was sleepy all day but couldn’t sleep at night. Couldn’t wake up early. Everything made me nervous. I was a different kind of broken, not better broken.

Third attempt: Hit.

Three tries to find the right medication. And even then, it took time to tune the dosage, to figure out the timing, to understand how it interacted with sleep and food and stress.

If I’d given up after the first try, I’d still be that flaming wreck. If I’d given up after the second try - after the side effects made me wonder if the cure was worse than the disease - I’d never have found what worked.

I’m not going to tell you what medication I take. That’s not me being coy - it’s me being responsible. Every body is different. Every brain is different. What works for me might be useless or harmful for you. You need to work with a doctor who knows your specific situation, your specific chemistry, your specific life.

But I will tell you: don’t give up after one failure. Don’t give up after two. The right treatment is out there. Finding it is a process, not an event.

Step Three: pay it forward

You’re not alone.

I know it feels that way. ADHD has a way of making you feel uniquely broken, uniquely difficult, uniquely unable to function like “normal” people. The shame compounds. You stop talking about it because talking about it means admitting weakness.

Here’s the truth: there are founders, engineers, creators, builders everywhere who have the same thing. Not identical - that would be too easy - but similar. Similar struggles, similar coping mechanisms, similar scars.

Find them.

I don’t mean join a support group (though that’s fine if it works for you). I mean look around at your professional network, your friends, your collaborators. The people who seem a little too intense, a little too scattered, a little too prone to either hyperfocus or chaos. Odds are good some of them are dealing with the same thing.

Talk about it. Share what’s worked. Share what hasn’t. When someone newer to the diagnosis asks for advice, give them what you wish you’d had.

This is paying it forward. Someone will do it for you first. Then you’ll have the chance to do it for someone else.

Half of my close work friends have ADD or ADHD. We’ve talked about it, compared notes, helped each other through the rough patches. That community - informal, unstructured, just people who get it - has been as valuable as any medication.

The things that actually help

Beyond diagnosis and medication, some practical stuff that’s made a difference:

Private life matters.

I don’t mean parties and drinking and crazy adventures that make people question your sanity. I mean the opposite. The quiet stuff.

Walks with a dog. Regular exercise - not extreme, just regular. Hobbies that aren’t work - board games with friends, video gaming, things that use your brain differently. A routine that includes rest.

For years I thought I could outrun ADHD with intensity. Work harder, move faster, burn brighter. It doesn’t work. You just burn out faster.

The walks with Justine - even during the crunch, even when my body was screaming - those kept me functional. The hobbies that have nothing to do with startups - those keep me sane. The routine of sleep and meals and movement - that’s the foundation everything else sits on.

Sleep is not optional.

ADHD and sleep have a complicated relationship. The medication can mess with it. The hyperfocus definitely messes with it. The racing thoughts at 3 AM mess with it.

But sleep deprivation makes everything worse. The mood swings get wider. The focus gets harder. The bad days get darker. Protecting sleep is protecting everything else.

Structure compensates for chaos.

My brain doesn’t naturally create structure. It creates chaos. So I’ve learned to build external systems - calendars, lists, routines, accountability partners - that impose structure from outside.

This isn’t a failure. It’s an adaptation. A diabetic doesn’t feel bad about needing insulin. An ADHD brain doesn’t need to feel bad about needing structure.

The new man

I need you to understand something.

The last few years of my life have been more stressful than the previous twenty combined. Building Omea. Building Migam. Fundraising. Technical challenges. Moving toward Silicon Valley. Crunches that left me seeing sunrises for eight days straight.

And these few years have also been the best days of my life.

That’s not despite the ADHD treatment. It’s because of it.

I’m a new man. Not perfect - still chaotic, still prone to hyperfocus, still fighting the wiring. But functional in a way I never was before. Present in a way I couldn’t be before. Fair to the people around me in a way I wasn’t capable of before.

Justine married me today. She knew me during the flaming wreck years. She’s seen the transformation. She said yes anyway - said yes because of who I’ve become, not just despite who I was.

The diagnosis. The treatment. The community. The lifestyle changes. They added up to a different person. Someone I actually like being. Someone who can handle stress that would have destroyed the old version of me.

If you’re in the early stages - newly diagnosed, trying to find the right medication, wondering if it’s worth the effort - I promise you it is. The person on the other side of that process is worth meeting.

For those who don’t have ADHD

If you’ve read this far and none of it resonates personally, thank you for staying.

You probably know someone. A co-founder, an employee, a friend, a family member. Someone who seems brilliant but scattered. Someone who swings between manic productivity and unexplained darkness. Someone who’s hard to work with but clearly has something valuable to offer.

Maybe they don’t know what’s wrong. Maybe they think they’re just broken.

You can’t diagnose them. You can’t force them to get help. But you can be someone who understands. Who doesn’t write them off as difficult. Who creates space for the conversation if they’re ready to have it.

And if they do get diagnosed, if they do start treatment, if they do start the long process of becoming functional - you can be someone who notices. Who acknowledges the change. Who pays it forward by being part of their support system.

The founder and engineering world is full of ADHD brains. We built a lot of this industry. We’re also burning out, melting down, disappearing without explanation. Anything that increases understanding helps.

Three steps

That’s it. That’s the whole thing:

One: Get diagnosed. Stop guessing. Stop assuming you’re just broken. Find out what you’re actually dealing with.

Two: Don’t give up on treatment. The first medication might not work. The second might make things worse. Keep going. The right combination exists.

Three: Pay it forward. You’re not alone. Find the others. Share what works. Accept help when it’s offered. Offer help when you can.

I spent twenty years as a flaming wreck because I didn’t know these three steps existed. I thought I just had to endure. I thought the chaos was permanent.

It wasn’t. It isn’t.

The last few years have been the hardest and the best of my life. The diagnosis made that possible. The treatment made that possible. The people who paid it forward before I could - they made that possible.

Now it’s my turn to pay it forward. This essay is part of that.

If you recognized yourself in these words, please don’t wait another twenty years like I did. The new version of you is waiting.

Less talking, more building. See you next week.

Max

PS. To Justine - thank you for staying through the broken years. Thank you for pushing me to get help. Thank you for saying yes this week. The new man is yours.

PS.2 Next week: Omea final demo preparations. Our story, just before releasing the big news. It’s almost time.

Jensen Huang was somewhere nearby. The invitation said “private party”. GTC Paris, VivaTech 2025. I’d somehow made the list.

And all I could think was: what the hell am I doing here?

It wasn’t excitement. It wasn’t gratitude. It was something closer to dissociation - like I wasn’t Max anymore, just a passenger in my meatsuit, watching this scene unfold and waiting for someone to tap me on the shoulder and say there’d been a mistake.

I’m 45 years old. I’ve been building companies for over a decade. I’ve shipped products, raised money, hired teams, failed spectacularly, and come back to try again. By most measures, I’ve earned my place in rooms like this.

And yet.

That’s the thing about being a greybeard in startup land. Experience doesn’t cure impostor syndrome. It just changes the flavor.

The greybeard reality

“Greybeard” is an old term from hacker culture - the experienced one, the person who’s seen the cycles come and go, who remembers when the current hot thing was the last hot thing under a different name. It’s not about actual grey hair, though I’ve got some of that too. It’s about having survived long enough to recognize patterns.

The startup world has a complicated relationship with experience.

There was an era - the Zuckerberg era - when “young people are just smarter” was said out loud, and investors pattern-matched hoodies and 23-year-olds to billion-dollar outcomes. That’s softened somewhat, but the bias remains. Walk into most startup events and count the grey hair. You won’t need many fingers.

I’m 45, building AI companies, moving toward Silicon Valley, competing in a space where some founders weren’t born when I wrote my first lines of code.

My co-founders are in their 40s and 50s. Michal. Casey. Artur. We’re not the young hungry wolves. We’re the ones who’ve been through the woods before and know where the traps are.

Some people see that as a disadvantage. I’m starting to think it’s the opposite.

What experience takes away

Let me be honest about the costs first. If I only talked about the advantages, you’d know I was selling something.

The body keeps score.

I just finished an 8-day crunch. December 26th through January 5th. Three projects colliding: Omea Vertical Slice, a B2B feature delivery, Migam demo prep. 16.5 hours a day average. Eight sunrises seen from the wrong side.

At 25, I would’ve bounced back in a weekend. At 45, I know I’ll need weeks. My body isn’t angry with me - it’s disappointed. There’s a debt that compounds, and recovery takes longer to pay it down.

The 22-year-old founder can pull all-nighters like they’re free. They’re not free for anyone, but the invoice arrives later when you’re young. At 45, it arrives immediately, with interest.

The curse of knowing too much.

Pattern recognition is a superpower until it becomes a cage.

I’ve seen companies fail. I’ve watched promising tech get crushed by better-funded competitors. I’ve experienced the slow-motion collapse of something I built - watching 20 people and years of work dissolve because we were too slow, in the wrong country, too focused on quality while the market moved on.

ACR. My camera robotics company. 2013 to 2019. That wound is still fresh. I think it always will be.

When you’ve lived through that, you see failure modes everywhere. Sometimes that’s wisdom. Sometimes it’s just fear wearing wisdom’s clothes. The balance between “I know how this ends” and “I should try anyway” gets harder to find.

The paralysis of probability.

Young founders move fast and break things without thinking too hard about what might break. They have the luxury of not knowing all the ways something can go wrong.

I know. I’ve lived a lot of them.

That knowledge can slow you down. The thoroughness that experience brings can become overthinking. The caution that wisdom provides can become hesitation.

Sometimes ignorance really is bliss, and the young founder who doesn’t know the cliff is there will occasionally make the jump that the experienced one won’t attempt.

What experience gives you

Now the other side. The part that makes the grey hair worth it.

Pattern recognition (the good kind).

I’ve seen hype cycles. I remember when everything was going to be disrupted by blockchain, by VR, by mobile, by the cloud, by social, by AI. Some of those disruptions were real. Most were noise dressed up as signal.

When you’ve watched enough cycles, you develop a filter. You can see what’s actually new versus what’s a rebrand of something that failed five years ago. You can smell the difference between genuine innovation and venture-backed marketing.

In AI right now, this matters enormously. So much noise. So many pitches that are “ChatGPT wrapper plus funding round”. The ability to see through that - to identify what’s actually going to matter in five years - that comes from having watched the previous waves.

Relationships compound.

Twenty years of building things means twenty years of connections. People who’ve watched you operate, fail, come back, and try again. Trust that can’t be speedrun.

When I call someone I’ve worked with for a decade, they take the call. When a young founder cold emails them, they might not. That’s not fair, but it’s real. Relationships are infrastructure, and infrastructure takes time to build.

Emotional regulation.

The panic that would’ve destroyed me at 25 doesn’t touch me at 45.

Not because I’ve become numb - I still feel the fear, the doubt, the 3 AM certainty that everything is about to collapse. But I’ve survived enough of those nights to know they pass. I’ve been through worse. I know I’ll be through worse again. And I’m still here.

Investors can smell desperation. They can also smell calm. Experience gives you the ability to be terrified on the inside while presenting composed on the outside. That’s not dishonesty - it’s regulation. It’s knowing that your fear isn’t useful information for the room.

Knowing yourself.

At 25, I was fighting my own nature constantly. Trying to work the way I thought I was supposed to work. Failing, blaming myself, trying harder in the same broken way.

At 45, I finally understand how I work. ADHD wasn’t a diagnosis I had most of my life - I just thought I was broken in ways I couldn’t fix. Getting that understanding, finding the right support, learning to use my brain instead of fighting it - that turned a lifetime of struggle into something closer to a superpower.

I know when to push and when to rest. I know that my best ideas come not in front of a keyboard but on a mountain trail or - I’m not making this up - while watching an avalanche from a backcountry toilet in King’s Canyon. That’s where I figured out how to implement multiplayer in Omea. Your brain keeps working even when you’re not looking at the screen. Especially when you’re not looking at the screen.

The generalist advantage.

Here’s something I’ve accepted: I’m not a great programmer.

I’m a mix of stubborn and lazy. My code works but it’s not elegant. I know people who are smarter and write better software.

But here’s what I bring: I’ve worked on movie sets and understand how storytelling works from the production side. I’ve built robots and understand physical systems. I’ve trained AI models and understand the math. I’ve run teams and understand people. I’ve failed at sales and understand markets.

The job of a founder - especially a technical founder - isn’t to be the best at any one thing. It’s to understand enough about everything to hire people better than you and know whether they’re doing good work.

I can sit with devops, frontend, backend, ML engineers, game designers, and narrative writers - and I can follow what they’re doing well enough to help. That generalist range comes from decades of being curious about everything. You can’t speedrun that either.

The impostor syndrome paradox

Here’s what nobody told me: impostor syndrome doesn’t go away with experience. It evolves.

At 25, impostor syndrome said: “You don’t know enough”.

The solution seemed obvious - learn more, work harder, earn your place.

At 45, impostor syndrome says something different: “You know too much about how hard this is”.

I’m not scared of the unknown anymore. I’ve faced enough unknowns. I’m scared of the known. I’ve seen talented people fail. I’ve seen great products die. I’ve seen founders who did everything right still lose.

The young founder has the comfort of ignorance - maybe THIS time it’ll be different, maybe I’M the exception.

I know the base rates. I know how many startups fail. I know how many AI companies are going to be nothing in five years. And I’m building anyway, with clear eyes about the odds.

That’s a different kind of impostor syndrome. Not “I don’t belong here because I’m not good enough” but “I know exactly what this takes and I’m not sure I have it”.

Standing in that dark room in Paris, holding my apple juice, watching Jensen Huang work the crowd - the voice in my head wasn’t “you don’t deserve this”. It was “you know how unlikely this is. You know how many things had to go right. You know it could all disappear tomorrow”.

Experience doesn’t silence that voice. It just teaches you to build anyway.

The team that finally works

One thing I haven’t mentioned yet: I didn’t get here alone.

For most of my career, I had the wrong co-founders. ACR collapsed partly because of market forces, partly because of geography, but also partly because the team wasn’t right. When trust breaks down at the top, everything downstream suffers.

Starting around 2019, something changed. I found my people.

Three Headed Monster - THM - was a game publisher where we built Beyond Humanity: Colonies. The most complicated board game ever made, in terms of components. IoT electronics on the table. RFID-powered playing cards. Companion app. Software everywhere.

It should have been impossible. But we did it, because the team worked.

Casey McBeath. Przemek Kuśmierek. Michał Pena. Artur Kurasiński. These are people who don’t put a knife in your back. Who show up when it’s hard. Who match intensity when intensity is needed and tell you to take a walk when you’re running on fumes.

Having co-founders in their 40s and 50s is part of the greybeard advantage. We’ve all been burned before. We’ve all seen partnerships fail. We know what we’re looking for now, and we know the warning signs.

A team of greybeards isn’t slower than a team of young founders. It’s more deliberate. Less drama, more execution. Fewer late-night fights about equity and more late-night fights about product. The right problems to have.

What I’ve learned to protect

A few things that took decades to figure out:

Supportive partner.

I haven’t been alone for most of my life. That’s not an accident - it’s a choice I made and keep making. My wife has been through ACR, through THM, through Migam and Omea. She’s the one who says “we’re going on a walk” when I’ve been staring at code for 16 hours and my body is screaming.

You can’t do this alone. Or you can, but you’ll break in ways that are hard to fix.

Hobbies make you sane.

I wouldn’t be building Omea if I weren’t a gamer. PC games, board games, pen-and-paper RPGs since I was young. I understand WHY we’re building what we’re building because I’ve spent decades as a player. That’s not frivolous - it’s foundational.

Your hobbies make you interesting. They also make you good at things you couldn’t have predicted. My understanding of narrative structure comes from being a Game Master. My understanding of player psychology comes from watching people interact with systems for fun. Work and life aren’t separate - they feed each other.

Vacations aren’t optional.

I started taking real vacations around 2022. Workations at first, then actual unplugged time. Hiking in places with no cell reception. Letting my brain work on problems without forcing it.

The multiplayer architecture for Omea came to me in King’s Canyon, watching an avalanche rumble down a mountainside while I was very much not at my desk. Your brain doesn’t stop working when you leave the office. Sometimes it works better.

The cult of hustle says vacations are for the weak. Experience says vacations are where the breakthroughs hide.

The actual advantage

So what’s the real greybeard edge?

Survival itself.

I’m still here. After ACR, after the failures I haven’t written about, after the moments when quitting would’ve been easier - I’m still building.

That’s not nothing. That’s the credential that can’t be faked.

Every failure taught me something the 25-year-old hasn’t learned yet. Not because they’re not smart - they might be smarter. But because some lessons only come from living through the thing. You can read about failure. You can study case studies. But you don’t KNOW it until you’ve watched something you built turn to dust.

The combination play.

The winning formula isn’t old versus young. It’s old AND young together.

Surround yourself with people who have what you lack. Hire the 28-year-old who codes faster than you ever did. Work with the 35-year-old who understands TikTok marketing in ways you never will. Be the greybeard for others while still finding your own mentors.

GTC San Jose 2025 was a revelation. Being among the craziest of the crazy, surrounded by people building things that will change the world. Some of them were 25. Some of them were 55. The energy wasn’t about age - it was about ambition matched with competence.

I want to be part of that community. Not as the old guy who remembers when, but as someone still building, still shipping, still in the game.

The invitation

To other greybeards out there, feeling like maybe they missed their window:

You didn’t. The window is still open. Maybe it’s open wider than it was when you were 25, because now you actually know what you’re doing.

The patterns you’ve learned. The failures you’ve survived. The calm you’ve earned through exposure to chaos. The relationships you’ve built over decades. The self-knowledge that only comes from years of getting it wrong.

These are assets. Real ones. The 25-year-old has energy. You have wisdom. Both are needed. The world is not short on young founders with big ideas. It might be short on experienced builders who’ve seen cycles and know how to survive them.

To the young founders reading this:

Find your greybeards. Not to tell you what to do - to tell you what they wish they’d known. To pattern-match the warning signs you don’t recognize yet. To be calm when you’re panicking because they’ve been through the panic before.

The best teams I’ve seen combine young energy with old wisdom. Neither is sufficient alone.

Some days the impostor syndrome still wins. Some days my body reminds me that it’s not 25 anymore and the invoices from past crunches are still coming due. Some days I stand in rooms full of younger, faster, maybe smarter founders and wonder what I’m doing there.

But then I remember: I’ve survived things they haven’t faced yet. I’ve learned lessons they’ll have to learn the hard way. I’m still building, still shipping, still in the arena.

The apple juice in my hand at that Paris party wasn’t champagne. That’s fine. I was there anyway. Passenger in my meatsuit or not, I was in the room.

That’s the greybeard advantage. Not certainty. Not confidence. Just survival, compounded over decades, plus the stubbornness to keep going.

Less talking, more building. See you next week.

Max

PS. To every founder over 40 feeling like they’re too late: you’re not. You’re just starting with better equipment. The scars are features, not bugs.

PS.2 Next week: (probably about) ADHD and the founder brain. How something I fought my whole life became (mostly) a superpower. Fair warning - that one’s going to get personal.

Years ago, I built myself a digital doppelganger. An Alpaca model - one of the early Llama derivatives, running on GPUs in a solar-powered garage just outside Warsaw. I fed it RAGs full of my notes, my thinking patterns, my half-baked ideas. Constantly upgraded it as new models dropped. My own environment for any kind of work. A second brain that actually understood what I was trying to build.

It was beautiful. It was expensive. It required two air conditioning units that still couldn’t keep the garage below sauna temperatures.

And now? That dream lives in a $20/month subscription. Claude does what CoMax versions one through forty-seven struggled to do. Sonnet handles my daily thinking. Opus steps in for the heavy lifting. Sometimes I wonder what all that electricity was for.

But I don’t regret a single watt.

The Garage Era (2022-2025, RIP)

Here’s what nobody tells you about running your own GPU cluster: it’s not the hardware that breaks you. It’s the heat.

Between mid-2022 and early 2025, I maintained a small empire of computing power in my garage. Over twenty GPUs total across multiple rigs, four RTX 3060s per Opteron server, all of it solar-powered because I’m Polish and electricity isn’t cheap. The setup was perfect for training models, running inference locally, maintaining complete control over my AI experiments.

The setup was also turning my house into a convection oven. At least during summer.

The garage shared a wall with the bathroom. During summer, that wall radiated heat like it had a personal vendetta against comfortable showers. Two industrial air conditioning units ran constantly. They lost the battle daily. Heat bled through every surface, every crack, every architectural weakness the builders had thoughtfully included.

Winter was different. Twenty GPUs make excellent space heaters. Our heating bills dropped noticeably. The bathroom wall became pleasantly warm. For a few months each year, the setup almost made sense.

For a while, I told myself this was the price of independence. No cloud bills. No vendor lock-in. Complete control over my infrastructure. Free heating in winter, sauna in summer.

Then the rigs started sitting idle.

Cloud computing had gotten good. Really good. Spinning up an L40S on RunPod took thirty seconds. No maintenance. No heat management. No seasonal trade-offs.

The hardware did nothing for months. I was paying for solar panels to power machines that weren’t running. The cloud was just... easier.

So I sold the rigs. All of them.

No regrets. Sometimes the best tool is the one you don’t have to maintain.

The Stack (honest version)

Every tech person eventually writes a “my setup” post. Most of them are exercises in subtle bragging disguised as helpful content. Here’s my honest version, including the embarrassing parts.

Hardware I actually use

MacBook Pro M2 Pro 16-inch, 16GB unified memory, 1TB SSD

My daily driver. Also my biggest frustration.

The M2 Pro chip is a marvel. The screen is gorgeous. The battery life lets me work from Warsaw cafes without hunting for outlets. But 16GB of RAM in 2025 is a chokepoint. I run Claude Code, VS Code, Docker, Ollama, a browser with too many tabs, and suddenly I’m watching the memory pressure gauge turn red.

CPU isn’t the problem. Memory is. I need 32GB minimum to run comfortably. The upgrade is coming.

The laptop is also covered in stickers. This matters more than it should.

I’ve collected them from everywhere: conferences, company visits, random encounters. The Meta logo from their campus gift shop. NVIDIA from their headquarters in San Jose. Startups that no longer exist. AI labs that pivoted three times. Each sticker is a small piece of a story, a reminder of somewhere I’ve been or something I believed in at the time.

When I upgrade to a new MacBook, this is what I’ll miss most. Not the machine - the archaeology of stickers that turned a generic aluminum slab into something personal.

iPad Pro M5 13-inch, 16GB unified memory, 1TB SSD, nano-texture glass

Plus Magic Keyboard and Pencil Pro. A recent addition to handle my travel addiction.

The Magic Keyboard is pure magic, as advertised. It transforms the iPad into something laptop-adjacent. The Pencil Pro? Still learning. It’s new territory for me. I’m used to thinking with keyboards, not styluses. But the potential is there for sketching concepts and visual thinking.

I fly between the US and Europe constantly, five round trips in 2025 alone. The MacBook is powerful but heavy, thick, clumsy. The iPad is what I reach for when I’m moving.

Mostly communication right now. Email, messages, document review. I still haven’t figured out how to run Claude Code comfortably on it. That’s a workflow problem I need to solve, because the iPad is technically capable of everything I need. I’m the bottleneck.

The nano-texture glass, though - that's the real revelation. I didn't fully appreciate it until I tried working outside on a sunny day. No glare. No squinting. No hunting for shade or awkwardly angling the screen. It just works. For someone who hates being trapped indoors and dreams of year-round garden computing, this changes everything. When I upgrade my MacBook, nano-texture is non-negotiable. The price premium is worth every penny for anyone who works outside regularly.

The linux box

Ryzen 9 9950X. 64GB DDR5. RTX 3090 with 24GB VRAM. Water-cooled. 5TB of solid-state storage plus 8TB of spinning rust for backups. Ubuntu with Gnome so I have a mouse pointer to click on things, though I mainly access it via SSH from another room.

This is the workhorse. The CUDA box. (For my Polish readers: yes, it's also the "cuda" box - the miracles box. Sometimes NVIDIA's naming works better than they realize.) When I need to run something locally that actually requires GPU compute, this is where it happens.

It also dual-boots Windows 11. Purely for gaming. Steam and Epic Games. Sometimes you need to shoot aliens to decompress.

The monitor

Alienware 32-inch, 4K, 240Hz, OLED.

This matters more than most people realize. Refresh rate isn’t just for gamers - it’s for anyone who stares at screens for eight-plus hours daily. The difference between 60Hz and 120Hz is noticeable. The difference between 120Hz and 240Hz? Subtle, but my eyes thank me at the end of long days.

My MacBook and iPad both run at 120Hz, which is good. But the Alienware at 240Hz with that OLED panel? That’s the dream setup. Deep blacks, no backlight bleed, buttery smooth motion. The brightness helps in well-lit rooms. The contrast helps everywhere.

Apple still hasn’t put OLED in their MacBook lineup, which is genuinely frustrating. They’ll get there eventually. Until then, serious work happens at the desk with the Alienware.

If you’re spending significant time in front of screens, invest in refresh rate and panel quality. Your eyes are doing the heavy lifting. Treat them well.

iPhone 16 Pro Max

It’s a phone. You know what phones do.

The stuff that actually matters

Shokz OpenRun Pro, bone conduction headphones for everyday use. Open-ear design means I can hear the world around me while listening to Spotify. Currently obsessed with their Chill Electronic mixes.

Sony noise-canceling headphones - for when I need to disappear. Airplanes, trains, open offices, anywhere the world gets too loud. They create a bubble of focus.

Oakley Holbrook with prescription Prizm Gaming lenses - yellow tint, cuts blue light aggressively. Got the prescription from a military optometrist in San Diego. Wasn’t skeptical going in, just wanted to try them. Now I can’t imagine working without them. My eyes last longer. The end-of-day fatigue that used to hit around 6 PM now shows up around 10 PM. Worth every penny.

A mechanical keyboard from a small shop in San Jose - compact (no number pad), yet the heaviest keyboard I’ve ever owned. Built like a weapon. I had it tuned with quieter switches, otherwise my wife would have killed me in my sleep. Now there’s just a risk, not a certainty. The tactile feedback is perfect for long coding sessions.

The embarrassing truth

I own an electric standing desk with adjustable height. I have never used the standing feature for actual work.

My posture can best be described as “damaged crash test dummy”. I don’t sit in my chair so much as exist in it like a fluid, constantly sliding down, spine curved in ways that would make an ergonomics consultant weep.

My back hates me. This is entirely my fault.

I’ve made resolutions to fix this. Failed resolutions only. The standing desk mocks me daily. I respond by continuing to sit like a human puddle and complaining about the consequences.

How I actually work

Let me break down what my days look like, because tools without workflow context are just shopping lists.

(If you want to see what this looks like in practice, I’ve included a screenshot of my desktop. Yes, all those windows are open simultaneously. Yes, this is normal. Welcome to ADHD-powered productivity.)

My work splits roughly 40/30/30:

40% communication - email, direct messaging, coordinating across time zones. Running Omea means talking to the team in Poland while setting up meetings in California. Advisory work at Migam is lighter now - they have a great engineer leading the AI development, so I’m more strategic than hands-on.

30% code-related - reviews, experiments, R&D. I’m not writing production code every day, but I’m deep in the technical decisions. Architecture reviews. Prototype experiments. Debugging sessions when something breaks in interesting ways.

30% brainstorming and conceptualization - strategy, product thinking, working through problems that don’t have clear solutions yet.

Claude touches all three buckets. This is not an exaggeration.

Communication

I use Claude Projects heavily. Not for generating generic email templates - for actually thinking through complex communication.

When I’m preparing for an important conversation, I’ll dump context into a project and work through the angles. What am I trying to achieve? What does the other person care about? What’s the best framing? Claude helps me see blind spots in my own thinking.

For everyday writing, Claude catches the moments when I’m being unclear, too aggressive, or burying the actual point under too much context. It’s like having an editor who’s always available and never annoyed.

Code

Claude Code, 100% of the time.

I experimented with Cursor for a while. It was fine. Good, even. Then Darek - our Game Director at Omea - pushed the whole team to adopt Claude Code heavily. Michał Pena showed me how to get started.

I never looked back.

The way Claude Code integrates with my thinking is different from other tools. It’s not autocomplete on steroids. It’s closer to pair programming with someone who has infinite patience, broad knowledge, and no ego about being wrong.

When I’m debugging something weird, I don’t just get suggestions - I get reasoning. When I’m architecting a new feature, I can think out loud and get pushback on bad ideas before I commit to them.

Cursor? I genuinely forget it exists now.

The painful part: flying without internet. Five transatlantic trips in 2025, hours in the air with no Claude Code access. It feels like trying to work with one hand tied behind my back. I’ve tried workarounds - downloading documentation, preparing local materials, running local models - but nothing replaces the real thing.

Brainstorming

This is where Claude becomes CoMax 2.0.

Remember the digital doppelganger I built in the garage? The dream was a second brain that could keep up with my thinking, challenge my assumptions, help me iterate faster than I could alone.

Claude is that dream, realized.

I use it to bullshit-test ideas. Throw a concept at it, see what breaks. “Here’s what I’m thinking about the narrative architecture - what am I missing?” And I get actual useful pushback, not validation seeking.

I use it to explore rabbit holes. When I’m curious about something tangential, I can go deep without losing the thread of what I was originally working on.

I use it to maintain context across weeks of thinking. Claude Projects let me build up shared understanding over time, so I’m not starting from zero every conversation.

The iterating never stops. Concepts get refined, challenged, rebuilt. It’s like having a thinking partner who never gets tired and never judges you for changing your mind.

The cloud architecture

The garage is gone, but the compute needs didn’t disappear. They just moved to better-managed infrastructure.

Here’s where the actual work happens:

Cerebras - our main production inference for Omea. The speed is impossible to beat. Our NIA (Narrative Intelligence Architecture) hits around 1,000 tokens per second on Cerebras. On NVIDIA GPUs? Maybe 200 tokens per second. Five times slower.

When you’re building interactive storytelling where response latency matters, that difference is everything. Players don’t want to wait. Cerebras lets us deliver experiences that feel immediate.

The landscape might shift soon - NVIDIA semi-acquired Groq, Cerebras’s biggest competitor. But for now, Cerebras remains the speed king.

Oracle - dedicated machines, not regular cloud instances. Part of our inference infrastructure, though not the primary path.

Azure - production backend, less focused on inference, more on the supporting systems.

RunPod - on-demand GPUs when ours are busy. Right now I’ve got two dedicated L40S instances running: one training a small experimental model, one handling inference for a text-to-speech beta we’re testing.

RunPod is perfect for immediate needs. Team needs extra GPU capacity? Spun up in minutes. No long-term commitment, pay for what you use.

Anthropic - API December bill

Over $3,500 in API costs.

Not for Omea - for Migam. Building synthetic datasets for American Sign Language and PJM (Polski Język Migowy - Polish Sign Language). The process is intensive: generating training data, running vocabulary density testing, using LLM-as-judge to validate quality across everything.

When you’re asking Opus to read and evaluate millions of tokens, the bills add up fast. Sonnet handles volume. Opus handles the heavy lifting where quality can’t be compromised. Haiku is increasingly part of the mix for lighter tasks.

It’s expensive. It’s worth it. Sign language AI doesn’t build itself on the cheap.

The long-running tasks

Some jobs take hours. Some take days.

I run them in Docker containers or Screen-based Python scripts on my Linux box. SSH in from wherever I am, kick off the process, check back periodically. Sometimes on RunPod with the team when we need more firepower than my single RTX 3090 can provide.

Dataset processing. Model evaluation. Synthetic data generation. The unsexy work that makes the sexy demos possible.

The future: NVIDIA DGX Spark

Speaking of hardware I’m watching - NVIDIA DGX Spark, their personal AI supercomputer. A desktop box with the GB10 Grace Blackwell chip, 128GB unified memory, capable of running 200B models. Reasonable price tag at three grand, available now.

For an AI nomad like me, constantly traveling between continents and annoyed by offline limitations, this is interesting. A personal AI party that fits on a desk and doesn’t require my wife to suffer through summer bathroom saunas. I’ll definitely try it out.

The local fallback

Sometimes there’s no internet. Given how much I travel, this happens more than I’d like.

My current local model of choice: Granite 4 Micro from IBM.

It’s a hybrid architecture - transformer mixed with Mamba - that provides surprising capability for its size. Runs comfortably on my RAM-constrained MacBook. The memory footprint is reasonable. The quality is good enough for basic tasks when Claude isn’t available.

But let’s be clear: local models are a fallback, not a preference. When I land and get internet back, I’m immediately back to Claude. The quality difference is real.

The software philosophy

Here’s where the opinions get spicy.

What I use

Development:

• VS Code with Claude Code extension - the core of everything

• Claude Code MAX for coding and deep research

• Claude Team for everyday conversations and brainstorming

• Enterprise Anthropic API - Sonnet for volume, Opus for heavy lifting, Haiku for lighter tasks

Terminal:

• Warp - not for its AI features (I barely use them), just for the UX. It looks good. It feels good. Sometimes aesthetics matter.

Local development stack:

• Ollama - manages local models for offline work

• Miniconda - Python environment management

• Brew - brings Linux-native tools to macOS

• Docker - keeps experiments isolated, prevents my machine from becoming a dependency graveyard

Team collaboration:

• Google Workspace (enterprise) - email, Drive, Docs

• Discord for Omea - love it, perfect for our team culture

• Slack for Migam - hate it, but it’s what they use

Why do I hate Slack? It feels corporate-y in a way Discord doesn’t. Discord grew up around communities and gaming. Slack grew up around enterprise sales. You can feel the difference in every interaction.

Thinking tools:

• Apple Freeform - for drawing concepts, schematics, visual thinking

• Apple Notes - for capturing thoughts in the moment

• Canva - replaced the Adobe Creative Suite behemoth. Good enough for what I need, none of the subscription hell.

Communication:

• WhatsApp primarily

• SMS/iMessage for certain contacts

• Email when formality matters

Search:

• Perplexity, occasionally. The quality isn’t there, even when it’s using Sonnet under the hood. Native Claude always wins.

What I don’t use

ChatGPT.

At all.

I canceled my subscription over a year ago. Haven’t opened the app since. Tried the API a few times when testing something specific. Came back to Haiku/Sonnet/Opus every single time.

Let me be clear: I respect the researchers at OpenAI. Brilliant people doing important work. But the company? The “Open” left OpenAI a long time ago. I still remember when they used to drop actual gifts to the community - Whisper was incredible, genuinely useful, freely shared. That spirit died somewhere along the way.

More importantly: Claude is just better.

I’ve run the comparisons. I’ve tried to be fair. Every time I use a GPT model for something complex, I find myself wishing I was using Sonnet. The reasoning is clearer. The outputs are more useful. The edge cases are handled better.

So I stopped pretending I needed to hedge my bets across multiple LLMs. I went all-in.

Team no-drama. Team Anthropic.

The whole Omea team has Claude access now. Most of them MAX accounts. We build AI that tells stories using AI assistance. It’s not ironic - it’s obvious. You use the best tools to make the best things.

The human in the loop

Tools are great. Tools are also insufficient.

Here’s what the tools can’t fix:

The crunches. When an idea grabs me or a deadline looms, I’ll do sixteen-hour days. Marathon sessions fueled by coffee and hyperfocus. I’m trying to limit these. I’m mostly failing.

The schedule. Six days a week, typically four to eight hours at the computer. Crunch periods have different rules entirely. Sustainable? Probably not. Stopping? Not yet.

The restlessness. I hate being tied to one chair in one spot. I work outside whenever I can - in the garden, on the terrace, anywhere that isn’t the same four walls.

Warsaw weather makes this difficult. Cold winters. Unpredictable summers. Limited outdoor working days.

But this problem gets solved Q1 2026.

I’m moving to Silicon Valley.

The garden work sessions are about to get a serious upgrade. California weather means year-round outdoor computing. No more checking forecasts before deciding where to sit.

The ADHD. It’s not a bug, it’s a feature, most of the time. Hyperfocus is a superpower when pointed at the right target. The ability to context-switch rapidly helps when you’re running multiple projects.

But it also means I need external structure. Claude Projects help. Strict routines help. Having a team that keeps me accountable helps.

Spotify’s Chill Electronic mix plays constantly. Not because I need the music, but because consistent background sound keeps part of my brain occupied so the rest can focus.

The body. The crash test dummy posture. The back pain. The standing desk I don’t use. The failed resolutions.

Someday I’ll figure this out. Today is not that day.

Closing: the philosophy

Here’s what I’ve learned about tools:

They’re expressions of philosophy, not just productivity choices.

I went all-in on Claude because the results were better. Not because of marketing. Not because of ecosystem lock-in. Not because everyone else was doing it. The outputs were simply superior for how I work and what I’m building.

When something works, you commit. You stop hedging. You stop maintaining optionality for its own sake.

The same philosophy applies to everything else:

The MacBook covered in stickers isn’t just a laptop - it’s a statement that tools should feel personal, should carry history, should mean something beyond their specifications.

The garage full of GPUs wasn’t just infrastructure - it was the belief that controlling your own compute mattered. Until it didn’t anymore, at which point I let it go without sentiment.

The standing desk I don’t use isn’t just furniture - it’s an honest reminder that buying tools doesn’t equal using them, and that I’m still figuring out how to take care of myself while taking care of everything else.

From a solar-powered garage with twenty-plus GPUs to a MacBook with insufficient RAM and a Claude subscription. From CoMax v1 running on overheated hardware to Sonnet doing everything I dreamed my doppelganger would do.

The tools changed. The obsession didn’t.

Less talking, more building.

Max

PS. This essay is about the tools I use to build products, not run them. The production infrastructure for Omea - the model architecture, the NIA system, how Cerebras actually deploys - is a different story. Maybe a future essay, if you want it.

PS2. Obviously, this has been written on my Mac and iPad using Claude’s help all the way - from initial concept, through drafting, to editing and final review. Practicing what I preach.

A pattern so fundamental that researchers at Princeton discovered something remarkable: when you listen to someone telling a story that follows this structure, your brain waves literally synchronize with the storyteller’s. Your neurons fire in the same patterns as theirs. You get on the same wavelength - not metaphorically, but measurably, observably, neurologically.

This isn’t mysticism. This isn’t creative writing advice from a blog post. This is peer-reviewed neuroscience, and it explains something that Joseph Campbell discovered seventy-five years ago by studying myths from cultures that had never had contact with each other.

Every culture on Earth, separated by oceans and millennia, tells variations of the same story.

The Greeks told it about Odysseus. The Norse told it about Odin. The Hindus told it about Arjuna. Native American tribes told it about countless heroes. African griots passed it down through generations. Aboriginal Australians encoded it in their Dreamtime stories. The Japanese told it. The Celts told it. The Mesopotamians carved it into clay tablets five thousand years ago.

The same story. The same structure. The same emotional beats.

Campbell called it the monomyth - the one story. We know it better as the Hero’s Journey.

And here’s why this matters to you, reading this newsletter about building startups and making impossible things happen: this pattern isn’t just for novelists and screenwriters. It’s the hidden architecture behind every pitch that makes investors lean forward. It’s the structure that turns a product demo into an emotional experience. It’s the difference between a company that people use and a company that people believe in.

It’s also the foundation of everything we’re building at Omea - an AI that tells stories you actually want to live inside. And the reason that works isn’t because we’re clever engineers. It’s because we’re building on fifty thousand years of human narrative evolution.

I first discovered Campbell’s work twenty-five years ago, when I was trying to become a better Game Master for pen-and-paper RPGs. I wanted to understand why some adventures felt epic and others felt flat, why some sessions left players talking for weeks and others were forgotten by the next morning. The Hero’s Journey was the answer I didn’t know I was looking for.

A quarter century later, I’m still using it. Every day. In how we design narrative AI, in how we pitch to investors, in how I think about my own journey as a founder.

Let me show you what I mean.

The man who found the One Story

Joseph Campbell was a professor of literature at Sarah Lawrence College who spent his career doing something unusual: instead of studying how myths from different cultures differed, he studied how they were the same.

This was counterintuitive. The academic tradition was to emphasize differences - to show how Greek mythology was distinctly Greek, how Hindu legends reflected specifically Hindu worldviews, how Native American stories emerged from uniquely Native American experiences. Campbell went the other direction. He asked: what if all these stories, from all these places, share something fundamental?

What he found changed everything we understand about storytelling.

In 1949, Campbell published “The hero with a thousand faces”, a book that would influence generations of writers, filmmakers, and storytellers. In it, he laid out a pattern that appeared across every mythology he studied - a universal story structure he called the monomyth.

Campbell summarized it like this:

Departure. Initiation. Return.

That’s the skeleton. The hero leaves home, faces trials, and comes back transformed. Simple enough. But Campbell went deeper. He identified seventeen specific stages within this structure, each appearing across cultures that had never communicated with each other.

The Greek hero Odysseus and the Babylonian hero Gilgamesh - separated by centuries and hundreds of miles - follow the same narrative beats. The Buddha’s journey to enlightenment mirrors the structure of European fairy tales. African trickster gods undergo the same transformations as Norse warriors.

This wasn’t a coincidence. It couldn’t be. These cultures had no contact, no shared written tradition, no way to copy each other’s stories. The pattern had to come from somewhere else.

Campbell, influenced by the psychologist Carl Jung, believed the pattern emerged from something universal in human psychology - what Jung called the collective unconscious. The Hero’s Journey, in this view, isn’t a template that storytellers choose to use. It’s a pattern that reflects something fundamental about how human beings experience growth, challenge, and transformation.

But Campbell was working in 1949. He didn’t have fMRI machines. He didn’t have the tools to look inside the brain and see what actually happens when we hear these stories.

We do now.

Your brain on story

In the decades since Campbell’s work, neuroscientists have been able to study what happens in the brain when we engage with narratives. What they’ve found explains why the Hero’s Journey works - and why it works so consistently across all of human history.

Let’s start with a remarkable discovery from Princeton University.

Researcher Uri Hasson and his team used fMRI scanning to observe the brains of people telling and listening to stories. What they found was extraordinary: the brain activity of the listener began to mirror the brain activity of the storyteller. Not just in the language-processing areas you’d expect, but across multiple regions of the brain.

They called this phenomenon “neural coupling”.

When you’re engaged with a compelling story, your neurons fire in patterns that synchronize with the person telling it. You’re not just processing information - you’re experiencing a kind of mental alignment with another human being. The storyteller’s brain and your brain are, quite literally, on the same wavelength.

This doesn’t happen when you’re reading a list of facts. It doesn’t happen when you’re looking at a spreadsheet. It happens with stories - particularly stories that follow patterns your brain recognizes and expects.

But neural coupling is just the beginning.

Paul Zak, a neuroeconomist at Claremont Graduate University, has spent years studying the neurochemical effects of storytelling. His research focuses on oxytocin - often called the “love hormone” or “trust molecule” - which plays a crucial role in human bonding and social connection.

Zak’s lab discovered that compelling stories trigger the brain to release oxytocin. Not metaphorically. Measurably. They drew blood from subjects before and after exposure to emotional narratives and found significant increases in oxytocin levels.

Here’s where it gets interesting for anyone who wants to persuade, inspire, or connect with other humans: Zak found that when stories caused oxytocin release, people became more generous, more trusting, and more likely to take action. In one experiment, participants who watched emotionally engaging stories donated 57% more money to charity than a control group. The oxytocin made them care.

Think about what this means. When you tell a story that follows the pattern humans are wired to recognize - the Hero’s Journey pattern - you’re not just communicating information. You’re triggering a neurochemical response that makes your audience more empathetic, more trusting, and more likely to act.

This is why you cry at movies about fictional characters. This is why you remember the plot of a film you saw twenty years ago but can’t remember what you read in an email yesterday. This is why stories have been humanity’s primary tool for transmitting knowledge, values, and culture since before we had writing.

The brain also releases dopamine during compelling narratives - particularly during moments of rising tension and anticipation. Dopamine is associated with motivation, attention, and reward. It’s what keeps you watching “just one more episode” at 2 AM. The Hero’s Journey structure, with its systematic building of tension through trials and obstacles toward a climax, is essentially a dopamine-optimization machine.

There’s also the phenomenon psychologists call “narrative transport” - the experience of being so absorbed in a story that you lose awareness of your surroundings. Research shows that when we’re transported into a narrative, we process the events as if they’re happening to us. The brain’s distinction between “real” experiences and “story” experiences blurs. We feel the hero’s fear, triumph, and transformation because, neurologically, we’re experiencing it with them.

This is why the Hero’s Journey works. Not because it’s a clever template that some writer invented. Because it maps to the way human brains process experience, growth, and meaning. Because evolution spent fifty thousand years optimizing our neural architecture to respond to exactly this pattern.

When Campbell found the same story in every culture, he was finding evidence of something biological. The monomyth isn’t a cultural artifact. It’s a neurological one.

The Twelve Stages

Campbell’s original formulation included seventeen stages, grouped into three main phases: Departure, Initiation, and Return. In 1985, a Hollywood development executive named Christopher Vogler wrote a seven-page memo that would change the film industry - a practical adaptation of Campbell’s work called “A practical guide to the hero with a thousand faces”.

Vogler’s memo, later expanded into the book “The writer’s journey,” distilled Campbell’s seventeen stages into twelve more practical ones. This is the version that Hollywood uses. It’s the version I’ll walk through here, because it’s the most useful for anyone trying to apply this pattern to their own work.

But first, a warning: this isn’t a rigid formula. Not every story includes all twelve stages. Not every story presents them in exactly this order. The Hero’s Journey is a pattern, not a prescription. The best storytellers use it as a foundation and then play with it, subvert it, combine stages, or skip them entirely when the story demands it.

Think of it as a map of the territory, not a set of turn-by-turn directions.

Act One: departure

Stage 1: the ordinary world

Every journey begins somewhere, and the Hero’s Journey begins in the ordinary world - the hero’s normal life before the adventure starts.

This stage does crucial work. It establishes who the hero is before they’re transformed. It shows us their daily life, their relationships, their limitations. It makes the hero relatable - “this person is like me, living a normal life” - so that when extraordinary things start happening, we’re invested in the outcome.

Luke Skywalker is a farm boy on a backwater planet, staring at the twin suns and dreaming of something more. Neo is a programmer in a cubicle, sensing that something is wrong with the world but unable to articulate what. Frodo is a hobbit in the Shire, comfortable and provincial, with no ambitions beyond his next meal.

The ordinary world shows us what the hero stands to lose. It gives the adventure stakes. Without it, we don’t care what happens next.

For founders, the ordinary world is your life before the startup. The job you had. The problem you saw that others didn’t. The restlessness that told you there had to be something more.

Stage 2: the call to adventure

Something happens that disrupts the ordinary world. An invitation arrives. A challenge presents itself. A discovery changes everything.

This is the moment when the story actually begins - when the hero is confronted with the possibility of a different life. The call can be external (a message, a challenge, a threat) or internal (a realization, a desire, a vision).

Luke receives a holographic message from a princess in distress. Neo is told to follow the white rabbit. Frodo inherits a ring that turns out to be far more than a family heirloom.

The call to adventure represents the story asking its central question: will this person accept the challenge? Will they step out of their ordinary world and into the unknown?

For founders, this is the moment of insight. The idea that won’t leave you alone. The problem you realize you might be able to solve. The opportunity that seems too big to ignore.

Stage 3: refusal of the call

Almost always, the hero hesitates.

This stage might seem counterintuitive - why would we want our hero to refuse the adventure? But the refusal serves an important purpose. It shows us that the journey is genuinely difficult, genuinely risky. It shows us that the hero is human, with fears and doubts and obligations that make sense.

A hero who leaps into adventure without hesitation isn’t relatable. We don’t trust their judgment. We don’t believe in their eventual success because we never saw them wrestle with the decision.

Luke says he can’t leave - he has to help with the harvest, he has obligations to his uncle. Neo runs from the agents at first, unwilling to believe what Morpheus is telling him. Frodo tries to give the ring away to Gandalf.

The refusal also raises the stakes. It tells us that whatever force eventually overcomes the hero’s hesitation must be powerful indeed.

For founders, this is all the reasons you almost didn’t start. The safe path you could have taken. The doubts that still wake you up at 3 AM. Every successful founder I know can tell you about the moment they almost chose differently.

Stage 4: meeting the mentor

The hero encounters a guide - someone who provides wisdom, training, tools, or simply encouragement. The mentor has been on their own journey and has knowledge the hero needs.

Crucially, the mentor doesn’t complete the journey for the hero. They enable the hero to complete it themselves. The mentor provides what’s needed and then steps back.

Obi-Wan Kenobi gives Luke his father’s lightsaber and teaches him about the Force. Morpheus shows Neo the truth about the Matrix and trains him to operate within it. Gandalf provides Frodo with guidance and protection, but he can’t carry the ring.

The mentor archetype is powerful because it represents the transmission of knowledge across generations - the way wisdom passes from those who’ve been through the fire to those who are about to face it.

For founders, mentors come in many forms. The advisor who believed in you before you believed in yourself. The book that changed your thinking. The conversation that gave you permission to try. For me, one of those mentors was Kelly Johnson - not in person, but through his writing and the Skunk Works principles I’ve written about before.

Stage 5: crossing the threshold

The hero commits. They leave the ordinary world behind and enter the special world - the realm of adventure, challenge, and transformation.

This is the point of no return. Once the threshold is crossed, going back to the old life becomes impossible. The hero has chosen their path.

Luke leaves Tatooine after his family is killed - there’s nothing left to return to. Neo takes the red pill. Frodo leaves the Shire knowing he may never come back.

The threshold crossing is often marked by a confrontation with a “threshold guardian” - some obstacle or challenge that tests whether the hero is truly ready to enter the special world. Only those who are committed can pass.

For founders, crossing the threshold is quitting your job. Taking the first investment. Shipping the first version of the product. Making the commitment that transforms “interesting idea” into “company”.

Act Two: initiation

Stage 6: tests, allies, and enemies

The hero enters the special world and must learn its rules. They face challenges, build a team, and discover who can be trusted.

This stage is often where the bulk of the story happens. The hero is tested repeatedly, gaining skills and allies while encountering obstacles and enemies. Each test prepares them for the greater challenges ahead.

Luke learns to use the Force, meets Han Solo and Chewbacca, navigates the politics of the Rebellion. Neo trains in the construct, meets the crew of the Nebuchadnezzar, learns to see the Matrix for what it is. Frodo journeys through Middle-earth, gathering the Fellowship, facing dangers at every turn.

For founders, this is the startup grind. Building the team. Landing early customers. Learning the market. Discovering which competitors will try to destroy you and which partners will help you succeed. Each project harder than the last - by design.

Stage 7: approach to the inmost cave

The hero prepares for the central ordeal. Tension builds. The stakes become clearer. Everything so far has been preparation for what comes next.

This stage often involves reconnaissance, planning, or confronting fears that will be relevant in the ordeal. The hero may pause to reflect on how far they’ve come and steel themselves for what lies ahead.

The Rebels analyze the Death Star plans and prepare for the assault. Neo goes to see the Oracle, confronting questions about his own identity and destiny. The Fellowship approaches the Mines of Moria.

For founders, this is the approach to the make-or-break moment. Preparing for the major funding round. Getting ready for the product launch that will determine whether you survive. The deep breath before the plunge.

Stage 8: the ordeal

The central crisis. The hero faces their greatest fear, confronts death (literal or metaphorical), and undergoes a transformation.

This is the heart of the Hero’s Journey - the moment of maximum danger and maximum growth. The hero must draw on everything they’ve learned in order to survive. They may fail before they succeed. They may have to sacrifice something precious.

Luke turns off his targeting computer and trusts the Force in the Death Star trench run. Neo faces Agent Smith and is killed - then rises again as The One. Frodo reaches the Crack of Doom and finds himself unable to destroy the ring.

The ordeal often involves a symbolic death and rebirth. The hero who emerges is not the same person who went in. They have been transformed by the experience.

For founders, the ordeal is the moment everything almost fell apart. The near-death experience of the company. The crisis that forced you to become something more than you were. Every successful startup has at least one of these stories.

Stage 9: the reward

The hero seizes what they came for. The ordeal has been survived, and there’s a moment of celebration, relief, or recognition.

But this isn’t the end. The reward stage marks a turning point, not a conclusion. The hero has achieved something significant, but the journey isn’t over. There are still consequences to face, still a return journey to complete.

The Death Star is destroyed. Neo has discovered his power. The ring is destroyed (though not by Frodo’s choice).

For founders, the reward might be the funding round closing. The product working. The market responding. It feels like victory, and it is - but you know it’s not the end of the story.

Act Three: return

Stage 10: the road back

The journey home begins, but it’s not a simple reversal. New challenges emerge. The consequences of the hero’s actions in the special world create complications.

Often this stage involves chase sequences, ticking clocks, or forces pursuing the hero. The special world doesn’t want to let them go.

For founders, the road back is everything that comes after product-market fit. Scaling. Hiring. Competition responding. The new challenges that success creates.

Stage 11: the resurrection

A final test - often the climactic confrontation of the entire story. Everything the hero has learned is tested. They must prove that their transformation is real and permanent.

This is frequently the emotional climax of the narrative, even if earlier sequences had more action. The hero faces a choice that reveals their true character.

For founders, resurrection might be the acquisition offer you turn down because it’s not right. The moment you prove that your values survive success. The test that shows whether you’ve really changed or just been lucky.

Stage 12: return with the elixir

The hero returns to the ordinary world, transformed, carrying something of value to share with others.

The elixir might be literal (a treasure, a cure, a person rescued) or metaphorical (knowledge, wisdom, a new capability). The point is that the journey has meaning beyond the individual hero. What they’ve gained benefits their community.

For founders, the elixir is impact. It’s the jobs you created, the problems you solved, the knowledge you can now share with others. It’s why this newsletter exists - to pass on what the journey has taught me.

The founder’s journey

Every pitch deck is a story. Every successful company is a narrative. Every investor who writes a check is, in some sense, buying into a Hero’s Journey.

But here’s where I need to complicate things a bit.

When I first learned about the Hero’s Journey twenty-five years ago, I was tempted to treat it as a template - plug in the stages, and your story will work. That’s not quite right. Storytelling is more art than science, and the Hero’s Journey is one tool among many. It’s a powerful tool, maybe the most powerful one, but it’s not a formula that guarantees success.

What I’ve learned over years of pitching, presenting, and persuading is this: the Hero’s Journey is most useful as a diagnostic. When a story isn’t working, mapping it against the Hero’s Journey often reveals why. When a pitch falls flat, it’s frequently because one of these stages is missing or underdeveloped.

Missing the ordinary world? Your audience doesn’t understand what’s at stake. Missing the refusal? Your journey sounds too easy to be believable. Missing the ordeal? There’s no emotional climax, no transformation that feels earned.

The pattern is also useful for understanding who the hero actually is in your story. This is where many founders go wrong.

When you’re pitching your company, you might think you’re the hero. You’re not - or at least, not always. In the story of your company, yes, you’re the hero. You received the call, crossed the threshold, faced the ordeals. That story can be powerful, and investors do want to understand your journey.

But in the story of your product, the customer is the hero. They have an ordinary world (life before your product). They have a problem (the call to adventure). Your product is the mentor - the guide that enables their transformation. Your company exists to help them complete their journey.

The best pitches weave both stories together. The founder’s journey establishes credibility and emotional connection. The customer’s journey shows why the product matters and what transformation it enables.

This is why storytelling matters in business, but it’s also why there’s no simple formula. The art is in knowing which story to tell, when, and how to make your audience care about the outcome.

Why AI can’t do this (and how we’re trying anyway)

Here’s where my obsession with the Hero’s Journey intersects with what we’re building at Omea.

The dream of interactive storytelling - narratives that respond to player choices while maintaining coherence and emotional power - has been around for decades. Games have attempted it with branching paths, where writers script every possible route. Choose-your-own-adventure books pioneered a version of it on paper.

But true interactive narrative - where the player has genuine freedom and the story adapts meaningfully to their choices - has remained elusive. And there’s a fundamental technical reason why.

Most large language models today are built on a particular architecture. They predict the next token based on what came before. They’re very good at this - good enough to write convincing paragraphs, good enough to pass professional exams, good enough to fool people into thinking they’re conversing with another human.

But this “next token prediction” approach has a limitation that becomes critical for long-form narrative: the model is always looking forward, always predicting what comes next. It doesn’t naturally maintain the kind of structural awareness that storytelling requires.

A good story isn’t just a sequence of plausible next sentences. It’s a structure. It has setup and payoff. It plants information early that becomes relevant later. It tracks character arcs and thematic threads across thousands of words. It knows where it’s going, even as it figures out how to get there.

When you’re running a pen-and-paper RPG as a Game Master - which is where I learned storytelling - you’re constantly holding the whole structure in your head. A player does something unexpected, and you adapt. But you’re adapting within a framework. You know where the story needs to go emotionally, even if the specific path is improvised.

This is incredibly hard for AI to do.

Standard approaches to AI storytelling tend to produce one of two failure modes. Either the output is rigidly scripted (branching paths that feel like you’re on rails) or it’s genuinely responsive but loses coherence over time (the story meanders, forgets what happened earlier, fails to build to a satisfying conclusion).

At Omea, we’re trying something different. Our approach - what we call the Narrative Intelligence Architecture - is designed to maintain awareness of the whole context, not just predict the next moment. Think less “what word comes next” and more “given everything that’s happened, what does this story need right now”.

The Hero’s Journey is fundamental to how this works. Not as a rigid template that every story must follow, but as a map of emotional territory. The system understands where the player is in their journey - are they still in the ordinary world? Have they crossed the threshold? Are they approaching their ordeal? - and it shapes the narrative accordingly.

Player freedom is essential. In Purple Blades, our hard sci-fi heist adventure, players can approach challenges however they want. Try to sneak into the planetary complex. Fail, and talk your way out. Or brute force it. Or find a creative solution the writers never anticipated. The system has to make all of these work while maintaining narrative coherence.

This is what I mean when I say each playthrough is unique, yet each follows a story structure that human brains recognize and respond to. The content differs wildly based on player choices. The emotional architecture remains.

Twenty-five years ago, I was trying to do this manually at a gaming table. Now we’re trying to do it with AI. The fundamental challenge is the same: how do you give people genuine agency while still delivering a story that satisfies the patterns their brains expect?

I don’t think we’ve fully solved this yet. I’m not sure anyone has. But I know the Hero’s Journey is part of the answer, because it’s been part of the answer for fifty thousand years.

My journey

I’ve been talking about the Hero’s Journey in abstract, so let me make it concrete. Let me map my own story - the one I’m living right now, the one that led to this newsletter and everything I’m building.

Ordinary world

Poland. Engineering. Building things that worked. A career in technology that was comfortable and successful by most measures, but accompanied by a restlessness I couldn’t fully explain. The sense that I was capable of more, that there was something bigger waiting, that the interesting problems were elsewhere.

Call to adventure

AI. The realization that machines could generate not just text but narratives. The insight that current approaches - chatbots, simple generators, branching scripts - weren’t good enough to create stories that actually moved people. The question that wouldn’t leave me alone: what if we could do this right?

Refusal of the call

The lessons of ACR were still fresh. I knew what failure felt like - almost a decade of building in the wrong country, with the wrong co-founders, getting outcompeted on price by Chinese manufacturers who first matched our quality and then crushed us economically. The safe path was obvious: consulting, comfortable employment, stay in Europe where I knew the rules.

Why would I risk that again?

Meeting mentors

The mentor in stories doesn’t fight the dragon for you. They prepare you to fight it yourself. Obi-Wan doesn’t defeat Vader for Luke - he teaches Luke to wield the lightsaber.

I found mentors who understood this distinction.

Przemek Kuśmierek, who had walked the impossible-project path with Migam and could speak from experience. Artur Kurasiński, who believed in crazy ideas before the evidence existed. Michał Pena, who would become CTO at Omea - the wise technical voice who keeps me from building the wrong thing brilliantly.

And two advisors who embody what mentorship actually means: Harald Nuhn and Priyank Jain. Harald, a Stanford lecturer. Priyank, IBM’s global innovation lead. Both advisors at Omea. Neither has ever handed me an investor or solved a problem for me directly. That’s not what they do.

What they do is listen. I bring them pain points, problems, worries - the messy stuff you can’t put in a pitch deck. They ask questions. They push back. They help me see what I’m missing. When I needed investors, they didn’t bring one. They spent months helping me sharpen the product-market fit, stress-test the business plan, refine the pitch until it could stand on its own.

The mentor gives you tools and wisdom. You still have to swing the sword.

And Kelly Johnson, through his writing - a mentor from the past, proving that small teams could accomplish things that should be impossible.

Crossing the threshold

Starting Omea. Committing to the US market. Burning the boats. Making the decision that transformed “interesting idea” into “this is what I’m doing with my life”.

There was a specific moment, or rather a series of moments, when going back became impossible. When I had committed enough - money, time, reputation - that the only path was forward.

Tests, allies, enemies

Building the team. Fundraising in a market that didn’t know us. Technical challenges that seemed insurmountable until they weren’t. Learning Silicon Valley’s rules while refusing to abandon the Skunk Works principles that got us this far.

Each project harder than the last. Beyond Humanity taught me about hardware, crowdfunding, and community. Migam taught me about impact and accessibility. Omea is teaching me about narrative AI and the limits of what small teams can accomplish.

The challenges keep escalating. That’s by design. Life’s too short to solve simple problems.

Approach to the inmost cave

The Bay Area trips. The conferences. The meetings with investors and partners. Standing in rooms with people whose companies are worth billions, feeling the impostor syndrome scream that I don’t belong here, that some cosmic glitch put me in a party I wasn’t invited to.

Preparing for the conversations that will determine whether Omea becomes what I believe it can become.

The ordeal

I’m in it. Right now. The company isn’t dead, but it also hasn’t achieved escape velocity. The technology works, but we haven’t proven the market. The vision is clear, but the path to get there still has moments of fog.

This is the part of the journey where the hero faces their greatest fear. Mine isn’t failure, exactly - I’ve failed before and survived. It’s the fear that I might not be good enough, that all the principles and the hard work and the belief might not be sufficient, that the story ends in an unsatisfying middle.

But here’s something I didn’t expect: writing this helps. Being open with you - whoever you are, reading this - makes the burden lighter. The fog clears a little when I put words to it. Maybe that’s why heroes in stories always find companions in the dark parts. Not to fight for them, but to witness. To make the struggle feel less alone.

The reward

Some days I can see it. The product working. Users loving it. The model validated. The reward isn’t guaranteed - that’s not how the ordeal works - but I can feel what it would be like to seize it.

The road back, the resurrection, return with elixir

I don’t know how these chapters go yet. The story isn’t over.

But I know what I want the elixir to be. Not just a successful company, though that would be nice. The elixir I want to bring back is knowledge. Proof that small teams can still build important things. Principles that work. Lessons that might help someone else make the journey.

This newsletter is part of that return, started before the journey is complete. Because sometimes you don’t wait until you have all the answers. Sometimes you share what you’ve learned so far, even while you’re still learning.

The invitation

So here’s what I want you to take from all of this.

The Hero’s Journey isn’t a writing technique. It’s not a clever framework that consultants sell. It’s a map of human experience that’s been encoded in our neurobiology over tens of thousands of years.

When you use it, you’re not manipulating your audience. You’re speaking their native language - a language older than any spoken tongue, a language written in oxytocin and dopamine and the synchronized firing of neurons.

But using this knowledge requires more than just memorizing twelve stages.

For your pitch: don’t just present information. Tell a story. Establish the ordinary world - what’s the status quo that’s broken? Show the call - what opportunity exists? Let your audience feel the ordeal - what challenges have you faced? Make the reward tangible - what have you achieved? And show them the elixir - what transformation does your product enable?

But don’t force it. Storytelling is essential for persuasion. The Hero’s Journey is one powerful structure among several. Use it when it fits. Adapt it when it doesn’t.

For your product: what journey are you taking your users on? Where’s their ordinary world? What’s the transformation you enable? Does using your product feel like a story - with progress, challenges, and rewards - or does it feel like a transaction?

The products people love aren’t just useful. They make their users feel like heroes.

For your own sanity: you’re on a Hero’s Journey right now. Whether you recognize it or not.

If you’re in the refusal stage - hearing the call but finding reasons not to answer - know that the refusal is normal. Every hero hesitates. The question is what force will eventually push you across the threshold.

If you’re in the tests stage - facing challenge after challenge, building your team, learning the rules of a new world - know that this is preparation. Each test teaches you something you’ll need for the ordeal.

If you’re in the ordeal itself - facing the moment of maximum danger, wondering if you’ll survive - know that this is where transformation happens. The hero who emerges won’t be the same person who went in. That’s the point.

And if you’ve reached your reward and are on the road back, remember that the elixir isn’t just for you. What you’ve learned has value for others. Share it.

The Hero’s Journey has been with us since before writing. Since before agriculture. Since humans first gathered around fires and told each other stories about the brave one who left, faced danger, and returned transformed.

It’s in every mythology. It’s in every religion. It’s in every blockbuster movie and bestselling novel and pitch that raised a billion dollars.

It’s carved into your brain, waiting to be activated by the right story told in the right way.

Twenty-five years ago, I discovered this pattern while trying to become a better Game Master. I thought I was learning a writing technique. I was actually learning how human minds work - and that knowledge has shaped everything I’ve built since.

Now I’m trying to teach it to an AI. The jury’s still out on whether that’s possible. But I know that whatever we build will be measured against fifty thousand years of storytelling evolution. The bar isn’t other apps. The bar is the pattern that human brains expect, demand, and respond to at the deepest neurological level.

No pressure.

Less talking, more building. See you next week.

Max

PS. If you want to go deeper on this:

Books:

• “The hero with a thousand faces” by Joseph Campbell - the original. Dense but essential.

• “The writer’s journey” by Christopher Vogler - the practical Hollywood adaptation.

• “Story” by Robert McKee - for structure obsessives and anyone who wants to understand screenwriting.

Research:

• Paul Zak’s work on oxytocin and storytelling - his TED talk is a good starting point.

• Uri Hasson’s research on neural coupling - shows what happens in the brain during narrative.

Gratitude: to the Game Masters who taught me storytelling by running unforgettable campaigns. To the players who showed me what works and what doesn’t by voting with their attention. To Campbell, who didn’t invent the pattern but found it hiding in plain sight across all of human culture.

PS2. Next week: tools of the trade. What’s actually on my desk and in my terminal. Hardware, software, the setup that makes all this building possible. Something lighter after two beasts in a row. We’ll see if I can keep it under 3000 words.

(I probably can’t)

Joseph Campbell found that every culture on Earth - Greeks, Norse, Aboriginal Australians, Mesopotamians - separated by oceans and millennia, tells the same story.

Same structure. Same emotional beats. Same pattern.

He called it the Hero’s Journey.

What Campbell didn’t know and neuroscience would prove WHY...

When you hear this pattern, your brain releases oxytocin. Your neurons synchronize with the storyteller’s. You literally get on the same wavelength.

This isn’t writing advice. It’s biology.

Next Thursday... a deep dive into how this 50000-year-old pattern shapes pitch decks, AI storytelling, and every founder’s journey.

6000 words. Bring coffee.

They expect me to say Agile. Maybe Scrum. Perhaps some fancy framework with certifications and consultants and three-day workshops in hotel conference rooms. They’re ready to nod along, to recognize the familiar acronyms, to mentally check the box that says “this guy knows what he’s doing”.

Instead, I tell them about a circus tent that smelled like a distillery. About a Swedish immigrant who could see air. About a group of engineers who built America’s first jet fighter in 143 days while the country was at war, working with hand tools and slide rules, fueled by coffee and cigarettes and the kind of determination that only exists when failure isn’t an option.

I tell them about Skunk Works.

And then I watch their faces. Because this is where people either lean in or check out. The ones who lean in - those are my people. The ones who understand that the best ideas about how to build impossible things don’t come from business schools or methodology certifications. They come from people who’ve actually done it, usually under circumstances that should have made success impossible.

This is the manifesto I’ve been trying to write for years. Every time I attempted it on LinkedIn, I’d hit the character limit and realize I was barely getting started. The philosophy that guides everything I build - from AI that tells stories to technology that helps Deaf people communicate to board games with embedded electronics - it all traces back to a set of principles developed eighty years ago by people building spy planes and stealth fighters.

If that sounds like a strange foundation for a startup in 2026, stick with me. By the time you finish reading this, you’ll either think I’m crazy or you’ll want to burn down everything you thought you knew about building products. Possibly both.

Let’s start at the beginning.

The circus tent where everything started

June 1943. The United States is deep in World War II, and there’s a problem. Nazi Germany is developing jet-powered fighter aircraft, and America has nothing to counter them. The propeller-driven planes that won the Battle of Britain are about to become obsolete, and everyone knows it.

The U.S. Army Air Forces Air Tactical Service Command approaches Lockheed Aircraft Corporation with what amounts to a desperate plea: can you build us a jet fighter? And can you do it fast?

A young engineer named Clarence Leonard “Kelly” Johnson says yes. Not just yes - he promises to deliver a prototype in 180 days. Six months to design and build America’s first operational jet fighter, a type of aircraft that Lockheed has never attempted before, using technology that barely exists.

His bosses think he’s insane. He probably is.

Johnson hand-picks a team of twenty-three engineers and about thirty shop mechanics. He can’t find space for them in Lockheed’s main facility - the war effort has every square foot occupied. So he rents a circus tent and sets up shop next to a plastics factory. The smell from the factory is so overpowering that the team starts joking they work in the “Skonk Works” - a reference to a location in the popular comic strip Li’l Abner, where a mysterious and malodorous moonshine was brewed.

The name stuck. Lockheed later changed the spelling to “Skunk Works” to avoid trademark issues, but the spirit remained the same: a small group of brilliant misfits, working in conditions that would make any HR department have a seizure, doing things that shouldn’t be possible.

Here’s what happened next: Kelly Johnson and his team delivered the XP-80 Shooting Star in 143 days. Not 180 days. One hundred forty-three. They finished weeks ahead of an already insane schedule.

Oh, and one more detail that still blows my mind every time I think about it: the formal contract for the project didn’t arrive until October 16, 1943 - four months after work had already begun. They built America’s first jet fighter on a handshake.

Let that sink in. No contract. No formal requirements document. No detailed specifications signed in triplicate by seventeen stakeholders. Just a handshake, a circus tent, and a team of people who believed they could do something impossible.

The man who could see air

To understand Skunk Works, you have to understand Kelly Johnson. And to understand Kelly Johnson, you have to understand that some people are simply built different.

Johnson was born in 1910 in Ishpeming, Michigan - a remote mining town where winter temperatures regularly dropped to thirty below zero. His parents were Swedish immigrants. He was the seventh of nine children. By every statistical measure, he should have ended up working in the mines like everyone else in town.

Instead, he became one of the most important aeronautical engineers in history.

His boss at Lockheed, Hall Hibbard, once said of Johnson: “that damned Swede can actually see air”. It wasn’t a metaphor. Johnson had an almost supernatural ability to understand aerodynamics intuitively. He could look at an aircraft design and immediately identify problems that would take other engineers weeks of calculations to discover. He could estimate weight, performance characteristics, and structural requirements in his head while other people were still sharpening their pencils.

But Kelly Johnson wasn’t just a brilliant engineer. He was a brilliant leader who understood something fundamental about how innovation actually happens: it doesn’t come from process. It comes from people. Small groups of exceptional people, given the authority to make decisions, protected from bureaucratic interference, and trusted to deliver.

His motto was simple: “be quick, be quiet, and be on time”.

Johnson is sometimes credited as the originator of the KISS principle - Keep It Simple, Stupid. Whether or not he actually coined the phrase, he certainly lived it. He had zero patience for complexity that didn’t serve the mission, for meetings that didn’t produce decisions, for paperwork that didn’t make the aircraft fly better.

After the success of the XP-80, Skunk Works became Lockheed’s secret weapon for impossible projects. Over the following decades, they produced a string of aircraft that changed the world.

The U-2 spy plane, which could fly at 70000 feet - so high that Soviet radar couldn’t track it and Soviet missiles couldn’t reach it. The U-2 gave the United States unprecedented intelligence capabilities during the Cold War and remained in service for decades.

The SR-71 Blackbird, which could fly at Mach 3.2 - more than three times the speed of sound - at altitudes above 85000 feet. The Blackbird was so fast that its primary defense against missiles was simply to outrun them. It still holds the world speed record for a manned, air-breathing aircraft. That record was set in 1976, and no one has beaten it in fifty years.

The F-117 Nighthawk, the first operational stealth aircraft, which could penetrate enemy airspace completely undetected by radar. The F-117 flew over 1300 combat missions in the Gulf War with zero losses.

Each of these aircraft was built by small teams using the principles Kelly Johnson established in that circus tent. Each of them was considered impossible until it flew.

The 14 rules that built the impossible

Kelly Johnson eventually codified his approach into fourteen rules. He first wrote them down in 1954, and they’ve been guiding Skunk Works operations ever since. If you visit Lockheed Martin’s website today, you can still find them posted.

The original rules were written for defense contractors working with military customers. They talk about project offices and security clearances and contractor-military relationships. But underneath the specific language, there are timeless principles about how small teams can accomplish extraordinary things.

I’ve spent years studying these rules, applying them, screwing them up, and learning from my mistakes. What follows is my translation of Kelly Johnson’s wisdom into principles that work for startups, for small teams, for anyone trying to build something that the world says can’t be built.

Principle One: ruthless team size

Kelly’s original rule: “The number of people having any connection with the project must be restricted in an almost vicious manner. Use a small number of good people - 10% to 25% compared to the so-called normal systems”.

Read that again. Ten to twenty-five percent of what’s “normal”. Not a small reduction. A savage one. And notice the language: “restricted in an almost vicious manner”. Kelly Johnson didn’t mince words.

This is the principle that most people understand intellectually but fail to apply in practice. When projects get hard, the instinct is to add people. When deadlines loom, managers start talking about “scaling up the team”. When problems multiply, the solution always seems to be more bodies.

It’s almost always wrong.

Here’s what actually happens when you add people to a struggling project: communication overhead explodes. Every new person needs to be brought up to speed. Every decision now requires more meetings, more consensus-building, more documentation so that everyone knows what everyone else is doing. The work that was already hard becomes harder, not easier.

Brooks’s Law - from Fred Brooks’s classic book The Mythical Man-Month - states that adding manpower to a late software project makes it later. Brooks wrote that in 1975, and we still haven’t learned the lesson.

Kelly Johnson understood this instinctively. He knew that a small team of exceptional people will always outperform a large team of average people. Not just in speed - in quality, in innovation, in the ability to pivot when something isn’t working.

But here’s the part people miss: this only works if the small team is actually exceptional. “Small number of good people” is the full phrase. You can’t have a tiny team of mediocre performers and expect magic. The Skunk Works hired the best engineers they could find and then trusted them to operate with minimal oversight.

When I built Beyond Humanity - the hybrid board game with a companion app, IoT-specific electronics, and practical AI applications - we did it with a team that would have made traditional game publishers laugh. They would have told us we needed separate teams for hardware, software, game design, manufacturing, and marketing. Instead, we had a handful of people who wore multiple hats and talked to each other constantly.

We raised over $410K on Kickstarter. The project succeeded not despite the small team, but because of it.

Principle Two: one throat to choke

Kelly’s original rule: “The Skunk Works manager must be delegated practically complete control of his program in all aspects. He should report to a division president or higher”.

This is about decision-making speed. In a traditional organization, decisions filter up through layers of management, get debated in committees, require sign-offs from stakeholders who may not understand the technical details, and eventually emerge - weeks or months later - as watered-down compromises that satisfy no one.

In Skunk Works, Kelly Johnson made the decisions. All of them. He reported directly to senior leadership, which meant there was no middle management to slow things down. If something needed to change, it changed. If a problem needed solving, it got solved. No committees, no consensus-seeking, no death by PowerPoint.

I call this “one throat to choke” because that’s the phrase investors sometimes use, and it’s viscerally accurate. When everything depends on one person’s judgment, that person feels the weight. There’s no hiding behind process, no diffusing responsibility across a committee. You make the call, and you own the outcome.

For founders, this principle feels natural - of course you’re making the decisions, you started the company. But it gets harder as companies grow. The temptation to add layers, to distribute authority, to create structures that feel more “professional” is enormous.

Fight that temptation. The moment decisions start requiring meetings to schedule meetings, you’ve lost something precious. The speed that let you compete with bigger players, the agility that let you pivot when the market shifted - it evaporates once you start optimizing for process over outcomes.

This doesn’t mean being a dictator. Kelly Johnson listened to his engineers. He valued their input. He changed his mind when presented with better information. But he made the final call, and he made it fast.

Principle Three: trust over process

Kelly’s original rule: “there must be mutual trust between the military project organization and the contractor, the very close cooperation and liaison on a day-to-day basis. This cuts down misunderstanding and correspondence to an absolute minimum”.

This might be the most important principle of all, and it’s the one that modern business has most thoroughly forgotten.

Process exists to compensate for lack of trust. When you don’t trust someone to do their job, you create checkpoints, reviews, approvals, and documentation requirements. When you don’t trust your partners to deal with you fairly, you create contracts with dozens of clauses covering every possible contingency. When you don’t trust your team to make good decisions, you create hierarchies and committees and sign-off procedures.

All of that process has a cost. It slows everything down. It creates overhead. It demoralizes people who are competent and trustworthy by treating them like they’re not.

Kelly Johnson started the most ambitious aerospace project of his era on a handshake. No contract. Just trust between Lockheed and the military that both sides would act in good faith. That trust enabled speed that would have been impossible in a more adversarial arrangement.

When I work with investors, partners, or team members, I’m constantly asking myself: is this process necessary, or is it compensating for a lack of trust? If it’s the latter, the real question is whether to build trust or accept that this isn’t the right relationship.

Some of my best professional relationships have operated with minimal formal structure. Daily communication. Complete transparency. Willingness to have hard conversations quickly instead of letting problems fester. The documentation is minimal because the trust is high.

Some of my worst professional relationships have drowned in process. Contracts that took months to negotiate. Weekly status reports that no one read. Formal change request procedures for the smallest modifications. All of that process didn’t prevent problems - it just made them harder to solve.

Principle Four: ship and iterate

Kelly’s original rules emphasized flexibility: “a very simple drawing and drawing release system with great flexibility for making changes must be provided” and “there must be a minimum number of reports required, but important work must be recorded thoroughly”.

Notice the balance here. Flexibility and minimal bureaucracy, but important work gets recorded. This isn’t about being sloppy. It’s about not letting documentation become an end in itself.

The Skunk Works built working aircraft. Not perfect requirements documents. Not comprehensive specification packages. Working aircraft that actually flew. And when something didn’t work, they fixed it - quickly, without convening a change control board or filing a formal modification request.

In modern startup language, we’d call this shipping and iterating. Get something real in front of users as fast as possible. Learn from what actually happens, not what you predicted would happen. Make changes based on evidence, not speculation.

The waterfall model - where you specify everything upfront, then design, then build, then test, and only then discover that your assumptions were wrong - is a recipe for disaster. It’s how you spend two years building something nobody wants.

Kelly Johnson didn’t have the vocabulary of agile development, but he was practicing it decades before the Agile Manifesto was written. Small iterations. Constant testing. Flexibility to change course when you learned something new.

When we’re building Omea, we don’t wait until a feature is perfect to get it in front of users. We ship it, watch what happens, and improve. The narrative AI that powers the experience has gone through countless iterations based on how real people actually interact with it. If we’d tried to specify everything upfront, we’d still be writing requirements documents instead of building a product that works.

Principle Five: know your numbers

Kelly’s original rule: “there must be monthly cost reviews covering not only what has been spent and committed but also projected costs to the end of the program”.

This seems like basic financial management, but the emphasis on real-time cost awareness is crucial. Kelly Johnson didn’t want to find out at the end of a project that they’d blown the budget. He wanted to know at every moment exactly where they stood financially.

For startups, this translates into obsessive attention to runway, burn rate, and unit economics. Not quarterly reviews where you discover problems too late to fix them. Weekly or even daily awareness of exactly how much money you have, how fast you’re spending it, and what that means for your timeline.

I’ve seen startups die because founders avoided looking at the numbers. They knew intellectually that cash was tight, but they didn’t want to confront exactly how tight. By the time they were forced to face reality, it was too late to make meaningful changes.

The bootstrapping mindset - even when you’re funded - is a competitive advantage. Every dollar you waste is a dollar you can’t spend on something that matters. Every month of runway you burn unnecessarily is a month of optionality you’ve lost.

Kelly Johnson delivered projects under budget. Not just on budget - under budget. In an industry notorious for cost overruns, Skunk Works consistently brought projects in for less than projected. That wasn’t luck. It was discipline. It was knowing the numbers and making decisions accordingly.

Principle Six: protect the work

Kelly’s original rule: “access by outsiders to the project and its personnel must be strictly controlled by appropriate security measures”.

In the original context, this was about military secrecy. Skunk Works projects were classified because they involved technology that adversaries couldn’t be allowed to learn about.

For startups, the principle is different but equally important: protect the team’s ability to focus.

Every meeting that isn’t essential is an attack on your team’s productivity. Every stakeholder who demands status updates is consuming time that could go toward building. Every well-meaning advisor who wants to “stay in the loop” is creating communication overhead.

I’m not saying you shouldn’t have meetings or stakeholders or advisors. I’m saying you should guard your team’s attention as jealously as Kelly Johnson guarded his classified projects. The context-switching cost of constant interruptions is enormous. A developer who’s interrupted every thirty minutes might as well not be working at all.

This also means protecting the team from scope creep. From “wouldn’t it be nice if” feature requests. From the temptation to chase every opportunity instead of focusing on what matters.

One of the hardest things about building something is saying no to things that seem good but aren’t essential. Kelly Johnson could say no because he had the authority and the mandate. Founders have to develop that same ability to protect their team’s focus even when it means disappointing people.

Principle Seven: reward builders

Kelly’s original rule: “because only a few people will be used in engineering and most other areas, ways must be provided to reward good performance by pay not based on the number of personnel supervised”.

This is subtle but crucial. In traditional organizations, the way to advance is to manage more people. The path to higher pay is through bigger teams, more direct reports, larger org charts. This creates terrible incentives. People try to grow their empires even when the work doesn’t require it.

Kelly Johnson wanted to reward people for building things, not for accumulating headcount. A brilliant engineer who wanted to stay hands-on shouldn’t have to become a manager to advance their career. The individual contributor path should be just as prestigious and well-compensated as the management path.

This resonates deeply with me because I’ve never wanted to be a manager. I want to build things. The moment I’m spending more time in one-on-ones and performance reviews than in code or design or problem-solving, something has gone wrong.

At Omea, we think about this constantly. How do we create a structure where the best builders want to keep building? How do we avoid the trap where our most talented people get “promoted” into roles that take them away from what they’re best at?

The Skunk Works was full of people who could have been executives elsewhere but chose to stay in the trenches because that’s where the interesting work happened. Creating that kind of environment - where building is valued more than managing - is one of the hardest challenges for any organization.

The failure that taught me everything

I’ve been talking about these principles as if I’ve always followed them. I haven’t. And the biggest lesson of my career came from the time I ignored almost all of them.

ACR Systems - Advanced Cinema Robotics - was my Polish company. I built it starting in 2013, and I poured almost a decade of my life into it. We created innovative hardware for film and video production, camera stabilization systems and motion control equipment that ended up on movie sets around the world.

On paper, it was a success. We had products that worked. We had customers who loved them. We ran one of the most successful Polish Kickstarter campaigns of its time.

And yet I count ACR as a failure. Not because the company collapsed, but because it never achieved what it could have. Because I made mistakes that limited its potential, and those mistakes were almost all violations of Skunk Works principles.

Mistake one: wrong country. I built ACR in Poland because that’s where I was, and I told myself it didn’t matter. In the age of global commerce, you can build a hardware company anywhere, right?

Wrong. The film and video industry’s center of gravity is in Los Angeles. The investors who understand the space are there. The customers with the biggest budgets are there. The ecosystem that supports hardware startups is there. Building in Poland meant fighting against geography at every turn.

Kelly Johnson built Skunk Works in California because that’s where the aerospace industry was. Location isn’t just about logistics - it’s about being embedded in the ecosystem where your industry lives and breathes. I learned this lesson too late.

Mistake two: I didn’t build sufficient trust-based relationships. I worked hard. Insanely hard. Sixteen-hour days, seven days a week, for years. But hard work isn’t the same as working smart, and it’s definitely not the same as having the right people in your corner.

I needed advisors. I had some. I didn’t listen to them enough. When people with more experience tried to tell me things, I was often too busy executing to really hear what they were saying. The Skunk Works principle of trust and close cooperation requires actually trusting and cooperating - not just nodding along while you continue doing what you were already planning to do.

Mistake three: wrong co-founders. This one hurts to write because it’s so fundamental. The people you build with matter more than almost anything else. The wrong co-founders don’t just slow you down - they can destroy everything you’re trying to create.

I’m not going to go into specifics because that wouldn’t be fair to anyone. But I will say this: the Skunk Works principle of ruthlessly restricting who has access to the project applies to founders too. Not everyone who wants to be part of your journey should be part of your journey. Not everyone who has something to offer is the right fit for the trust-based, high-intensity, we’re-building-something-impossible environment that this kind of work requires.

I violated Principle One by not being ruthless enough about who was on the team. I violated Principle Three by building partnerships without sufficient trust. I violated Principle Two by diluting decision-making authority across people who didn’t share the same vision.

Mistake four: I underestimated the competition. When we started, Chinese manufacturers were making cheap knockoffs of Western camera equipment. The quality was poor. We could compete on quality.

Then the quality improved. The Chinese manufacturers weren’t just copying anymore - they were innovating. And once the quality gap closed, the price gap became insurmountable. We couldn’t compete with companies whose labor costs were a fraction of ours.

This isn’t a Skunk Works principle exactly, but Kelly Johnson understood something crucial: you have to build things that can’t be easily replicated. The SR-71 wasn’t just incrementally better than Soviet aircraft - it was a generational leap that took decades to approach. Building something that’s merely good isn’t enough when competitors can eventually copy it and undercut you on price.

ACR taught me that working hard isn’t enough. Being good isn’t enough. You need the right team, in the right place, building something that has defensible advantages, with trust-based relationships that help you navigate the inevitable challenges.

Every project I’ve undertaken since has been informed by those lessons. Every time I’m tempted to compromise on team composition, or to avoid having a hard conversation, or to build in a convenient location instead of the right location, I think about ACR and what it cost me to learn those lessons the hard way.

Building the impossible, over and over

After ACR, I could have played it safe. Taken a comfortable job at a big company. Built things that were guaranteed to work because thousands of people had built similar things before.

Instead, I went in the opposite direction. Each new project has been harder than the last. Not because I’m a masochist, but because life’s too short to build simple things. We’re here for a limited time. Might as well spend it attempting something meaningful.

Beyond Humanity was supposed to be impossible. A board game with a companion app, custom IoT electronics, and AI-driven gameplay. The game industry veterans we talked to said it couldn’t be done by a small team. We did it anyway, raised over $410K, and delivered a product that players love.

The lesson: Skunk Works principles work. Small team, ruthless focus, trust-based collaboration, shipping and iterating. We ignored the conventional wisdom about how games get made because conventional wisdom would have told us not to try.

Migam is attempting something even harder. Teaching AI to understand and generate sign language - not just one sign language, but multiple ones across different countries and cultures. The goal is to break down communication barriers for over 70 million Deaf people worldwide.

Working with Przemek Kuśmierek on Migam has been a masterclass in applying Skunk Works thinking to social impact. The technical challenges are immense. The resources are limited. The potential impact is transformative. It’s exactly the kind of “impossible” project that Kelly Johnson would have recognized - too important to not attempt, too hard for conventional approaches to handle.

And then there’s Omea.

Omea - formerly known as StoryWeaver - is my attempt to revolutionize interactive storytelling. We’re building an AI that doesn’t just respond to user choices but genuinely understands narrative. Not chatbot-style responses that feel like a game of Mad Libs, but actual stories that adapt and evolve based on what you do.

The technical approach was controversial. The standard way to build AI systems right now is agentic - multiple AI agents coordinating with each other, breaking down complex tasks into subtasks, creating layers of AI talking to AI. It’s the fashionable approach, and everyone’s doing it.

We went the opposite direction.

Instead of agentic architectures, we built an orchestration system based on zero-shot approaches. One model, carefully tuned, doing the work that others try to accomplish with swarms of agents. The result is something unique: better quality because we’re not accumulating errors across multiple agent interactions, better speed because we’re not waiting for agents to coordinate, better cost efficiency because we’re not running multiple models for every request.

It’s a bet against the prevailing wisdom. It might be wrong. But Kelly Johnson didn’t build the SR-71 by doing what everyone else was doing. He built it by having the courage to pursue unconventional solutions when conventional ones weren’t good enough.

Our proprietary Narrative Intelligence Architecture - what we call NIA - is based on over 155K carefully curated texts. It can maintain context across millions of tokens, which means it actually remembers what happened in your story and builds on it coherently. The voice-controlled interface lets you experience narratives without touching a screen, as naturally as having a conversation.

When people ask how a small team can compete with well-funded AI giants, I point to Skunk Works. Twenty-three engineers in a circus tent built America’s first jet fighter. A small team with the right principles, the right focus, and the right people can accomplish things that should be impossible.

The invitation

By now you’ve either decided I’m onto something or dismissed this as the ravings of someone who’s watched too many documentaries about Cold War aerospace programs. Either response is valid.

But if you’re still with me, I want to extend an invitation.

The Skunk Works methodology isn’t about aerospace. It’s not about defense contracting or classified projects or billion-dollar budgets. It’s about a set of beliefs regarding how exceptional work gets done. Small teams. Trusted relationships. Ruthless focus. Speed over perfection. Shipping things that work rather than documenting things that don’t exist yet.

These principles are available to anyone. You don’t need permission to apply them. You don’t need a certificate or a consultant or a three-day workshop. You just need to make different choices.

What would you build if you stopped waiting for the team to get bigger? Kelly Johnson built the XP-80 with twenty-three engineers. What could you accomplish with the people you have right now, if you stopped assuming you need more?

What would you decide if you stopped convening committees? The Skunk Works manager had complete authority. What decisions are you postponing because you’re waiting for consensus that will never come?

What would you ship if you stopped polishing? The Skunk Works delivered prototypes that flew, not requirements documents that satisfied reviewers. What could you get in front of users this week if you stopped waiting for everything to be perfect?

What would you attempt if you believed it was possible? The U-2, the SR-71, the F-117 - all impossible until they weren’t. What’s the project you’ve been dismissing as too hard, too ambitious, too crazy?

The world doesn’t need more safe bets. It doesn’t need more incremental improvements. It doesn’t need more startups that are slightly better versions of things that already exist.

The world needs Skunk Works thinking. People willing to attempt the impossible, equipped with principles that make the impossible achievable, and stubborn enough to keep going when conventional wisdom says to stop.

That’s what I’m trying to do with everything I build. That’s what I hope to help you do with everything I write here.

Be quick. Be quiet. Be on time.

And never, ever let anyone tell you that the thing you’re trying to build can’t be done.

Less talking, more building. See you next week.

Max

PS. Some acknowledgments are essential.

Everything I understand about the Skunk Works methodology comes first from Kelly Johnson himself - both his documented rules and his autobiography “More than my share of it all”. If you want to go deeper, Ben Rich’s “Skunk Works: a personal memoir of my years at Lockheed” is the definitive account of what it was like to work there. Rich was Johnson’s successor and writes with the perspective of someone who lived the principles I’ve described.

Kelly's autobiography

Ben Rich's personal memoir

But principles only matter if you apply them, and I’ve been fortunate to work alongside people who embody Skunk Works thinking even if they’ve never heard the term.

Michał Pena has been my partner in crazy IT experiments for years. He’s now CTO at Omea, and there’s no one I trust more to translate impossible ideas into working systems. The trust-based collaboration that Kelly Johnson described - Michal and I have that. It makes everything possible.

Artur Kurasinski and Przemek Kuśmierek believed in my crazy ideas when believing in them was an act of faith. Przemek’s partnership on Migam has shown me what it looks like when two people are fully aligned on an impossible mission. Artur saw potential in StoryWeaver (former Omea) before it was anything more than a wild vision.

Tomasz Kolinko shares my approach to technology - extreme optimism and enthusiasm, grounded in hard work. Talking with Tomasz reminds me why I got into this field in the first place. The future is worth building, even when building it is hard.

And Justine. My wife. My biggest supporter and fan. She’s listened to me rant about Kelly Johnson and the SR-71 more times than any human should have to endure. She’s supported the late nights and the setbacks and the moments when the impossible felt truly impossible. None of this happens without her.

PS2. If you’re wondering what’s next - week 3 will be about the Hero’s Journey. Not the startup journey, though that’s part of it. The actual Hero’s Journey, the storytelling structure that’s been embedded in human culture for thousands of years, carved into our brains as a pattern we recognize instinctively. It’s the foundation of everything we’re building at Omea, and it’s the secret weapon for any founder who needs to make people care about their vision.

It’s also, I’ll warn you now, going to be long. The beast is becoming a pattern. Deal with it.

If you’ve been following me on LinkedIn for the past few years, you’ve witnessed something that was never supposed to happen. You’ve watched a robotics engineer turned AI builder turn your professional networking feed into his personal diary. Raw fundraising updates at midnight. Impostor syndrome confessions after rubbing shoulders with Silicon Valley legends. Victory posts written at 3 AM after finally squashing a bug that had been haunting me for weeks. The whole messy, unfiltered journey of trying to build impossible things.

LinkedIn was never designed for this. I know that. You know that. The algorithm definitely knows that, and it’s been punishing me for it with increasingly creative ways to hide my posts from the people who actually want to read them.

But here’s my confession: I kept doing it because I was too lazy to set up a proper blog.

There. I said it.

Every time someone suggested I start a newsletter, I’d nod thoughtfully and say something like “yeah, I’ve been thinking about that” while internally calculating how many mass produced coffee cups it would take to fuel the effort of setting up Yet Another Platform. The answer was always “too many”, so I’d go back to LinkedIn and write another 3000-character post about whatever was keeping me up at night.

And honestly? For a while, it worked beautifully.

The community I found on LinkedIn has been nothing short of incredible. Through those messy, too-long posts, I’ve connected with investors who actually get what we’re building. I’ve found collaborators who’ve become friends. I’ve met fellow founders who message me at weird hours because they know I’ll be awake, probably debugging something, definitely willing to talk through whatever crisis they’re facing. I’ve received DMs that made me tear up - people telling me that my raw posts about impostor syndrome helped them feel less alone in their own struggles.

I’m grateful for every single comment, every DM, every “holy shit, I needed to read this today”. Those interactions have meant more to me than I’ve probably ever properly expressed.

But here’s the kicker, and it’s taken me too long to admit this: some stories simply don’t fit in a LinkedIn post.

Let me tell you about the moment I realized this.

A few months ago, I was trying to write about the Skunk Works methodology - this philosophy that’s basically become my entire approach to building companies. For those who don’t know, Skunk Works was Lockheed’s legendary secret R&D division. These were the crazy bastards who created the U-2, the SR-71 Blackbird, the F-117 stealth plane. They did impossible things with tiny teams, ridiculous timelines, and bureaucracy-allergic management. They changed aerospace forever by basically telling conventional wisdom to go fuck itself.

I’ve been living and breathing this methodology for years. It’s how we built Beyond Humanity, the board game that shouldn’t have worked. It’s how we’re building Omea, the AI storytelling platform that everyone said was impossible. It’s how Migam is teaching machines sign language to help 70 million Deaf people communicate with the hearing world.

So I sat down to write about it for LinkedIn. I had so much to say - the history, the principles, how I’ve adapted them for AI startups, the failures that taught me the real lessons, the wins that validated the approach. I started typing.

Three hours later, I had 8000 words and I wasn’t even close to done.

LinkedIn’s limit is around 3000 characters. Not words. Characters.

I tried to cut it down. I really did. But every time I removed something, it felt like I was lying by omission. The Skunk Works philosophy isn’t a list. It’s not “10 tips for building like Lockheed secret team”. It’s a way of thinking, a set of hard-won principles that only make sense when you understand the context, the failures, the stories behind them.

So I gave up. I posted something shorter, something that felt incomplete. And I told myself I’d figure out a better way to share the full version… eventually.

That “eventually” kept getting pushed back. Because building companies is consuming. Because there’s always another fire to put out, another investor call to prepare for, another bug that’s somehow breaking production at the worst possible moment. Because writing properly, writing deeply, writing in a way that does justice to the ideas bouncing around my skull - that requires time and energy that felt like luxuries I couldn’t afford.

But something shifted recently.

Maybe it’s the approaching new year making me reflective. Maybe it’s the fact that I’ve been on this journey long enough now to have actually learned some things worth sharing. Maybe it’s watching founders I respect - people like Grzesiek Kossakowski, whose writing is so consistently excellent that it makes me genuinely jealous - building audiences through long-form content that actually has room to breathe.

Or maybe it’s simpler than that. Maybe it’s just Karol Stryja, who keeps pushing me to write more, to be more accessible, to share what I’ve learned with people who are earlier in their journeys. Every conversation with him ends the same way: “Max, you have things to say. Stop hiding them in LinkedIn posts that disappear after 48 hours.”

He’s annoyingly right. He usually is.

So here we are. New year, new home base.

And yes, I’m fully aware that “New Years resolution to write more” is practically a cliche. I know the statistics. Most resolutions fail by February. The road to abandoned blogs is paved with good intentions and optimistic first posts.

But this one feels different, and I’ll tell you why: this isn’t really a resolution. It’s a promise to myself.

I need a place to think out loud. I need somewhere to process the absolute chaos of building multiple companies across two continents. I need to document this journey while it’s happening, before the details blur and the lessons get lost in the fog of whatever crisis comes next.

Omea is teaching AI to tell stories that actually respond to human choices. Migam is breaking communication barriers for Deaf people worldwide. QUIN-C, my personal robot project, is still sitting on my workbench reminding me that weekends are for tinkering. I’m navigating fundraising, building teams across the Atlantic, figuring out the O-1 visa maze, and somehow trying to maintain sanity through it all.

That’s a lot of material. That’s a lot of stories that deserve more than 3000 characters.

So what is this place going to be?

First and foremost, it’s my diary. A place to write my thoughts and share them with whoever cares to read. If that sounds self-indulgent, well, yeah, it kind of is. But I’ve learned that the most valuable content often comes from people processing their own experiences honestly, not from people trying to package wisdom they don’t actually have.

I’m going to unpack the Skunk Works philosophy properly. Not the elevator pitch version, but the real version - with all the historical context, the principles that actually matter, the ways I’ve adapted them for AI startups, and the painful lessons about what happens when you deviate from them.

I’m going to take you behind the scenes of building Omea. The technical decisions, the narrative architecture we’ve developed, the AI models we’re training. But also the human side - the fundraising struggles, the moments of doubt, the victories that feel surreal because part of me still can’t believe we’re actually pulling this off.

I’ll share what I’m learning as an advisor at Migam, working alongside Przemek Kuśmierek on technology that could genuinely change millions of lives. The intersection of AI and accessibility is fascinating and underexplored, and I have thoughts.

And I’m going to write playbooks. Real, practical, hard-won knowledge about things I’ve actually done. The tools I use every day - from my Mac and iPad setup to Claude Code and how it’s changed how I work. Building teams when you’re straddling the Atlantic. Fundraising when you’re not from Silicon Valley. How to tell stories that make people care about what you’re building.

Here’s what this place will NOT be:

It won’t be polished corporate content. I don’t have a content team. I don’t have an editor. It’s just me, probably writing at some ungodly hour, trying to capture whatever’s on my mind before I forget it. There will be typos. There will be tangents. There will be posts that probably should have been shorter but weren’t because I got excited and couldn’t stop.

It won’t be monetized. I’m not doing this for money. I don’t need your credit card number. I need a place to process my thoughts, and if those thoughts happen to be useful to you, that’s a bonus. Subscribe for free. That’s the whole deal.

And it won’t be a pivot away from building. I’ve always believed in “less talking, more building”. That philosophy isn’t changing. Writing is thinking, and thinking is part of building. But the building always comes first. If I ever have to choose between shipping a feature and writing a newsletter post, the newsletter loses. Every time.

The commitment I’m making to myself is simple: one post per week.

That’s it. Every week, something new here. Some weeks it’ll be a deep dive into technical architecture. Some weeks it’ll be a raw diary entry about whatever challenge I’m facing. Some weeks it might be shorter, some weeks it might be the 8000-word Skunk Works piece I couldn’t fit on LinkedIn.

One post per week. That’s the promise.

I’m not abandoning LinkedIn entirely. I’ll still post there - probably teasing what’s happening here, probably still writing shorter updates when something exciting happens. But Skunk Works Playbook is home base now. This is where the real stuff lives.

Next week, I’m finally going to publish the piece I’ve been wanting to write for years: the Skunk Works Manifesto. What this philosophy actually means, where it comes from, why it’s the only way I know how to build anything worth building. If you’ve ever wondered what the hell I’m talking about when I reference Skunk Works, that post will explain everything.

Buckle up. It’s going to be a ride.

And if you’ve made it this far - thank you. Seriously. The fact that you care enough to read my rambling thoughts means more than I can properly express.

Subscribe if you want to come along for the journey. Or don’t. Either way, I’ll be here, writing into the void, trying to make sense of the beautiful chaos of building impossible things.

Less talking, more building. But also, apparently, a bit more writing.

Max

PS. Some thank-yous are in order, because I didn’t get here alone.

To Przemek Kuśmierek - my partner in crime at Migam, who’s been on this journey with me longer than almost anyone. You’ve watched me ramble on LinkedIn for years and somehow still believe in my ability to form coherent thoughts. Your faith in me has always exceeded my faith in myself, and I’m trying to live up to it.

To Grzesiek Kossakowski - whose publications are always so damn well-written that I’m genuinely jealous. Every time I read something you’ve written, I think “why can’t I write like that?” and then I remember that the only way to get better is to actually write. So this is partly your fault. Your excellence pushed me to finally try.

To Karol Stryja - who never stops pushing me to write more, to be more accessible, to share what I know instead of hoarding it. You’ve told me a hundred times that people want to hear what I have to say. I never fully believed you, but I’m done making excuses. This one’s for you. If it fails, I’m blaming you. If it succeeds, I’ll probably also find a way to blame you. That’s what friends are for.

And to all the kind-hearted people who’ve been rooting for me through this journey - the ones who comment on my posts, who send encouraging DMs, who show up to my talks, who somehow believe in the crazy things I’m trying to build. You know who you are. I don’t know what I did to deserve your support, but I promise I’ll try not to waste it.

PS2. Yeah, I’m already doing the double PS. thing. Some habits from LinkedIn are going to be hard to break. Deal with it.