Med4You.
From MVP
to a live product.

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.

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.

It sounds like a detail. In practice it is the foundation of the entire database architecture and permissions logic.

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).

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.

After 12 days they had a working first product version, ready to use and to keep learning from real data. What usually happens to an MVP at that point? The client goes to a software house to scale it, disappears, or the developer finishes and moves to the next project. Here, something different happened.

Kasia and Tomasz came back after two weeks with a list of changes. Not vague claims that “something does not work”, but with 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:

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 the test most MVPs fail:
whether you can keep working after deployment without rewriting from scratch.

The third phase, currently being implemented, adds another +24 working daysof development. It touches three dimensions at once.

This is no longer an “MVP”. 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.