How I Learned to Build

Where It Started

I was seven or eight years old, watching my older brother play Warcraft III on the family computer. He was deep into the custom games scene - player-made maps that turned the strategy game into something else entirely. Tower defenses, RPGs, survival games. I wanted in.

The game I got hooked on was called Sheep Tag. The premise was simple: most players were sheep trying to hide, and a few players were wolves trying to catch them. But there was one player slot - Teal - that was different. Teal could fly. While everyone else was running around the maze trying to survive, Teal floated above it all, untouchable.

I wanted to be Teal every single time.

The problem was that player slots were assigned by join order. Whoever got into the game lobby first claimed the best color. And I was slow. By the time I found a game and clicked join, someone else had already taken Teal. Every time. The frustration was unbearable in that particular way that only matters when you’re eight years old and something feels cosmically unfair.

So I had an idea: what if I hosted the game myself? If I created the lobby, I’d be first in. I’d be Teal by default.

I clicked the button to host a game. Set up the map. Waited for players to join. Nobody came. I tried again. Nothing. Some error message about ports that meant nothing to me. I didn’t know what a port was. I didn’t know what forwarding meant. But I knew that something was blocking people from joining my game, and I knew that I was going to fix it.

What followed was hours of searching - the kind of obsessive, single-minded focus that I’d later learn had a name. I found forum posts about something called port forwarding. I learned that my router was blocking incoming connections, and that I needed to tell it to let certain traffic through. The problem was that every router brand had a different interface. Netgear looked different from Linksys looked different from whatever off-brand thing my parents had bought. I had to find instructions specific to our router, figure out how to log into its admin panel, and navigate menus that weren’t designed for eight-year-olds.

Eventually, I got it working. Players could join my games. I was Teal.

That experience planted something. Not the technical knowledge itself - I’d forget the specifics of port forwarding within weeks - but the pattern. Want something. Hit a wall. Refuse to accept the wall. Learn whatever is necessary to get past it. That loop has run continuously for twenty years.

After Warcraft III, I moved through a succession of games: Counter-Strike Source, Garry’s Mod, World of Warcraft, Minecraft. Each one followed the same progression. I’d start as a player, get frustrated with the limitations of playing on other people’s servers, and decide to run my own. Running my own meant learning whatever that particular game required - different server software, different configuration files, different communities with different expectations.

Garry’s Mod was where things got interesting. The game was essentially a physics sandbox built on top of the Source engine, and its server ecosystem ran on Lua plugins that could transform it into almost anything. I didn’t want to just host a vanilla server; I wanted to build custom game modes. So I learned to read Lua code - not write it from scratch, but understand it well enough to modify existing plugins. I’d find a plugin that did something close to what I wanted, trace through its logic, figure out which variables controlled which behaviors, and tweak it until it matched my vision. I built custom RPG modes this way, stitching together pieces from different sources and filling in the gaps.

The key realization from that period was that building things didn’t require writing code from scratch. It required understanding how pieces fit together. Most of the interesting work was integration - making system A talk to system B in a way that created something neither could do alone.

By the time I was twelve, I had a problem: my game servers were getting popular enough that I needed better hosting, and better hosting cost money. My parents weren’t going to pay for dedicated servers so I could run a Minecraft community (they didn’t know my PC was running 24/7). If I wanted to keep going, I needed to figure out how to fund it myself.

So I learned to build websites. Basic HTML and CSS at first, enough to put together landing pages for my servers. Then I learned how DNS worked - nameservers, A records, CNAMEs, the whole system that translates human-readable addresses into IP addresses. I needed to understand this because I was pointing custom domains at my servers, and when things broke, I needed to debug why.

Then came the integration that felt like real magic: connecting the website to the games. I figured out how to wire PayPal’s payment system to a database, and wire that database to the game servers. When someone donated money through the website, they’d automatically receive benefits in-game - a colored name, a better plot of land in Minecraft, some amount of in-game currency. No manual intervention. The money came in, the database updated, the game server checked the database, and the player got their reward.

I was twelve years old, and I’d built a functioning e-commerce integration without really understanding that’s what it was called.

The community kept growing. My home computer couldn’t handle the traffic anymore - too many players connecting, too much lag, too many crashes. I researched VPS hosting and learned about latency optimization. If I wanted players from both Europe and the US to have decent ping, I needed to host on the US East Coast. I found providers, compared prices, figured out how to deploy my server software on a remote machine I could only access through a command line.

By fourteen, I was running a multi-game community with a staff of volunteer moderators I’d recruited from Minecraft forums. I was handling scheduling across time zones, managing interpersonal conflicts, running what amounted to marketing campaigns to attract new players. I had no framework for any of this - no management training, no business education. I just did what seemed necessary to keep the thing I’d built from falling apart.

Around this time, I also stumbled into content creation. I started a YouTube channel, mostly tutorials and gameplay videos related to the games I was playing. Nothing sophisticated, but consistent enough that it eventually accumulated 2.5 million views. That taught me something different: the gap between making something and getting people to care about it. Technical skill alone wasn’t enough. You had to understand what people wanted, how to present it, how to show up repeatedly until an audience formed.

When I was sixteen, one of my brother’s friends was doing contract work for a Danish cloud hosting company called Meebox. They needed someone for technical support and website migrations, but they couldn’t afford to pay full adult wages. My brother’s friend knew about my gaming servers, the integrations I’d built, the technical troubleshooting I’d done. He suggested they talk to me.

