From Industrial Engineer to Full-Stack CPTO: How I Accidentally Learned to Code and Lead Tech
I failed programming in my first year of Industrial Design Engineering. Not just struggled - completely failed. If someone had told me then that I’d end up as CTO/CPO of a tech startup, writing full-stack code and making architectural decisions, I would have laughed.
This is the story of how an industrial engineer who couldn’t understand basic programming concepts accidentally became the technical leader of Voicit, our HR tech startup. It’s not the typical “I always loved coding” narrative. It’s messier, more real, and hopefully more useful for other engineers wondering if they can make a similar transition.
The First Failure: When Programming Made No Sense
First year, programming course. I completely bombed it.
It wasn’t just that I didn’t understand the syntax - I couldn’t grasp the fundamental logic. How do you tell a computer what to do? Why does this sequence of words make anything happen? The whole concept felt abstract and disconnected from the physical world I was used to as an engineering student.
I had to retake it, and that's when something clicked.
The “Aha” Moment: Understanding the Logic
When I retook programming, something fundamentally changed in my brain. It was one of those rare “OHHHH, that’s how it works!” moments. Suddenly, the logical flow made sense. Programming wasn’t about memorizing syntax - it was about breaking down problems into logical steps.
That moment of understanding was transformative, but I had no idea it would define my career path.
The Hardware Years: Robots, Drones, and Real Things
After that programming course, I didn’t touch code for two years. I was busy with mechanical engineering, 3D modeling, and all the physical aspects of industrial design.
Then, in my third year, I went on an exchange program to Universidad Politécnica de Valencia. That’s where everything changed.
We had to develop a robot, and I volunteered for the programming part using Arduino and C++. I already knew some C++ from that retaken course, and the idea of creating behavior for a physical robot absolutely fascinated me.
This wasn’t abstract programming anymore - this was making a real thing move and think.
That summer, I bought my own electronics and tried to build a mini-drone. Eventually, this led to my collaboration scholarship developing a larger drone with more powerful electronics. Hours and hours learning embedded software, understanding electronics, and mastering 3D printing.
By the time I graduated, I had fallen in love with robotics. That’s why I jumped straight into a master’s in Mechatronics Engineering.
The Unexpected Pivot: From Hardware to UI/UX
During my master’s, I started an internship at Ortoplus, a dental laboratory. I was supposed to work on 3D printing, but somehow ended up as a Product Designer doing UI/UX.
This transition seems random, but my background as a designer gave me an advantage. I’d always been interested in graphic design - I’d even done some freelance work designing sports uniforms. Having a designer’s eye made the transition to UI/UX natural.
I became obsessed. I studied design systems, analyzed apps, and spent hours talking with the programmers daily, learning how apps actually worked.
One day, they let me create an HTML screen. I did it completely wrong, but that hands-on experience taught me more than any tutorial.
Web Development: The Overwhelming World of Too Many Concepts
When I started getting serious about web development, the sheer number of concepts was overwhelming.
Frontend, backend, DevOps - each world has incredible depth. Coming from the relatively straightforward world of mechanical engineering, this felt like entering a maze where every path led to ten more paths.
I started with Django and Python, learned a bit, but when Voicit became real, we migrated everything to React with JavaScript and Node.js. The decision was about scalability and sharing the same language between frontend and backend.
Over time, my technical stack evolved further. Today, I develop the frontend in JavaScript (though I’m planning to migrate it to TypeScript someday) and the backend in TypeScript. This mixed approach isn’t ideal from a purist perspective, but it reflects the reality of a growing startup - you make decisions based on immediate needs and gradually improve the codebase.
The transition from physical engineering to web development was mentally challenging. You go from building things you can touch to building digital experiences that exist only in browsers.
Becoming CPTO by Necessity, Not Choice
When we raised our first 100k€ investment, we tried to hire a CTO. It was impossible. So I assumed the role as CPTO and hired an excellent programmer who became my teacher.
During that period, I focused on frontend and users while he handled backend and DevOps. I learned constantly from him - every technical decision, every architectural choice.
Then he decided to leave.
The Moment of Truth: Sink or Swim
When our programmer left, I felt enormous pressure. The options were clear: either I figure out how to handle the backend and DevOps, or the company dies.
There was also our browser extension built with Svelte that I had to learn and maintain. Suddenly, I wasn’t just maintaining a React app - I was responsible for the entire technical stack.
I realized it was either "I manage to move this forward" or "I manage to move this forward." There was no third option.
He eventually came back, but by then I’d decided we’d both be full-stack. When he left again, I was ready.
The DevOps Reality Check
As we scaled users, I decided to outsource DevOps because I felt it was beyond my knowledge. We went from paying €200 to €600 in infrastructure plus the external company’s costs.
Looking back, we probably could have handled more time with the old infrastructure. That migration was expensive and probably premature.
When that company went bankrupt, they helped me migrate the dependencies and transition to GitHub Actions. I learned a lot about CI/CD pipelines, and while I’m still not a DevOps expert, I can solve problems as they arise.
My Programming Language Journey
Looking back, my progression through programming languages tells the story of my transition:
- C++ (University) - Where I first understood programming logic with Arduino
- Python/Django (Early Voicit) - My first attempt at web development
- JavaScript (Frontend) - React development that I still use today
- TypeScript (Backend) - Added for better type safety and developer experience
- Svelte (Browser Extension) - Learned by necessity when maintaining our extension
The mixed JavaScript frontend and TypeScript backend setup isn’t perfect, but it reflects startup reality: you optimize for shipping, not for technical purity. Someday I’ll migrate the frontend to TypeScript for consistency, but right now, user features take priority over code elegance.
How I Work Today: Designer-Developer Hybrid
Today, design and development are completely integrated in how I work. When I talk to users and detect a need, I understand how to approach it technically.
Obviously, this means no part gets a perfect 10, but I follow the strategy of launching quickly and iterating based on feedback.
I abandoned long-term roadmaps completely. We used to plan features up to 2 years ahead - complete madness! Now I plan maximum 3 months because priorities change constantly, and what you knew a month ago is different from what you know today.
The Advantages of an Industrial Design Background
I believe my background gives me specific advantages that pure computer science graduates might not have:
- Better user understanding - Industrial design teaches you to think about how people actually interact with objects
- Systems thinking - You learn to see the whole product, not just the code
- Constraint-based problem solving - Physical engineering teaches you to work within real limitations
- Design sensibility - I can move between technical architecture and user experience naturally
Advice for Engineers Wanting to Transition
I’m terrible at giving structured learning advice, but here’s my pragmatic path:
- Start with frontend - It’s visual and immediate. You can see what your code does
- Understand you’ll need backend - When you hit that wall, learn backend to connect everything
- Eventually learn DevOps - When you need to host everything somewhere
The key is learning by necessity, not by curriculum.
What I Miss and What I Love
I miss the electronics and 3D printing days sometimes. There’s something satisfying about building physical things.
But what I really enjoy is making things that work - whether that’s a robot that moves correctly or an app that solves a real problem for users.
The Reality of Being a Technical Founder
Today I handle development, roadmap decisions, design, incident management, some sales, and programming. It sounds overwhelming, but when necessity drives learning, you’d be surprised what you can absorb.
The truth is that most technical decisions aren’t about knowing the “perfect” solution - they’re about understanding trade-offs and moving forward with imperfect information.
For Other Engineers Considering This Path
If you’re an engineer from another discipline thinking about learning to code to create products, here’s what I’ve learned:
- Your engineering background is an advantage, not a limitation
- You don’t need to be a perfect programmer to lead technical products
- Understanding users and systems often matters more than knowing every framework
- Learning by building real things is more effective than following tutorials
The transition from hardware to software, from individual contributor to technical leader, isn’t just about learning to code. It’s about learning to think in systems, prioritize under uncertainty, and build things people actually want.
And sometimes, the best preparation for that is failing programming in your first year and having to figure it out from scratch.
If you’re an engineer thinking about making a similar transition, I’d love to hear your story. The path from engineer to technical founder is different for everyone, but the challenges are surprisingly similar.
What’s your biggest hesitation about learning to code? Let’s discuss it.