For years I worked as a freelance developer.
I built products, solved technical problems, and delivered features.
But there were three startups that changed the way I understood my role.
It wasn’t a planned transition.
It was an evolution forced by mistakes, difficult decisions, and real-world context.
1. Startup A: When the Problem Wasn’t the Code
I joined as an Android developer. There was already a CTO.
From the beginning I suggested validating the product with an MVP.
Not building for years without real feedback.
I insisted.
The insistence created friction.
And eventually I gave up.
The result was more than four years of development without solid commercial validation.
A lot of money was invested.
People were hired without much scrutiny.
There was a constant feeling of progress… but there was no real validation.
The company closed in 2025.
During that period I was replaced by someone cheaper.
It wasn’t personal. It was business.
But it confirmed something I had suspected: technical decisions that aren’t aligned with strategy end up being expensive.
My biggest lesson there wasn’t technical.
It was this:
Being right is not enough if you don’t know how to influence.
I didn’t manage to communicate my point of view effectively.
I didn’t know how to turn judgment into leadership.
2. Startup B: When the Title Doesn’t Guarantee Leadership
This time there were three founders.
One assumed the role of CTO, but without real prior experience in that responsibility.
The project moved forward as a side project.
The platform was more of a personal tool than a scalable foundation.
Over time, the CTO’s involvement decreased.
Until he acknowledged something important:
“This is the profile we need.”
I took on the role.
My first decision was clear: rebuild the platform from scratch, reusing what was useful, but designing it with a real product vision.
Here I understood a key difference:
- A developer optimizes code.
- A CTO optimizes decisions.
Architecture stopped being a purely technical matter and became a strategic one.
3. Startup C: The Moment You’re No Longer “Just a Developer”
In this fintech startup I started as an Android developer.
From the beginning it was expected that the backend would need to evolve.
But an external regulatory change forced us to prioritize it earlier than planned.
The difference from my first experience was clear.
This time:
- I analyzed the full context (regulation, costs, team, timelines).
- I chose AWS balancing budget, resilience, and scalability.
- I designed with future growth in mind, not just fast delivery.
- I balanced technical debt with real business progress.
The backend wasn’t a surprise.
The change in direction made it critical.
And that’s when I understood something fundamental:
Leading technology means making decisions under uncertainty, not coding without it.
What Really Changed
Between the first and the third startup there was a transformation.
I learned that:
- Early validation is not optional.
- Feedback cycles must be short.
- Hiring is a strategic decision, not just an operational one.
- Good practices are not bureaucracy — they are future protection.
- Context matters more than the chosen technology.
- Technical authority is exercised with clarity and responsibility, not ego.
Today, when I work with a startup, I don’t just execute tasks.
I take responsibility for the technological direction.
Even when the title doesn’t explicitly require it.
That, for me, is what being a fractional CTO means.
It’s not about hierarchy.
It’s about accepting that your technical decisions change the destiny of the company.