Odys

Odys is a scheduling SaaS for Brazilian independent professionals across health, fitness, wellness, beauty, education, and creative services — psychologists, personal trainers, hairdressers, estheticians, nutritionists, photographers, and more. It replaces the chaotic WhatsApp-thread-as-agenda pattern most of them use today.

The problem

Most Brazilian independent professionals run their agenda through WhatsApp. A client messages asking for a Friday 3pm slot. The professional confirms manually. Payments happen in separate threads, often forgotten. Reminders are typed by hand. No central calendar, no paper trail, no analytics.

Existing tools (Calendly, Simples Agenda) miss the mark:

• Too complex for a solo professional who just wants a booking page
• Don't speak WhatsApp natively — the actual channel where business happens
• Designed for English-speaking corporate markets, not Brazilian realities (PIX, WhatsApp as primary channel)

What Odys does

• Public booking page at /p/[slug] — clients pick a slot, fill details, done
• AI WhatsApp agent — clients can book appointments autonomously by chatting with Odys on WhatsApp; the agent looks up availability and creates appointments via Groq LLM tool-calling
• Professional dashboard to confirm, track, and manage appointments
• Transactional WhatsApp messages — reminders, confirmations, cancellations, alerts — all delivered from a single corporate Odys number via Evolution API
• Stripe subscription billing for the professional to pay Odys (Basic / Pro / Premium)
• PIX payment flow for client-to-professional payments — Brazilian-native, off-Stripe

Scope of professions supported

29 professions across 6 categories, defined in src/lib/professions.ts:

• Health — psychologist, physiotherapist, nutritionist, dentist, therapist, speech therapist
• Fitness — personal trainer, yoga instructor, pilates instructor, dance instructor
• Wellness — massage therapist, acupuncturist, holistic therapist, osteopath
• Beauty — hairdresser, barber, manicure, esthetician, makeup artist, tattoo artist, eyebrow designer, lash designer
• Education — tutor, music instructor, language instructor, coach
• Creative — photographer, personal stylist, personal organizer

The schema is strictly per-individual-professional — there is no salons table. A salon owner using Odys would onboard each professional individually.

The corporate-number architecture

Unlike earlier designs that connected Evolution to each professional's personal phone, Odys operates one corporate WhatsApp number that handles every interaction:

• Outbound — reminders, confirmations, AI replies, professional alerts — all leave from the corporate number
• Inbound — client and professional messages are routed through /api/whatsapp/webhook to the AI intake agent
• Reply routing — a client replying to a transactional notification is contextualized via a Redis key last_outbound:{phone}, so the AI knows which professional/appointment the reply concerns without asking again
• Conversation-aware delivery — the reminder cron skips a push if the client is mid-conversation with the AI (<15 min idle), avoiding interleaving transactional alerts with in-progress scheduling dialogues

Why this matters: professionals' personal numbers are never exposed to spam risk. Odys controls the brand, the message tone, and the scale path to Meta's WhatsApp Business Cloud API when volume demands it.

Current state (2026-04-23)

• Deployed at odys.com.br — launch-ready
• Zero paying customers yet — pre-launch, by design
• Before the first acquisition push, the product has been hardened: real Drizzle schema, working Stripe + PIX payments, a security audit with 15 findings actively being worked, three-runtime Sentry observability, and an MCP server exposing the DB to AI agents

When a section in these docs says "the system handles X," it means the code is in production and tested end-to-end — but has not yet been load-tested by real traffic.

What's in the rest of these docs

• Architecture — high-level diagram of how the pieces connect
• User Journeys — the 3 flows that define the product
• Frontend — Next.js 16 App Router structure
• Backend — the API route tree
• Database — 10-table Drizzle schema on Supabase Postgres
• Payment — Stripe subscriptions + PIX flow
• AI Layer — Groq + Llama, tool-calling, AI intake agent, dashboard assistant
• MCP Server — local stdio server with 4 tools
• WhatsApp — corporate-number architecture, Evolution API, ~20 message templates
• Observability — Sentry 3-runtime + PostHog
• Deployment — Vercel + Railway + GitHub Actions
• Security — the 15-finding audit, what's fixed, what's open
• Tech Decisions — the "why" behind every major choice
• Lessons Learned — what I'd do differently