They gave me a practical test: migrate a WordPress website from one server to another. I’d done exactly this, dozens of times, for my own projects. Files, databases, DNS updates, testing, verification. I passed. They made me an offer. I accepted.

I worked there for four years, starting as part-time support while I was still in high school. The skills transferred directly - the same debugging instincts, the same integration thinking, the same willingness to figure out unfamiliar systems. By eighteen, I’d been promoted to Support Engineer. By nineteen, I was the Account Manager, handling seventy to eighty percent of the company’s new business. I was twenty years old, managing relationships with four hundred customers, and I’d built a VPS product line that - as far as I know - is still generating revenue today.

During those years, the company got acquired. I led the customer migration, which meant months of careful communication, technical coordination, and relationship management while everything around us was in flux. Revenue grew four hundred percent through the transition. That taught me something about chaos: it’s uncomfortable, but it’s also when the interesting opportunities appear. When systems are stable, roles are defined and territories are fixed. When everything’s in motion, you can step into gaps that wouldn’t otherwise exist.

Here’s the part of the story where I have to be honest about something that shaped my path more than any single project or job: I never properly learned to code.

I understood the technical landscape. I could read server logs and trace errors. I could navigate configuration files and understand what different settings controlled. I could look at code and follow its logic. But sitting down and learning to program from scratch - working through tutorials, building toy projects, grinding through the fundamentals - that never happened.

It wasn’t for lack of trying. I’d start courses, get partway through, and abandon them. The problem was sustained attention. Programming education, at least as it was structured in most courses and books, required long stretches of focus on abstract problems with delayed payoffs. Write this function. It doesn’t do anything useful yet, but trust that it’s building toward something. Now write another one. Keep going.

The way around, for me, was business. Instead of learning to write code, I learned to manage systems that were already built. Sales, account management, operations, customer experience. I could architect technology stacks - decide which tools to use, how to connect them, how to configure them for specific purposes - without writing production code myself. The value I added was integration and orchestration, not implementation.

In 2020, I joined a Norwegian startup called Ledidi as employee number five. They were building a clinical research data management platform - collaborative workspaces for research teams with compliance features suitable for academic researchers and pharmaceutical sponsors. When I arrived, they had a product in development but nothing commercial. No pricing, no billing system, no customer support, no marketing infrastructure, no legal documentation. My job became building all of it.

Over the next three years, I constructed an eight-system technology stack: HubSpot for CRM and marketing automation, Chargebee for subscription management, Stripe for payments, Segment as a customer data platform to route events between systems, Amplitude for product analytics, Freshdesk for support ticketing, plus web analytics tools. Each piece connected to the others through Segment, creating a commercial infrastructure that could track a user from first website visit through trial signup through conversion through ongoing engagement.

I designed the product-led growth strategy - freemium tier to reduce friction, upgrade triggers based on usage, viral mechanics so every user could invite teammates. I built the customer success function, hired support staff, created tiered SLAs. I documented terms of service, privacy policies, data processing agreements. When enterprise customers needed security certifications, I contributed to the ISO 27001 process.

By the time I left, we had over a thousand users across twenty to thirty enterprise customers. Retention was one hundred percent - no customer who started paying ever stopped. Revenue grew through expansion: existing customers adding users and upgrading plans. I’d taken something from zero to one without writing a single line of production code.

Then ChatGPT came out, and everything changed.

For the first time in my life, I looked at the coding barrier and thought it might not be a barrier anymore. The problem had never been that I couldn’t understand code - I could read it, trace it, debug it, understand what it was doing. The problem was the sustained attention required to produce it. Grinding through syntax, remembering function signatures, building up fluency through repetition. All the things that clashed with how my brain worked.

But now there was a collaborator that could handle that part. I could describe what I wanted to build, and it would write code. I could iterate in conversation, seeing results immediately instead of working through exercises with delayed feedback. The hyperfocus that had always driven my learning now had a faster loop. Want something, describe it, see it work, refine it, repeat.

Each new model release expanded what was possible. I started building things I’d only been able to configure before - custom tools, data pipelines, integrations that didn’t exist as off-the-shelf products. The twenty-year pattern finally had access to a new medium.

After Ledidi, I joined BASE Life Science as a consultant, working with pharmaceutical clients on data migrations and AI implementations. The projects were larger and more regulated than anything I’d done before. I led a clinical document migration at a major mRNA vaccine manufacturer, where the most valuable outcome was recognizing that the data quality was too poor to migrate safely and recommending we stop. I architected a multi-agent AI system for FDA document review at a US-based biotech - six specialized agents analyzing regulatory submissions in parallel, deployed on Google Cloud Platform, with a client-validated business case projecting millions in savings in regulatory submission years. I built AI translation pipelines at two Nordic pharmaceutical companies, working with thirty thousand sentence pairs of pharmaceutical terminology.

Then a stint at IntelliShore, hired to scale their AI and automation practice. A €400K data governance transformation with twenty-five-plus stakeholders across a Nordic pharmaceutical company. More proof that the interesting work sits at the intersection of technical capability and business complexity.

Now I’m independent, building AI systems for companies that need production infrastructure rather than demonstrations. The work feels like a continuation of everything that came before - the same pattern, better tools. Find something that isn’t working the way it should. Figure out how to make it work. Learn whatever’s needed along the way.

Twenty years after I first wanted to be Teal, I’m still doing the same thing. The games changed, the stakes increased, the technology evolved. But the core loop stayed constant: frustration with limitations, focus on solving them, willingness to learn whatever the solution requires. The kid who couldn’t stand being second into the lobby is still trying to find ways around the things that are supposed to stop him.