Project Case Study
Building Redeemed by Casper: from booking prototype to live barber portfolio.
Redeemed by Casper is the project and domain identity for the live Redeemed Precision Grooming website. The current build presents services clearly and hands appointment booking to Booksy, while the earlier prototype taught me important full-stack lessons.
Current project status
The current public site is Redeemed Precision Grooming. It is a mobile-first barber portfolio built with Next.js, React, TypeScript, and Tailwind CSS. Clients can review the work and move into an established Booksy flow for appointment availability and booking.
The current site does not claim a custom booking database, checkout, SMS system, or admin calendar. Booksy remains the booking source of truth. That narrower architecture reduces duplicate operational systems and keeps the public experience focused.
Why the original prototype mattered
Before the current portfolio rebuild, I used the project to explore a custom service-business workflow. A client needed to understand a service, choose a time, confirm a request, and receive clear follow-up. The business side needed a structured view of scheduling, deposits, and communication.
That prototype let me practice coordinating interface decisions, application state, data, payments, messaging, and admin concerns. Those were development exercises and design lessons, not descriptions of the live site's present booking system.
Lessons from scheduling, payments, and notifications
Scheduling was the center of the original prototype 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.
I explored Stripe Checkout for a deposit path and Twilio SMS for messaging in that earlier build. The exercise showed how quickly a custom booking product expands beyond a visual interface. Each integration creates operational ownership, edge cases, and ongoing maintenance that must be justified by a real need.
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 the original prototype, that meant treating scheduling, deposits, and customer communication as one connected system rather than unrelated features.
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
The original Redeemed by Casper prototype 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.
Rebuilding the public experience around a focused portfolio and Booksy handoff was also a product decision: use the established operational tool when it is the right source of truth. Next, I would continue improving accessibility, performance, content clarity, and the transition from portfolio browsing to the external booking flow.
Project links
Review Redeemed by Casper on the projects page · Open the live site · View the GitHub repository · View my developer resume · Back to the blog