When I first started building my graduation project, I was certain that writing code and designing an interface were the only things that mattered. Deployment architecture felt like something senior engineers worried over, not a thing for a student still figuring out backend basics.
But as development progressed, it became clear: where your app actually runs isn’t a technical afterthought. It’s the foundation that determines whether your project survives past launch or collapses under its own technical debt. Choosing between a Virtual Private Server (VPS), a dedicated machine, cloud hosting, or going serverless is always a trade-off between control, complexity, and budget. And as a student, I quickly learned that I couldn’t afford to guess wrong.
The Trap of Professional Tools
I started weighing my options honestly. A VPS looked tempting at first—affordable, full root access, total control. But I soon realized the hidden cost: managing Linux, configuring firewalls, scheduling backups, and monitoring traffic would easily swallow half the time I’d allocated for coding my diploma.
A dedicated server was immediately out of the question. Renting an entire physical machine for a student app is like leasing a cargo truck just to carry a backpack. I also looked at big cloud platforms like AWS, Azure, and Google Cloud. They offer powerful features like automatic scaling and professional tools. However, their control panels were very complicated and hard to understand. I was also worried about the cost. If I forgot to turn off a test server, I could get a massive bill very quickly. For a student budget, this was too risky.
The “Aha!” Moment
That’s when it hit me: does my project even need a server? My app is a local-first notes manager. Its core promise is speed, reliable on-device storage, and offline functionality. Running a full server 24/7 with a database, security settings, and traffic control was completely unnecessary. In fact, it would have slowed me down.
I realized I was trying to use complex professional tools for a simple student project. A dedicated server would not help me; it would only take up my time. I needed to focus on what really matters: building a stable and easy-to-use app.
Embracing Serverless
That realization led me straight to serverless architecture. It wasn’t a compromise; it was a deliberate fit for my actual needs. I don’t need a constantly running process. I just need a few lightweight cloud functions that trigger only when the user opts to sync selected notes or authenticate across devices.
I wrote the code, deploy it with a single command, and let the provider handle scaling, security patching, and billing based on actual usage. Sure, there are trade-offs: cold starts, mild vendor lock-in, and less low-level control. But for me, that isn’t an issue. For a diploma project, that’s a fair price to pay for focusing on product development instead of DevOps firefighting.
Conclusion
All in all, I’ve learned that the right architecture isn’t the one that sounds most impressive in a presentation. It’s the one that solves your specific problem with the least headache. Serverless gave me just enough storage and functions, without the infrastructure headaches. For a beginner developer, it’s been the perfect learning ground: I’m working with real APIs, designing stateless functions, and shipping a project that costs almost nothing.
Sometimes, the best server is the one you don’t even have to think about.
