The problem and the scope
Checking services and availability through WhatsApp interrupts appointments and scatters information. Tymee brings client choices and professional scheduling into one web application, accessible on phones and computers.
My contribution
Tymee is the project I develop with AI assistance. My contribution spans the interface and application flows, including bookings and business management. AI participates in writing the code; I direct the project and take responsibility for what I present here. The implementation is also an opportunity to study a web application with persistent data and business rules.
Implemented flows
Booking through a public link
Choose one or more services, a date and a time; clients provide their name and phone number without creating an account to book.
Professional workflow
Configure services, team members and working hours; manage schedules, status changes, availability blocks and recurring appointments.
Access and persistent data
Professional accounts with email and password, email verification and account recovery. Clients, services and bookings are stored in PostgreSQL.
Management and communication
Client records and financial tracking. Prepared messages open in WhatsApp for the professional to send manually. Subscriptions integrate with Stripe.
Technologies and their roles
Next.js · React · TypeScript
Bring the interface and server routes into one web application; types help organize data between screens and rules.
Tailwind CSS · React Hook Form · Zod
Styling, form state and input validation, including data submitted through the public booking flow.
PostgreSQL · Drizzle ORM
Relational storage for professionals, services and appointments, with typed queries and transactions.
Better Auth · Resend · Stripe
Professional authentication, transactional email and subscription billing. Deployment uses Railway, with separate staging and production environments.
Two decisions visible in the code
Availability is checked again on the server
Bookings are created in a PostgreSQL transaction with locks and a fresh check of time, professional and overlapping appointments. An idempotency key handles repeated submissions. This avoids relying only on the time slot displayed on screen.
Operations use a professional context
The session and team membership define the professional being accessed. Queries filter by professionalId and team-member permissions are checked. The application associates clients, services and bookings with the business context, rather than relying only on an identifier sent by the interface.
Current state, limits and next steps
- The website is published. Product documentation records early validation and pilot preparation; there are no proven ongoing-use results or metrics to present yet.
- The public simulator demonstrates the interaction but does not make real bookings. The dashboard requires an account and features depend on business configuration.
- WhatsApp uses links containing prepared text; sending remains manual. I do not present this as automated messaging.
- Next steps: complete pilot setup, observe the full workflow, record difficulties and prioritize fixes based on real use.
Technical content checked against project code and documentation in October 2026. Inspecting the public website does not replace full testing of authenticated areas.