Every job I had in my twenties ended the same way. I'd get hired, dive too deep into the stack, start pushing for "better ways" to do things, and within a year or two the friction would be obvious to everyone in the room. I wasn't lazy. I was the opposite. I cared about architecture, tooling, and polish in a way that rarely matched what the company actually needed on a Tuesday afternoon.
So in 2011, I stopped waiting to be fired and started Bee Interactive instead.
Fifteen years later, the studio is still here, in Yverdon-les-Bains, still Laravel-first, still small. Which is either stubbornness or a sign it was the right call. Probably both.
Finding the right pain
The thing that made it work wasn't a business plan. It was an obsession.
In the Swiss SME market, there's an entrenched way to build web projects: heavy agencies, bloated CMSes, JavaScript frontends stacked on JavaScript frontends, SPAs where a server-rendered page would do the job in a tenth of the time. I'd watched teams — including my own, at moments — drown in their own stack.
Meanwhile, something quieter was happening in the Laravel world. Livewire. HTML over the wire. The backend as the source of truth, with just enough JavaScript to feel modern. You could take a developer who didn't know React and still ship a real, interactive app.
That clicked. It shaped the client work, it shaped Lochness (our in-house CMS), and it pulled me into open source — maintaining livewire-filemanager, publishing the TipTap extension on npm, planning a Filament plugin. None of it started as strategy. It started as this pain is annoying me, let me fix it for myself.
What actually pays the bills
There's a lie a lot of developers quietly believe: if enough people use your open-source project, money will appear. It doesn't. You can ship a package with thousands of installs and be exactly as broke as you were the week before.
What works, at least for me, isn't any single line item. It's a stack of things built around one ecosystem:
Bee Interactive is the steady heartbeat — custom Laravel work for SMEs, associations, and luxury brands. On top of that, products: Popcorn on the stores, Alpage for macOS devs, Splitty, Stamps. Underneath it, open-source packages that outlive any single project. Around all of it, a presence in the community — talks, meetups, tinkering in public.
Each piece is modest on its own. Together they compound. A talk leads to a client. A client project surfaces a missing package. The package earns credibility. Credibility brings better clients. The loop tightens.
The constraint I try to hold: the open-source work has to be genuinely useful on its own terms. Not a funnel, not crippled, not a loss leader. If someone uses one of my packages for years and never pays a centime, that's the deal I signed when I published it. The reputation it builds shows up later, in ways I couldn't have planned.
The first hire nobody warns you about
For fourteen years, Bee Interactive was effectively me. That's a comfortable place to stay, and a lot of independent developers never leave it — for good reasons. You keep all the margin. You answer to no one. You ship at your own pace.
Last year I hired Gregory, a UX/UI designer, at 60%. And here's the part nobody warns you about: the first hire isn't a scaling decision. It's an identity decision.
When you're solo, every weakness in your work is a weakness you can feel — the design instinct you don't quite have, the detail you'd have caught if you had another pair of eyes, the project you said no to because it didn't match your strengths. You absorb all of it privately. The numbers work because you're the one eating the cost.
The moment someone else shows up at the studio, that math breaks. You can't hire a designer "to help out occasionally" — you hire them, and then you have to actually become the kind of studio that sells design work, scopes it, prices it, and defends it to clients. The hire isn't the end of a process. It's the start of one. You're not adding a resource to an existing business; you're being forced to rebuild the business around what the new person makes possible.
That's the counterintuitive part. I spent years thinking the question was "can I afford someone?" The real question was "am I willing to become a different kind of studio?" Those aren't the same question, and the second one is the one that actually keeps people solo forever.
What I'd tell the version of me who was about to quit his last job
You don't need a grand plan. You need one thing that annoys you enough to fix it, and the patience to keep shipping the fix in public while the rest of your life gets built around it.
Pick an ecosystem and stay long enough to see the pain clearly — not as an outsider with hot takes, but as someone bleeding on the same rocks as everyone else. Build the smallest useful thing. Ship it where people can find it. Keep the client work honest; it isn't a side project you tolerate so you can do "real" creative work — it's the thing that funds the experiments, and the experiments are what make the client work better over time.
And when the time comes to hire someone, don't frame it as a cost. Frame it as a commitment to become something you currently aren't.
There's luck in all of this, of course. I got into Laravel early enough that there was still territory to stake out. I live in a country where a well-run studio can actually pay its people properly. But from the inside, it doesn't feel like luck. It feels like fifteen years of small bets: try this idea, open-source that package, give the talk, hire the designer, build the native macOS app just to see if you can.
I'm not "just a developer" anymore, and I haven't been for a long time. I run a small studio, I ship things, I teach by building in public, and I try to be a useful presence in a community I care about. The code is central but it isn't the whole job.
Fifteen years in, I'm still pulling threads. That's the whole trick.