Project Scope
I was commissioned to build a reservation management site for members of a one-on-one training gym, and developed it alone. I planned the work over more than six months and implemented the required features one by one. I handled the full path myself: requirements, screens, server-side code, operation, and ongoing fixes.
The main thing I kept in mind was preventing problems in real store operations. When defining personas, I learned that the gym's main users were in their 30s to 50s, so I paid close attention to making the UI usable even for people who are not digital natives.
If reservation, cancellation, payment, member information, admin permissions, or email notifications are implemented carelessly, staff members have to compensate manually. I developed the system carefully to prevent that.
Implementation Scope
The frontend was built with Nuxt and Vuetify and deployed on Cloudflare. The database is Cloudflare D1 with Drizzle ORM and NuxtHub, email delivery uses Resend, and bot protection uses Turnstile. For payments I integrated Stripe subscriptions and used webhooks to receive completed payments and update member state.
Cloudflare D1 is SQLite and does not support transactions, so I use batch operations instead to preserve atomicity. I also added several other measures to preserve ACID-like guarantees.
On the member side, the site handles account creation, reservations, cancellations, and viewing active plans. On the admin side, it handles member management, reservation slot management, products and plans, order checks, and various settings. I also made it possible to create moderators separately from admins, split permissions, and configure which admin features each person can read or write.
Reservations required not only normal schedules, but also holidays and exceptional slot adjustments. Store-specific rules such as reservation email notifications, cancellation notifications, and whether admin approval is required can be changed from the admin settings. It was difficult to decide every requirement before building, and there were many major additions and fixes after implementation.
Working Alone
Because it was a solo project, I could move quickly, but if I postponed decisions, it would burden both me and the client. I had to decide everything myself, from database handling and screen structure to email copy, payment failure behavior, and the granularity of logs visible to admins. Developing without coordinating with anyone is both easy and hard.
In this project, the initial requirements rarely stayed unchanged until the end. Feedback after launch also led to specification changes. That is why I started with the minimum set of features and expanded gradually. This helped reduce development cost significantly.
At the same time, frequent interviews can burden the client. I still find it difficult to balance how much I should proceed on my own and how much I should leave to the client.
After Building It
In personal development, if I change my mind I can rebuild freely, and if I am satisfied I can abandon the project. Work accepted as a job is different. It is not enough for the system to run; it must be manageable by the other party, fixable when trouble happens, and built with cost growth in mind.
This project required an unusually large number of decisions, from database fields to reservation management methods. Building it from scratch was valuable experience. I am also responsible for maintenance, so I will continue working on it.