Project Case Study
Building Cutz By Casper: scheduling, payments, and SMS in a real booking app.
Cutz By Casper gave me a practical full-stack problem to solve: make booking clearer for clients while giving the business a structured way to manage scheduling, deposits, and communication.
Why the project exists
I built Cutz By Casper around a service-business workflow: a client needs to understand the service, choose a time, confirm the booking, and receive clear follow-up. A barber or administrator needs the same flow to stay organized without relying on scattered messages or manual reminders.
The verified implementation uses Next.js App Router, TypeScript, TailwindCSS, Supabase Postgres, Stripe Checkout, Twilio SMS, admin scheduling tools, and an AI secretary route. I treated the project as more than a landing page. The goal was to practice connecting the interface, data, payments, and notifications into one dependable experience.
Booking workflow
The booking flow starts with a mobile-first customer path. The user should be able to understand the service and move toward an appointment without feeling lost. That meant keeping the interface direct, making calls to action visible, and building around the real sequence of a booking instead of a generic contact form.
The AI secretary route supports the same goal: guide the client toward a time, connect the request to availability, and make the next step explicit. I did not want the feature to feel decorative. It had to support the actual booking workflow.
Scheduling, payments, and notifications
Scheduling was the center of the application because every other piece depends on it. If availability is unclear, the checkout and notification layers do not matter. I approached the scheduling logic as an operational problem: define the action, confirm the next state, and reduce ambiguity for both sides of the appointment.
Stripe Checkout is used for the deposit path, and Twilio SMS is used for messaging. Those pieces matter because they move the app from a visual prototype toward a real service workflow. A booking application has to communicate, not just store data.
Admin and operational thinking
My field-operations background affects how I think about admin tools. The administrator should not have to guess what happened. The system should make the current state understandable and keep the work organized. In Cutz By Casper, that meant thinking about the business side of scheduling, deposits, and customer communication as part of the same system.
I also paid attention to mobile behavior because many service bookings happen from a phone. A polished desktop view is useful, but the mobile path has to carry the experience.
What I learned
Cutz By Casper reinforced that full-stack work is coordination. The interface, database, payment flow, SMS layer, and admin workflow all have to agree with each other. A small unclear step can create confusion for the user or extra work for the business.
If I were improving the project next, I would continue refining calendar clarity, admin visibility, edge-case handling, and testing around the booking path. Those improvements would make the workflow easier to maintain and easier to trust.
Project links
Review Cutz By Casper on the projects page · Open the live app · View the GitHub repository · View my developer resume · Back to the blog