Rules in the model
Every business rule is a domain constraint with its own test. If the rule changes, the test fails before the appointment does.
1 domain → N rules · Beauty industry
Skin Studio
Appointments and e-commerce built end to end, with the business rules in the domain
See the live site (opens in a new tab)rules with their own test
Mandatory deposittest ok
Rescheduling windowtest ok
Arrival tolerancetest ok
Break between appointmentstest ok
The problem
Mandatory deposits, rescheduling windows, arrival tolerances and breaks between appointments lived as unspoken team agreements and broke on every exception.
The decision
Model every rule in the domain, not in the interface, each with its own test.
Payments and calendar
A mandatory deposit through MercadoPago before confirming the appointment, and Google Calendar sync so the studio has a single schedule.
Audit and roles
Gift cards, roles and audit logs: who changed which appointment and when, because in a business with deposits that stops being a detail.
The result
Rules verified by tests instead of human judgment, and a site that loads in 2.7 s on a mid-range phone.
94
PageSpeed performance, mobile
80%
Test coverage
4
Critical rules with their own test
Tech sheet
- Role
- Complete product, end to end: interface, domain, backend, payments and deployment.
- Frontend
- Next.js · React + Vite
- Backend
- Django Ninja · PostgreSQL 16 · Redis 7 · Celery
- Integrations
- MercadoPago · Google Calendar
- Testing
- pytest + FactoryBoy, TDD where possible. 80% coverage.
- Performance
- PageSpeed mobile: 94 performance, 96 accessibility, 100 SEO. LCP 2.7 s · CLS 0 · TBT 0 ms (emulated Moto G Power, slow 4G).
- In production
- micaskin.com, on my own VPS
- Client
- Beauty studio. The site is public: micaskin.com.
Next case
Multi-app VPS
A self-hosting pattern, documented and repeatable
Shall we work together?
Let's talk.
I design it, build it end to end and take ownership of keeping it running. Write to me and let's talk. I reply the same day.