New website for a telemedicine clinic with a personal account, online registration and Stripe + Twilio integrations (HIPAA-oriented)

Initial situation: a small telemedicine clinic currently only has a landing page on Tilda without registration or payment. Registration is done manually via email; after payment, the patient is sent a link to a video call. Due to manual operations, applications are lost and there is no normal analytics.

Subject area and goal: to create a new website with a public part and a patient’s personal account, where you can choose a service and a doctor, sign up for free time, pay for a consultation and receive a link to a video session. The administrator must manage scheduling and cancellations. Careful work with personal data, logging of actions and minimizing the storage of sensitive information is required.

Technical environment and limitations:
- Deploy to the customer’s existing AWS account (EC2 or ECS, you can suggest the best option), domain in Route53
- Stack: Next.js 14 (App Router) + TypeScript, PostgreSQL (RDS), Prisma, Docker, Terraform or AWS CDK for infrastructure (partially acceptable, but deployment must be reproducible)
- Authentication: NextAuth or equivalent with email magic link, brute-force protection, rate limiting
- Payment: Stripe Checkout + webhooks, correct processing of payment statuses and repeated events
- Notifications: email (SES) and SMS (Twilio) about registration/transfer/cancellation
- Video communication: generation of a secure link to the session via Twilio Video (without storing recordings)
- Data: do not store medical documents and diagnoses, only visit metadata (service, time, doctor, status, payment). We do not implement any doctor’s notes
- Languages: RU/EN (minimum 6 pages of the public part + account)
- Design: can be based on a ready-made UI kit (for example, shadcn/ui) without unique rendering, but with a single style

Specific result:
- Public site: home, services, doctors, prices, FAQ, contacts, privacy policy
- Patient’s personal account: registration/login, profile, list of visits, creating an entry, canceling/transferring within the rules
- Admin panel (you can have a simple protected section): managing doctors, services, schedules (slots), viewing visits and payment statuses, manual cancellation
- Integrations: Stripe (payment), SES (email), Twilio (SMS and Video), webhooks, event log
- CI/CD: GitHub Actions for build and deployment, .env.example and launch instructions

Execution steps (required):
1) Short technical analysis and data/flow diagram (record-payment-call-notifications) with fixation of assumptions
2) Implementation of MVP registration and payment functions with webhooks and a basic account
3) Adding notifications and integrating video sessions
4) Admin section, testing, stabilization, deployment and documentation

Acceptance criteria (measurable):
- The user can create an entry for a free slot, pay via Stripe, after a successful webhook, the visit status changes to paid in no more than 30 seconds
- SMS and email are sent when creating a record, successful payment, cancellation and transfer (the log of successful sending and errors is available to the administrator)
- The link to Twilio Video is available only to visit participants and is active in the interval: 10 minutes before the start until 60 minutes after the start, then unavailable
- Any access to the account without a session will redirect to the login, all API routes are protected
- At least 15 autotests (unit/integration) for critical scenarios: creating a visit, processing webhook, access rights
- Lighthouse for public pages: Performance no lower than 80 on mobile for the main and services pages (excluding external Stripe scripts at the time of payment)
- Instructions in README: local launch in Docker, applying migrations, setting environment variables, deployment

What I will provide on my part: access to AWS, Stripe/Twilio/SES keys, page texts (drafts) and a list of services/doctors in CSV. There are no design files, careful implementation on ready-made components is allowed.

Important: the project is complex due to the combination of schedules, payments, webhooks, access restrictions and infrastructure. Preference for a solution that can be supported further without magic and manual edits on the server.