A Physics Practice App for the Hungarian Érettségi
How I learnt what good software actually means.
Producing value is the ultimate test of software. Users don’t care about the cool tech or clever architecture; often, they don’t even care about half the features. They have a problem they want your software to solve.
The problem
My classmates and I were preparing for the physics component of the Hungarian érettségi, the secondary-school leaving exam whose results also count towards university admission. We were advised to start two years in advance by solving questions from past exams1. But the archive mixes questions from across the curriculum. That makes it tedious to practise one topic and hard to tell whether a question covers material you simply haven’t learnt yet.
The evolution of the solution
I manually extracted the questions and diagrams from years of exam PDFs, a perfect way to procrastinate on studying. Then my physics teacher, the project’s main stakeholder, and I categorised every question by topic. Finally, I built a small interface over the database. The site still runs at fizika.schmelczer.dev2, making the questions searchable and generating mock exams using only topics a student should already have mastered.
Despite being one of my earliest projects, built with only a rudimentary understanding of full-stack development, it was my most popular app for years, measured by both active-user count and time spent per user. It has stood the test of time too. Students at my old school, PTE Babits Mihály Gyakorló Gimnázium, still use it to prepare for the same exam.
The app has gone through a few iterations. It started as the most spaghetti-like PHP app imaginable, backed by a real, yet absolutely unnecessary, MySQL database. But it worked. I got a good score on the exam and left the site running for future students.
Eventually, hosting a full-blown database became too expensive to justify, so I migrated everything to a static site served through Firebase. Year after year, students then wrote in asking how to add the latest questions, and guiding each of them through the GitHub workflow became tiresome. So at the beginning of 2026, I vibecoded a small CRUD interface that edits a JSON file on disk. The file is under version control, so a bad edit can always be recovered. We’re back to running a backend server, but this is where self-hosting compounds3: the infrastructure was already in place, so the marginal cost was negligible. Happy users, happy maintainer.
Conclusion
There are two takeaways. First, data can be far more important than the app around it: Fizika’s wrapper has been replaced twice without changing its core value. Second, building software for the thrill of engineering is different from building software to create value at minimal cost. This project taught me the value of both.
