The Dorm Room
It was 2022. I was studying Business Administration at the University of Amsterdam, still carrying the residue of COVID — half my lectures were online, the campus felt half-empty, and my dorm had become this strange little world where I spent most of my time. There was a lot of free time. Too much, maybe.
Then ChatGPT dropped.
I'd always wanted to build things — apps, products, something real — but I couldn't code. Not even close. I was a business student. The gap between having an idea and making it exist felt impossibly wide. But this new AI thing? It felt like a crack in the wall.
The Tutor That Couldn't Remember
I turned ChatGPT into my personal tutor. The plan was simple: learn Swift, build an iOS app, figure it out as I go. Trial and error. I'd describe what I wanted, it would spit out code, I'd paste it into Xcode, and — it would break. Every single time.
The problem was fundamental. Back then, the context window was tiny. You couldn't feed it your whole project. You'd describe a feature, get a chunk of code back, but it had no idea what the rest of your app looked like. So you'd end up with these Frankenstein codebases — stitched together from dozens of disconnected conversations, each fragment unaware of the others.
And the code quality was rough. Not just "needs polish" rough — genuinely broken. Missing imports, wrong types, deprecated APIs, logic that contradicted what you'd built three prompts ago. Every output came with a trail of errors.
A Blessing in Disguise
Here's the thing nobody talks about: the errors were the education.
Because the AI kept breaking things, I had to actually understand what was going wrong.
I'd stare at error messages, trace through the code, look up what a @StateObject
was versus a @ObservedObject, figure out why a view wasn't updating. I wasn't
just copying and pasting — I was debugging. And debugging is how you actually learn to code.
Looking back, I'm genuinely grateful the models were bad. If I'd started building today, I'd probably never understand a codebase. I'd never learn to think about security, architecture, or why things break. The broken outputs forced me to develop real intuition for software — and that intuition is what separates someone who builds from someone who just prompts.
Today's vibe coders drop a prompt into Cursor or Claude, get a working output, ship it, move on. They never look at the code. They don't have to — the models are good enough now. But in 2022, you had no choice. The output was broken enough that you had to get your hands dirty. And that forced understanding? That's what made me a builder.
Building for Friends
Once I understood Swift, I couldn't stop. I built four apps — all of them scratching itches that me and my friends actually had. Small tools that made our lives a little easier.
The best one was a tennis app. If you've ever tried to book a tennis court in Amsterdam, you know the pain: every club has its own website, its own booking system, its own interface. You'd have to open six different sites, check availability on each, compare time slots manually. It was absurd.
So I built a single app that pulled in the APIs from every tennis club in Amsterdam. One view. All courts. All time slots. You could see what's available across the entire city in seconds. My friends loved it. It saved us hours every week. That feeling — building something that people around you actually use and appreciate — that's when I knew this was more than a hobby.
From Months to a Week
As the AI tools improved — better models, bigger context windows, fewer hallucinations — I started building a personal framework. A way of working with AI that was systematic rather than ad hoc. Instead of treating every app as a brand-new struggle, I'd developed patterns, templates, mental models for how to structure prompts and stitch outputs together.
What used to take months now took about a week. An entire app, from idea to working product, in seven days. At the time, that felt groundbreaking. Today it barely raises an eyebrow — but back then, nobody was shipping at that speed without a team of engineers.
And that's when the idea started forming: what if this wasn't just my personal superpower? What if this could be a business?
The Agency Thesis
The logic was simple. If I could build apps in a week that used to take months, and if the tools were only going to get better, then we had an unfair advantage. The plan: start as an agency. Take on client work. Generate revenue immediately. And if we ever found our own product idea worth pursuing, we'd already be the best builders to execute on it.
I pitched this to two investors. They got it. They saw the same thing I did — that the gap between "idea" and "product" was collapsing, and whoever figured out how to ride that wave first would win.
That's how Skylark was born. February 2025. One investor gave me real freedom and a chunk of capital. From there, I needed to find someone who could complement what I brought to the table.
Finding Filippo
By this point, I could build products. But building and shipping are different things. I knew enough to be dangerous — but not enough to be confident that every security parameter was locked down, that the architecture would scale, that the production deployment wouldn't fall over at 2am. I was self-aware about this gap.
That's why I brought on Filippo as CTO. He had the engineering depth I lacked — the kind of experience you can't prompt your way into. From day one, he's been a constant. The technical foundation that lets me move fast without breaking things that matter.
The Pivot
The agency worked. Clients were happy. We delivered. But pretty quickly, we realized something uncomfortable: we were underselling ourselves. The quality we shipped as a two-person team matched what agencies with ten engineers produced. We weren't in the services game — we had a product thesis waiting to break out.
First, we built tools for people like us — other agencies. A meeting bot integration that could sit in a client call and start generating an MVP during the meeting itself. The client describes what they want, and by the time the call ends, there's already a working prototype. It was cool. But the market was too small.
So we pivoted again. Bigger. What if it wasn't just agencies? What if anyone could build software by just talking?
marnix.ai
That's where marnix.ai comes in. A conversational software agent. You talk to it like you'd talk to a technical co-founder. You describe what you want to build, and it builds it — not by generating a wall of code and hoping for the best, but by having an actual conversation. It listens. It asks clarifying questions. It guides the direction toward the best possible output.
The premise is simple but radical: the requirement to know how to code in order to build a product is going to disappear. Not in ten years. Soon. And when it does, the bottleneck won't be technical skill — it'll be the ability to clearly articulate what you want. To think through a product. To have taste.
marnix.ai is built for that future. A world where the builder isn't defined by the language they write in, but by the clarity of their vision and the quality of the conversation they have with their tools.
We went from a business student who couldn't code, to an agency, to a platform that lets anyone build software by talking. The whole journey took about three years. And honestly? We're just getting started.
The First-Time Founder Tax
I didn't grow up dreaming of being a startup founder. I went to the Gymnasium in Amsterdam — the kind of school where everyone was expected to become a doctor, a lawyer, or go into finance. My friends went to the best universities. Entrepreneurship wasn't just uncommon in my circles — it was, honestly, a bit looked down on. It wasn't the "serious" path.
So when I fell into it, it wasn't part of some grand plan. I had an idea I genuinely believed would make a difference, and I was so passionate about it that working on it 24/7 actually gave me energy instead of draining it. That's how I knew it was real.
But being a first-time founder means paying a tax on everything. Communication with employees — I got that wrong early on. Communication with clients — could've been sharper. Money management — definitely learned that the hard way. All the things that experienced founders do efficiently, I had to learn by doing them badly first.
The thing is, that tax is also the education. Working with different personalities — clients who want conflicting things, employees who need different styles of leadership, investors who need different kinds of updates. You learn to read people, to adapt, to take responsibility when things go sideways. None of that comes from a textbook. It all happens on the fly, in real time, with real stakes. And that's what makes it fascinating.
Don't Stop Building
There's one thing I'd change if I could go back.
From 2022 onward, building gave me everything — learning, energy, momentum. I loved it. It made me more technical, more capable, more confident. But the moment I stepped into the CEO role, I let myself off the hook. I told myself I didn't have time to code anymore. Too many meetings. Too many decisions. Too much strategy.
That was a mistake. You can always make time. The most successful founders I've seen still find ways to get their hands dirty — to ship a small feature, to review a pull request, to stay close to the product. When I recently started building again alongside the CEO work, everything got better. I felt more refreshed, more focused, more connected to why I started this in the first place.
So if you're a founder who started out as a builder — someone who got into this because you loved making things — don't stop. Don't talk yourself out of it. Don't let the title or the responsibilities convince you that building is someone else's job now. It's probably the thing that inspired you to start the company in the first place.
Always keep building.
