01
Discover
The customer picks a service, barber, and time slot
The public site needs to feel premium, but the flow still has to stay clear and quick.
Case Study
Balkan Barbershop
Live client projectSecond freelance client - built a portrait-driven editorial layout with Framer Motion animations that matched the barbershop's aesthetic. Managed design, development, and deployment. Live at balkan.thisisrikisart.com.
Last curated refresh: 2026-05-11 12:39 PM EDT
Project FramingProblem / ContextRole and OwnershipConstraintsArchitectureKey DecisionsIterations and StrugglesLearningsOutcomesNext Improvements
Case Study Map
Project framing
Balkan started as a design-heavy client website but evolved into a much more serious product: a real booking platform with operations, payments, reminders, and admin workflows that had to work for an actual shop.
Problem / Context
A barbershop does not just need a pretty homepage. It needs a customer flow that reduces friction for bookings, supports staff operations, and does not create more work for the owner. The core problem was operational reliability wrapped in a premium brand presentation.
Role and Ownership
I owned the customer booking flow, backend APIs, payments, admin tooling, notifications, deployment, and the final editorial presentation of the brand.
Why now
This project forced me to move past portfolio aesthetics and deal with the realities of client software: payment states, notifications, reschedules, admin visibility, and deployment stability.
Topline
Constraints
- The product had to work for a real shop's operations, not just look premium.
- Payments, reminders, and admin workflows all had to fit a lean single-owner setup.
- Infrastructure had to stay maintainable without a dedicated ops team.
Outcomes
- A real booking platform with payments, admin tooling, and customer lifecycle flows.
- A cleaner DigitalOcean deployment setup after simplifying an overbuilt AWS path.
What changed because of the project
A real booking platform with payments, admin tooling, and customer lifecycle flows.
Architecture
What Balkan does
A customer books a service, the shop gets a reliable operational record, and the owner can run the business without extra manual cleanup.
02
Commit
The booking and payment are captured in one transaction path
The product handles the operational moment where intent becomes a real appointment.
03
Coordinate
The system confirms, reminds, and keeps the admin side in sync
Notifications and dashboard visibility reduce no-shows and owner confusion.
04
Operate
The owner manages appointments, staff, and business flow from the admin surface
The admin dashboard is part of the product, not an afterthought behind the marketing site.
OutcomeThe site behaves like a real booking product for a live shop instead of a pretty brochure that creates more admin work later.
Architecture narrative
The architecture became a classic three-layer product: React frontend for customer and admin surfaces, Node/Express APIs for booking/payment/notification logic, and PostgreSQL for bookings, services, users, and operational state. Around that core, I iterated on notifications, Stripe payments, and deployment until the product matched how the shop actually runs.
System diagram
This is the secondary view: the system shape behind the flow above. It exists to explain the moving parts, not to substitute for the product story.
Booking Flow and Shop Operations
The experience had to serve both the customer booking path and the owner/admin operating path.
Customer
Public site
services, barber, schedule
Booking + payment
Stripe-backed flow
Application
Node/Express API
auth, booking, reminders
Notification layer
email, SMS, reminders
Operations
Admin dashboard
appointments, analytics, staff ops
PostgreSQL
bookings, services, users, payments
Infra
DigitalOcean deploy
Docker + Nginx
Real business constraint
Booking reliability mattered more than novelty because staff and customers depended on it.
Operational loop
The admin surface was part of the product, not an afterthought after the marketing site.
Key Decisions
Build Journey
AI-heavy prototype
Started broader and more experimental than the client actually needed.
Booking product consolidation
The project sharpened once bookings, auth, reminders, and admin tooling became the main arc.
Hardening and redesign
Later work tightened the UI, operations, and deployment until it felt like a real platform.
Struggles
The early scope was too broad and made the product harder to stabilize.
I cut back to the pieces the business would genuinely use and depend on every week.
Notification and payment providers shifted over time.
I treated those integrations as replaceable operational components instead of as hard-coded assumptions.
Aesthetic quality could not come at the cost of the booking flow.
I let the operational path drive the architecture and layered the brand treatment around it.
Learnings
Client products get better when the software matches the owner’s real operational rhythm.
A strong aesthetic is most convincing when the plumbing beneath it is equally serious.
The best product decision was subtractive: removing complexity the business did not need.
Outcomes and Scale
ConfigEnvironment-based (dev/test/production)
BackendMVC pattern (controllers/, services/, routes/, middleware/)
Secretsdocs/SECRET_ROTATION_RUNBOOK.md
Databasedocs/DB_SCHEMA_OVERVIEW.md
FrontendPage-based routing with component co-location
Deploymentdocs/CLEAN_DEPLOY_WORKFLOW.md
Technical MapREADME_CLEAN.md
Total Commits156 over 4 months (~1.3 per day average)
18 Backend Packages (CoreExpress, pg, bcryptjs, stripe, openai, nodemailer)
43 Frontend Packages (CoreReact, Router, Axios, Framer Motion)
Latest Work
Latest evolution
Payment Integration & SMS Stack Iterations (Nov 25-Dec 9, 2025) - 14 days
Commits: 76-119 Theme: Monetization and multi-channel notifications Stripe Payment Integration (Major effort, Nov 25-Dec 5): - Nov 25 (12:08:01): Step 1 - Client utility + databas…
Historical phase
Admin Assistant with LLM (Jan 20 - Jan 25, 2026) - 6 days
Commits: 120-136 Theme: AI pivot from frontend (hairstyle generation) to backend (data assistant) Architecture Journey: 1. Jan 20 (11:11-11:21): Backend scaffolding - assistantSaf…
Historical phase
Full Platform Hardening & DigitalOcean Migration (Feb 17 - Mar 11, 2026) - 23 days
Commits: 137-156 Theme: Production readiness, infrastructure migration, visual redesign Production Stabilization (Feb 17-18): - Feb 17 (11:43): Schema stabilization - Finalized au…
Historical phase
Next Improvements
- Tighten analytics, rebooking flows, and customer retention features.
- Make service and staff operations even easier for a small team to manage without support overhead.
- Continue simplifying the operational stack wherever it reduces fragility.
Evidence Appendix
Curated narrative summary
Production website for a local barbershop in Jersey City. Designed a portrait-driven editorial layout with Framer Motion animations, team portraits, and neighborhood backgrounds. Managed the full project lifecycle from design through deployment and ongoing maintenance. What this demonstrates: Frontend design sense, Framer Motion animatio…
Repo history executive summary
The Balkan Barbers project evolved from an initial AI-enhanced barbershop prototype into a production-ready booking platform with sophisticated features. The journey reveals a typical SaaS product development arc: bold…
Full Platform Hardening & DigitalOcean Migration (Feb 17 - Mar 11, 2026) - 23 days
Commits: 137-156 Theme: Production readiness, infrastructure migration, visual redesign Production Stabilization (Feb 17-18): - Feb 17 (11:43): Schema stabilization - Finalized auth flows, notification routing, deployme…
Technical stack evidence
React 18.2.0 with Context API for auth state, React Router DOM 7.9.5, Plain CSS with organized design-system.css + page-specific .css files, Charcoal/Brown/Gold (luxury barbershop aesthetic), Font sizes increased Nov 24 for accessibility, Custom-built (no Material-UI or similar), RescheduleModal.js, BarberSelection.js
Demo