Context
Eter is a personal startup project for doctors and medical practices. It combines patient administration, evolving medical records, appointments, staff permissions, documents and subscription management in a tenant-aware product.
The team has direct access to medical professionals, including a hospital medical director and a physician in the founding team’s close network. Their feedback informs workflows, but it is not presented as formal clinical validation.
The operational problem
Many doctors still manage records with paper and Word documents. Patient history becomes fragmented, appointments require manual coordination and context is difficult to carry consistently across consultations and practices.
Starting without a client also created a product challenge: the team had to build requirements from zero, then revisit early assumptions as medical professionals described how work actually happens.
Tenants, practices and roles
Each tenant owns its practices, users, doctors, patients, consultations, records, documents, configuration, plan and enabled modules. Within that boundary, assistants and receptionists receive limited permissions appropriate to their work.
This structure is designed to support individual practices first and grow toward clinics with deeper staff and organizational controls.
Solution
Eter centralizes the doctor’s clinical and administrative workflow while preserving a longitudinal record for each patient. Every new consultation contributes to the patient’s history without discarding the context doctors need across visits.
The product includes specialty-based templates, customizable templates, prescriptions, attachments, studies, appointments, staff permissions, practice configuration, subscriptions and financial tracking by consultation.
Product flow
- Enter the selected medical practice with the appropriate role.
- Find or register a patient.
- Start a consultation using a specialty template.
- Add observations, notes, prescriptions and documents.
- Close the consultation and update the longitudinal record.
- Coordinate future appointments and access according to staff permissions.
Architecture
The relational foundation models tenant, practice, subscription package and enabled modules before clinical entities. Doctors, staff, patients, appointments, consultations, records, documents and financial records remain inside that ownership chain.
Supabase, PostgreSQL and Prisma support the data layer; Cloudflare R2 stores documents. Google Calendar is part of appointment synchronization, while Meta / WhatsApp is planned for operational appointment assistance.
Key technical decisions
- Place tenant ownership on every clinical and administrative path, not only on users.
- Treat the patient record as a longitudinal result of consultations rather than a static document.
- Keep modules and subscription packages configurable so practices can evolve without separate deployments.
- Separate professional decision-making from future AI support and preserve the doctor’s judgment.
- Use synthetic data for every public demo and screenshot.
My contribution
I lead the project technically and built approximately 90% of the backend, including the multi-tenant and modular database foundation. I designed the data architecture, defined responsibilities and coordinated parts of the implementation with the team.
Main challenge
The hardest part was turning an internally initiated product into grounded requirements. Every round of medical workflow feedback exposed assumptions that needed to become clearer data, permissions or flows.
Outcome and current state
Eter is a SaaS product in development. It has a multi-tenant backend and evolving clinical workflow, but it is not presented as clinically validated or as a mature production system.
A future assistant may help doctors query existing patient context as decision support. It is intended as clinical support and does not replace professional judgment.
What I learned
Eter expanded my understanding of SaaS architecture, subscription flows, payment gateways, configurable modules and the importance of domain discovery.
What I would change
I would begin workflow interviews and domain research on day one instead of designing from assumptions and validating later.
Roadmap
The next stage expands from individual practices toward clinics with deeper administrative, staff and organizational controls, followed by carefully bounded decision-support capabilities.
Interface gallery
The final gallery requires synthetic-data views for the doctor dashboard, patients, longitudinal record, consultation, template, prescription, agenda, documents, practice configuration and permissions.
Demo walkthrough
The recorded demo presents the current product experience and complements the clinical workflow described in this case study. Before final publication, every visible record must be confirmed as fully synthetic.
Source and safety
The source is private because Eter is a commercial product in development. No public asset may contain real medical information; videos and screenshots must use an isolated synthetic dataset.