Lead Engineer by Day, Indie Developer by Night

There are two versions of me working every day.

The first is the Lead Software Engineer at Elemental Machines. Works on IoT systems, coordinates technical decisions on a team, has code reviews and meetings and shifting priorities. Thinks in terms of reliability, scalability, and impact on a product that isn't his.

The second is Daniele Molinari of Honeyside. Builds his own products, makes every decision alone, has no reviews from anyone, and answers for the consequences directly. Thinks in terms of shipping, iterating, and surviving.

They're not the same person. And it's not always easy to switch between them.

What You Learn in Each Direction

The full-time job teaches me things I would never learn on my own.

Working on a team with engineers more senior than me — who exist, despite the title — exposes me to ways of thinking I wouldn't have developed working alone. How to manage complexity at scale, when to refactor and when not to, how to communicate a technical tradeoff to non-technical stakeholders. These skills don't come from building products alone in a metaphorical garage.

The scale of the product I work on at Elemental Machines — real users, physical hardware, SLAs, environments I can't just turn off at will — gives me a sense of responsibility that's different from what I feel with my own products. Not better or worse: different. More formal, more distributed, more dependent on others.

The indie work teaches me things I would never learn in a company.

When you're the only developer, you can't delegate hard decisions. You can't wait for someone else to solve the infrastructure problem, or decide the architecture, or figure out how electronic invoicing works. You have to understand everything well enough to do it, including the parts that don't interest you.

This builds a breadth of competence that specialized work tends not to develop. I'm not the world's best DevOps, but I can deploy an application and keep it running. I'm not the best designer, but I can build usable interfaces. I'm not an accountant, but I understand my tax regime well enough not to be completely dependent on others.

The Cost of Context Switching

The part that's invisible from the outside is the cognitive cost of keeping both modes active.

It's not just the time — it's the hours. But even when you have the time, it takes energy to switch from one context to another. Finishing an intense work session and opening the laptop to work on Barba Studio isn't automatic. There's a transition — not always quick — between "Lead Engineer solving a system problem" mode and "solo developer deciding what to ship this week" mode.

Some evenings the transition doesn't happen. I close the laptop, open the personal projects, and can't get into flow. It's not laziness — it's that any kind of intensive work depletes cognitive energy, and forcing a context switch when the tank is low produces mediocre results in both directions.

I've learned not to fight it. The evenings I can't work on personal products, I don't work. I do something else. The next day works better.

The Skills That Don't Transfer

Not everything I learn in one context is useful in the other.

The coordination and communication skills I use as a Lead — facilitating group decisions, managing priorities with multiple stakeholders, giving constructive feedback in code review — aren't needed when I work alone. There's no team to coordinate, no stakeholders to persuade.

Conversely, the speed and ease with which I make decisions alone — without consensus, without validation, often with incomplete information — would be wrong in the company context. In a team, that speed is called unilateralism and it causes problems.

The risk is bringing the wrong mode into the wrong context. The decisiveness that works alone becomes unilateralism in a team. The collaborative caution that serves in a company becomes paralysis on a personal project. Recognizing which context you're in — and adapting how you work accordingly — is the skill that holds both things together.

Why I Keep Doing Both

The honest answer is that neither one alone would be enough.

The full-time job provides financial stability, exposure to scale problems I wouldn't have on my own, and a social structure that solo work doesn't offer. Working on a team has a rhythm and energy that indie work can't replicate.

The personal products give autonomy, the satisfaction of owning what you build, and the freedom to make mistakes my way without consequences for others. It's a type of work I wouldn't stop doing even if it weren't financially necessary.

They're two different things that feed each other. As long as I can keep both alive without one suffocating the other, it makes sense to continue.