More than a list of companies
I’ve been building software professionally for over fifteen years.
During that time I’ve worked with startups, outsourcing companies, consultancies, and enterprise organizations. I’ve helped modernize legacy systems, build greenfield products, develop internal platforms, and deliver software used by thousands of people across industries including finance, telecommunications, healthcare, manufacturing, retail, and tourism.
Although most people know me as an Angular developer, my work has rarely stopped at the front end. Throughout my career I’ve naturally moved toward full-stack development, system design, and helping shape products from the first conversation with stakeholders to production.
More than any particular framework or language, I’ve learned how software evolves—and how to build it in a way that keeps evolving with it.
A career built in stages
Learning to build (2011–2016)
My early years were spent working on a wide variety of projects, often switching between PHP, JavaScript, databases, infrastructure, and front-end work depending on what the project needed.
That variety turned out to be one of the most valuable parts of my career. Instead of becoming attached to a single technology, I learned how different systems fit together and how business requirements translate into software.
Those years taught me adaptability.
Learning to own software (2016–2019)
As I moved into larger companies, I started working on enterprise applications with bigger teams, stricter processes, and more complex requirements.
I worked on products for companies like Virgin Media and Legal & General, became a Team Lead, and learned that writing code is only part of the job.
Architecture, communication, mentoring, planning, and delivering predictable results became just as important as implementation.
Those years taught me ownership.
Learning the business side (2019–2022)
Co-founding Fire Flamingo Dev changed how I think about software.
Instead of receiving requirements, I helped define them.
I worked directly with clients, translated business processes into applications, estimated projects, made architectural decisions, and balanced technical quality with budgets, deadlines, and business priorities.
That experience changed my perspective permanently.
Today, when I build software, I don’t just think about how something should be implemented—I think about why it exists in the first place.
Building products, not just features (2022–today)
My recent work has focused on modern Angular applications and full-stack development using Angular and NestJS.
I’ve worked on everything from enterprise applications to startup MVPs, designing back-end services, databases, APIs, authentication systems, real-time communication, testing strategies, and front-end architectures.
What I enjoy most is joining projects early, when the important decisions haven’t been made yet.
Choosing the right architecture at the beginning is often worth more than fixing the wrong one later.
What I’ve learned
Looking back, the technologies have changed constantly.
The principles haven’t.
I try to write software that someone else can understand six months later.
I prefer simple architectures over clever ones, practical solutions over theoretical perfection, and systems that can evolve rather than systems that impress.
Whether I’m working alone or with a team, my goal is always the same:
Build software that solves real problems, remains maintainable, and makes the next person’s job easier.
Still learning
The part of software engineering I enjoy most today is designing systems.
Not because architecture diagrams are interesting, but because good technical decisions quietly remove problems before they appear.
Lately I’ve also been spending a lot of time experimenting with local AI models, developer tooling, automation, and self-hosted infrastructure through my homelab. Those projects aren’t client work, but they’ve become one of the best ways I continue learning outside of my day job.