A year and a half ago, I was stuck in a big-corp role, completely demotivated and unsure whether software was even my thing. I had spent months building PoCs, which were exciting even though they never reached customers. When I was moved to a real product team, I expected to finally feel closer to users, but instead everything felt even slower and more distant. I missed the sense of impact I used to have.

That’s when I realised that what I had enjoyed about PoCs wasn’t just the technology but the ownership and the direct influence on outcomes. I wanted that same intensity, but with real users on the other side. A startup suddenly felt like the right match.

I had always been close to the Barcelona startup scene, so I applied to a role promoted by a VC, for one of their portfolio companies. The tech stack matched mine, even if the experience requirements didn’t. The "tech lead" (he was literally the only developer) gave me a small API challenge, I built it, and he liked both the solution and how I approached it.

Then I met the CEO (a telecom engineer, like me), who made me laugh multiple times and gave me the trust that the rest of the process didn’t. From the outside, everything looked sketchy: no website, no socials, a remote-only team, a tech lead with a peculiar Spanish English mix, and a former founder whose previous startup (exited, Blueliv) landing looked outdated and boring. But I had nothing to lose, so I said yes.

Months later, the Zynap team had doubled, we had onboarded our first customers, we had basic processes in place, and we had moved from meeting in coworkings once a month to having our own office. It was intense, chaotic, and full of lessons. Here are the most important ones.

1. Speed Is Everything

I quickly realised that the most important thing was to get things done fast and iterate even faster. Whenever I asked the tech lead how he preferred something to be done, his answer was always the same: “Do it however you want, in the way that gets it done fastest.”

We moved incredibly fast. Our approach was to build the MDV (Minimum Demoable Version), the smallest thing we could show to a real user. It often looked ugly or incomplete, but it clearly showed the value. Even when the product was half broken, users were excited to try it because they immediately understood what it could do for them.

That speed kept us from overbuilding. Instead of guessing what to polish, we listened closely, fixed only what real users were actually touching, and improved specific parts of the system based on their feedback. Customers loved that we responded quickly and incorporated their suggestions almost in real time.

The product had cracks everywhere, but the value was visible, people were willing to work with us, and each iteration made it better. That is the power of speed.

2. The Importance of Ownership

Two months in, we onboarded our first big client and grew the team. That’s also when things started breaking: bugs in demos, half-finished features, occasional outages.

Part of it was the price of moving fast. But another part came from blurred responsibilities. Developers expected PMs to catch issues; PMs expected developers to magically cover every edge case while still delivering fast. Management wanted both speed and quality, impossible when the product surface is large and you have a "deep tech" product like the one we had.

We shifted to bottom-up ownership. Engineers started calling out risks, pushing back when necessary, and defining clear boundaries for what “done” actually meant.
This alone reduced bugs more than any tool or process we introduced afterward.

3. AI First Mentality

One of the things I’m most grateful for is how deeply AI became part of our culture. We’d get 6 a.m. messages from the CEO saying: “Use the fucking AI at all levels. IT IS MANDATORY!”

It was funny, but also true. Everyone used AI: designers, PMs, engineers. Tools like Claude Code or Cursor multiplied our speed, and in a startup, speed is your only real advantage.

4. Your Network Is a Superpower

Launching in a space where you have a network changes everything. Our CEO and head of sales personally contacted old colleagues and friends, and those warm intros turned into our first pilots and first paying customers.

It was the same for hiring. Because of the CEO’s reputation in cybersecurity, we brought in people who are normally extremely hard to hire: malware analysts, ethical hackers, credential-leakage specialists, and even industry leaders like Alfonso Muñoz.

This ability to attract top-tier, scarce talent became one of our strongest competitive advantages, giving us capabilities that few organizations in the sector and initial market could match.

6. Fake it Till You Make It

In the early days, everything is uncertain and resources are scarce. You need people who believe the mission justifies the means and are willing to do whatever it takes to achieve the goal. This sometimes means making decisions or taking actions that some might see as ethically gray.

Not everyone is comfortable with this mindset. Early hires who are not aligned with it often struggle. These gray-area decisions open doors that otherwise wouldn’t exist, and thanks to speed and iteration, most of them quickly turn into real achievements.

7. Less Is More

Because we had significant funding early on, thanks to a founder with a strong track record, we built a lot very fast, including things we didn’t need. Having our own infra person pushed us toward over-engineered solutions and owning infrastructure that should’ve been managed services.

The result was a massive operational backpack that didn't slowed us that much because the team pushed very hard. Focusing on narrower use cases and a simpler, more managed setup would have saved us enormous headaches.

8. Set Standards From Day One

One of our issues was the lack of standardisation. Every developer used their preferred libraries, folder structures, and patterns, which meant we were constantly reinventing the wheel and creating unnecessary friction.

When the new CTO, Jordi Miró, joined, one of his first priorities was to push for shared abstractions and basic engineering standards. This might sound like bureaucracy, but implementing light, flexible foundations early actually accelerates development instead of slowing it.

The later you do it, the harder it becomes to fix.