Before the code
My route into full-stack engineering was not a straight line. I worked in QA, customer support, and project management before moving into frontend development and then technical leadership. Each role gave me a different view of the same thing: the distance between software that exists and software that helps someone.
I still work inside that distance. Today I own a production multi-tenant SaaS platform at YLM Solutions, from its SQL schema and backend services to the interfaces people use in the office and in the field. The earlier roles have a lot to do with how I approach that responsibility.
Learning to question the happy path
At Fundtech, my work included system tests, integration tests, acceptance tests, release upgrades, and production helpdesk support. Testing makes you look beyond the intended sequence of clicks. You have to ask what happens when a dependency is unavailable, an assumption is wrong, or a release reaches a real environment.
Later, supporting automated systems in the municipal sector put me closer to the people dealing with those failures. A technical issue and a customer problem can be the same event described in completely different languages. Understanding both is useful long after you leave a support role.
Learning what it takes to deliver
Project management at dooble, and then at YLM, meant turning requirements into specifications and working across UX, design, development, and QA. I also worked on websites, analytics, SEO, DNS, and the less glamorous details that stand between a finished page and a functioning launch.
That experience taught me to treat the specification as a conversation. A clear requirement is valuable. So is noticing when the requirement does not quite describe the problem the customer is trying to solve.
Moving closer to the implementation
In 2023 I moved into frontend development at YLM. The work included replacing RDLC forms with Vue-based reporting, handling charts and calculations, building an integrated chat application, and creating internal React tools for repetitive tasks such as barcode generation and data formatting.
The questions became more concrete. What shape should the data have? Where should this calculation happen? How does the interface behave when the input is incomplete? The product conversations were familiar; now I could work on the implementation that followed them.
Owning the whole system
My current role spans Angular, Node.js and Express, Azure SQL, background notifications, deployment, and the Flutter companion we are building. I led a live Angular migration with zero downtime, worked on cloud spending and recovery, and built across reporting, maps, QR workflows, and Hebrew RTL interfaces.
The scope is broader, but the underlying job is familiar: understand what people need, make the technical decisions explicit, and stay responsible for the result. A database decision can become a user-experience problem. A convenient interface choice can become an operational cost.
I do not see the earlier roles as time away from engineering. They gave me more ways to recognize a problem. Now I get to connect those perspectives and write the code that follows.