From CS Student to Automation Dev

I'm a CS student in Bolzano, which means I'm surrounded by two things: small businesses that have existed for decades without ever needing to think about their digital infrastructure, and a lot of spare time to notice that.

The first thing I built for someone else was a simple booking page for an agency a friend worked at. Not because they asked me to — because I kept watching staff take phone calls that could have been a form. It wasn't a serious project. I built it in a weekend and showed them. They started using it immediately. That was enough for me to understand that there was a gap between what these businesses were using and what was actually possible.

The more serious project came when I started working part-time at an automotive agency. The job was not development-related. But I found myself mentally cataloguing every inefficiency I encountered: the WhatsApp threads, the paper documents, the manual confirmation process for appointments.

After about two months of taking notes, I started building. Not for them initially — for myself, to prove it was possible. At some point the thing was functional enough that it made more sense to deploy it than to keep it on localhost. That's still how I tend to build: solve the problem first, worry about deployment later.

The moment that shifted my understanding of this work was watching someone use the booking system for the first time. A client who had previously always called — and whose appointments had previously required three back-and-forth exchanges — booked, uploaded their documents, and received confirmation in about four minutes. Without talking to anyone.

That wasn't a technical achievement. The tech was straightforward. It was a systems achievement — replacing a slow, unreliable process with a fast, reliable one. I stopped thinking of myself primarily as a developer after that. I started thinking of myself as someone who builds systems that remove friction.

I'm still a student, which means I have more to learn than I've built. But the direction is clear: I want to work with businesses that have real operational problems — the kind that have been lived with for years because nobody thought a solution was available — and build systems that actually solve them.

Not beautiful systems, necessarily. Not technically impressive ones. Ones that work, that the people using them trust, and that free up human time for things that actually require humans. That's the whole brief, really.