When I left my OffSec job to create vulnit, I knew there would be a lot of technical work involved. The thing is that me and my partners all have a very similar background and we came from the same company, so we are aligned in how to work. We understand the same problems, we speak the same technical language, and we usually agree pretty quickly on what good security work looks like, although each one has it’s personal expertise that is shared to the rest.

That is good but I also saw that it has some cons. If everyone is good at the same things, everyone is also bad at the same things. In our case, it’s all related to business.

None of us started this project because we wanted to replace our technical work to become sales people, or because we wanted to spend our time preparing pitch decks, going to events, explaining the same idea over and over again, or having commercial conversations with potential clients.

We started this because we like building security products and because we think mobile application security is going to need much better tooling in the next few years.

But building a good startup is not about what you already know how to do.

In a company, someone has to explain the product. Someone has to talk to companies. Someone has to validate the problem, meet potential clients, listen to uncomfortable feedback, and make investors understand why this should exist.

In vulnit, part that role has ended up falling on me. For example, regarding pitch decks and talking with persons that could buy the product, my cofounders say I am the one who is best at this out of the four of us, so whether I liked it or not, I have had to prepare myself for it.

And honestly, I am glad it happened.

Learning to pitch

Over these last months I have participated in a couple of programs where the exercise was very simple: stand in front of people, explain what you are building, and make them care. That is called “pitching” in the entrepreneur world.

The two main events where I pitched were:

Both events forced me to do something that is not natural when you come from a technical background. You cannot just say “we are building a security testing platform for mobile apps” and expect people to magically understand the whole concept and what you are contributing to the ecosystem.

You need to explain the problem, who has it, how they are solving it today, why that is not enough, and why your approach makes sense now. That is a very different skill from building the product.

At the beginning, I was much more focused on the solution. That is the normal instinct. You see a problem and your brain goes straight into architecture, features, automation, infrastructure, edge cases and so on. You start thinking about how to build the best possible version of your project and how it will be in a year or two.

But these programs pushed us in another direction: think harder about the problem before falling in love with the solution. I had to answer questions like:

  • Who exactly has this problem?
  • How are they dealing with mobile security right now?
  • What is painful about that process?
  • What would make them change?
  • What do they need to hear in the first five minutes to understand that this matters?

These questions changed how I think about the product and my perspective about the first steps building a business. I recommend everyone trying to answer this questions before even putting their hands on a keyboard (if building a software product).

BREAKER, feedback and uncomfortable questions

BREAKER Impulsa was especially useful because it gave us something we needed more than we realized: feedback from people who were not emotionally attached to the product and also not familiar with the cybersecurity field.

We did not win the program, but we received high quality mentoring, very interesting questions, and a much better idea of what we had to validate next. Some of the feedback was positive, some of it was uncomfortable, and some of it forced us to explain things that we thought were obvious but clearly were not.

And this last is very important: you work in security, especially in offensive security, you assume a lot of context. You assume people understand how attackers think. You assume they know why manual testing does not scale. You assume they see why AI-generated code and AI-assisted attackers are going to create a weird security gap.

But people that are not in the security field do not know these things. They know much less than you think they know.

So the pitch has to build the bridge. Not by dissecting the idea down (because pitch decks are 5 minutes long at most), but by making the problem clear enough that someone outside your bubble can follow it.

But practicing makes the master. When you participate in these things constantly, you start preparing answers before the questions arrive. You start noticing which parts create confusion and which parts are clear.

Winning a stand at Alhambra Venture

Through the University Entrepreneurship Competition, we won a prize that gave us a stand at Alhambra Venture 2026.

Alhambra Venture is an event with startups, investors, companies and people who are used to hearing pitches and filtering ideas quickly.

In this event, there are a lot of investors that are going to listen briefly to your idea and to more than 50 ideas. You have a few minutes to make someone understand your problem, and it was another exercise that went good. A lot of people understood the pain, and wanted to hear more about it, by asking interesting questions. ## The unexpected pitch deck that went good

At Alhambra Venture I also ended up giving a pitch on the main stage almost by accident.

Someone from another company could not give their pitch, and suddenly it was my turn. I had not prepared that specific pitch for that specific room. I had practiced for BREAKER Impulsa and for the entrepreneurship competition, so the ideas were there, but the situation was not exactly planned.

And the pitch went than I expected, actually. After the pitch, a few people came to tell me they liked the idea and, more importantly, that they had understood the situation we are trying to explain.

Summary

I still love the technical side, but the business is not only coding and building the infra. Talking to people is part of the project. Validating the problem is part of the project. Explaining the idea in a way that someone actually cares about is part of the project. Getting challenged by mentors is part of the project. Standing in a room full of people and defending why this should exist is part of the project. And I am learning a lot of these things now, because I had not previously needed to.

What I am taking with me

If I had to summarize these months, it would be this: do not fall in love with the first version of your solution. Fall in love with understanding the problem properly.

The product will change. The pitch will change. The market will correct you. Mentors will point out things you were avoiding. Clients will tell you what actually hurts. And if you listen, the idea gets better.

I know a lot has to be done, but I also know I have learnt a lot of things during these three months, and this motivates me.