Not every project makes it into production — and I learned that firsthand during my bachelor's. Our brief was to build a tool for scanning barcodes and NFC tags to support the equipment lending at the Media Technology Service Center (MTSC). The challenge was to build something functional with limited experience and the resources at hand — and that's exactly what we did.

The starting point

Back then we were still newcomers in many areas, but bursting with the confidence that a few lines of code could change the world. Our skills were mostly PHP, JavaScript, and some fundamentals, so modern frameworks felt more like a hindrance than a help. Rather than learning an entirely new framework in six months, we decided as a team to build on the skills we already had — a decision that might make a few seasoned developers smile today.

The development process

Agility and team dynamics: we went agile, with no weekly plan lasting longer than a week. Our sprints had heated debates about how to solve specific challenges — every idea felt naive at the start. But that unburdened, honest collaboration created one of the best team dynamics I've ever experienced. We knew not every sprint looks like a sprint: sometimes you need a break to recharge. You may move faster alone, but as a team you run a marathon.

Technology without the frills: rather than reaching for modern frameworks, we leaned on standard JavaScript and wrote most of our logic in PHP — even though both technologies often get a bad rap. We wouldn't have wanted to do without our self-defined types. For the critical part, the NFC and barcode scanner, we combed Stack Overflow intensively for workable solutions.

Learning and insight — the project was an intense learning process:

• Working with NFC and barcode scanners: we had to get deep into the subject and understand the communication between hardware and software.
• Technical tinkering and pragmatism: betting on proven tools and languages taught us that the latest technology isn't always what leads to success — often the will to build something matters more than the newest framework.
• Teamwork and open communication: our honest, easygoing team atmosphere let us get through the hard phases together. Space and shared breaks were essential to staying motivated over the long haul.

The result and its presentation

In the end we shipped a web app that met all the requirements — flaws and all. We presented it as a team, with a humorous story that mirrored our journey. That presentation was not just a moment of celebration but a valuable learning step. The recognition came too: at the FH St. Pölten project showcase, we came out as the winners. With everything I've learned since, I'd say the tool in its original form wouldn't be production-ready — but the real win was the development and the insight we drew from it.

Conclusion

fherlei was far more than a project brief. It was an intense learning process that taught us how important practical experience, teamwork, and the courage to use tried-and-true methods really are. Even if our tool might not meet the standards of modern systems today, the gain for us as developers was immense. It was the starting point where we realized that every line of code and every discussion — naive or advanced — was a step toward our professional future.

Thanks to everyone who walked this path with me — the challenges, the successes, and the mistakes all made me who I am today.