Med4You.
From MVP
to a live product.
The first production version was built in 12 working days. Then came two further development phases: iteration after real usage and product scaling. The relationship continues, because nobody has to relearn the context from scratch.
The 12 days refer to the first product version. The following numbers are separate development phases, each counted on its own.
Kasia is an aesthetic medicine doctor. Like hundreds of other specialists in Poland, she kept treatment documentation and patient photos on her own phone. Every new patient, a new folder. iOS notes, GDPR-sensitive data scattered everywhere, and comparing effects after a year was impossible without manual scrolling.
Together with Tomasz, the business and technical co-founder, they decided to solve it. That is how Med4You was born: a SaaS product for aesthetic medicine treatment documentation.
They came to me with a vague idea and one question: can this be built?
That was a few months ago. Today the project is in its third development phase.
The first product version in 12 working days.
Challenge #1: separating doctor and patient roles.
A doctor must be able to create a patient record even when the patient has no account in the application. But if the patient later decides to log in, their history must attach to them. Doctor and patient can edit the same profile, but their entries must be visually distinct and sharing permissions must be controlled.
The entire database architecture and permissions logic rest on this separation.
The doctor writes. The patient gets their own version.
Challenge #2: medical photos under GDPR.
Every photo has EXIF metadata (location, device), requires encryption, labeling (processing purpose) and a publication policy. A botox-treatment photo cannot leave the clinic without consent. A photo for the clinic portfolio is a completely different mode. Everything is aligned with GDPR Articles 6 and 9 (medical data).
Every photo is medical documentation.
What I did.
I designed a PRD with 28 functional requirements and a full set of non-functional requirements. I built a clickable prototype with the complete application design before writing the first line of code. We walked through it with the client and caught nuances that would otherwise have surfaced halfway through the build.
Auth, roles and permissions
- Registration and onboarding
- Health interview
- Supabase RLS and access policies
Patients and visits
- Patient management
- Treatment templates
- Visit form
Photos, comparison tool and sharing
- Upload, compression and EXIF
- Before/after comparison tool
- Patient module + record sharing
Reports, export and doctor panel
- PDF report generation
- Export and PL/EN localization
- Notifications
GDPR and deployment
- GDPR compliance
- Photo policies
- Production deployment
Stack chosen for the problem
From an empty record to effect comparison.
After 12 days they had a working first product version, ready to use and to keep learning from real data. We kept working together in the next phases.
I feel you are a bit of an owner of this product, and I appreciate it. It really sets you apart. A great mix.
Iteration, from MVP to live product.
Kasia and Tomasz came back after two weeks with a list of changes based on real feedback from users who had started using the application.
The second phase was another 18 working days of work. The scope covered 18 new features and improvements:
Lower barrier to entry
- Consultation as a simplified visit type
- Password reset with cross-role verification
- Small UX fixes reported by users
- Reminders about next treatments
Deeper medical record
- Two-sided notebook, doctor and patient in one thread
- Profile photos (front, side, semi-profile) with comparison tool
- Vision defect with versioned history
- Complications with a catalog
First scope extension
- New visit category, Dental
- Location and dose for every injectable treatment
A visit recorded by the specialist.
The patient adds their own context.
After phase II, the product grew from 28 features to ~46. Those additional 18 working days cost a fraction of the original budget, because the prototype and phase-one architecture were ready for it.
This is how I check whether an MVP was built well:
whether it can keep growing after deployment without a rewrite from scratch.
Scaling: AI, GDPR and desktop.
The third phase, currently being implemented, adds another +24 working daysof development. It touches three dimensions at once.
AI reads a prescription → the “vision defect” field fills itself.
AI features inside the product
- Reading a prescription / optical form from a photo
- Reading medical documentation from PDFs and galleries
- Recognizing product labels (name + LOT)
- Assisted visit entry from paper forms
- Analysis of patient and doctor notes
Advanced legal compliance
- On-screen signature authorization + timestamped PDF
- SMS consent flow with 3 reminders and auto-deletion
Dynamic specialization modules
- Aesthetic / Cosmetic / Dental, selected during onboarding
- Each module activates its own fields and terminology
- Scaling toward further specializations without rewriting the core
- Desktop version planned
Today it is a product with three specialization types, AI modules, GDPR compliance and its own design, with a plan to scale into further medical specializations.
I treat medical data like medical data.
- 01Discovery and PRDVague idea → 28 concrete functional and non-functional requirements.
- 02Full application designAll screens, flows, color system and components before the first line of code.
- 03Clickable prototypeThe client sees what will be built before everything enters the build phase.
- 04Architecture and codeStack chosen for the problem. Frontend, backend, database.
- 05Security and GDPRArticles 6 and 9, Supabase RLS, photo encryption and sharing policies.
- 06Production deploymentCI/CD, environments and Playwright E2E tests.
- 07Iteration based on feedbackIn the second and third phases I led the product’s development.
- 08AI in the productDesign and implementation of LLM-powered features, from prescriptions to note analysis.
- 09Marketing materialsCopy, landing page proposals and product presentation formats.
No handovers between PM, analyst, designer and developer. One person who has known the product from day one; every next iteration is cheaper and faster because nobody has to relearn the context.
Med4You is currently in stealth mode, before public launch.
The founders have a working GDPR-compliant product, with architecture ready for scaling and further development with any team. There is a plan to expand into additional medical specializations.
After the MVP, the collaboration continues and picks up pace.