Med4You.
Od MVP
do żywego produktu.
Trzy fazy współpracy. Ponad 50 funkcjonalności wdrożonych. Sześć modułów AI w drodze. Relacja, która trwa, bo nikt nie musi się od nowa uczyć kontekstu.
Kasia jest lekarzem medycyny estetycznej. Jak setki innych specjalistów w Polsce, dokumentację zabiegów i zdjęcia pacjentów trzymała na własnym telefonie. Każdy nowy pacjent, nowy folder. Notatki w iOS, dane RODO rozsiane gdzie popadnie, porównanie efektów po roku, niemożliwe bez ręcznego scrollowania.
Razem z Tomaszem, co-founderem od strony biznesowo-technicznej, postanowili to rozwiązać. Tak powstał Med4You, SaaS do dokumentacji zabiegów medycyny estetycznej.
Przyszli do mnie z mglistym pomysłem i pytaniem: czy da się to zbudować?
To było kilka miesięcy temu. Dziś projekt jest w trzeciej fazie rozwoju.
MVP w 12 dniach roboczych.
Wyzwanie #1, rozdzielenie ról lekarz/pacjent.
Lekarz musi móc założyć kartę pacjenta nawet wtedy, gdy pacjent nie zakłada konta w aplikacji. Ale gdy pacjent kiedyś zechce się zalogować, jego historia musi do niego dołączyć. Lekarz i pacjent mogą edytować ten sam profil, ale ich wpisy muszą być wizualnie odróżnialne, a uprawnienia do udostępniania, kontrolowane.
To brzmi jak detal. W praktyce to fundament całej architektury bazy i logiki uprawnień.
Wyzwanie #2, zdjęcia medyczne pod RODO.
Każde zdjęcie ma EXIF (lokalizacja, urządzenie), wymaga szyfrowania, etykietowania (cel przetwarzania), polityki publikacji. Zdjęcie z zabiegu botoksu nie może wyjść poza klinikę bez zgody. Zdjęcie do portfolio kliniki, to zupełnie inny tryb. Wszystko zgodne z Art. 6 i Art. 9 RODO (dane medyczne).
Co zrobiłem.
Zaprojektowałem PRD z 28 wymaganiami funkcjonalnymi i kompletem wymagań niefunkcjonalnych. Zbudowałem klikalny prototyp z pełnym designem aplikacji zanim napisałem pierwszą linijkę kodu, przeszliśmy przez niego z klientem, wyłapaliśmy niuanse, które bez tego wyszłyby w połowie buildu.
Auth, role i uprawnienia
- Rejestracja, onboarding
- Wywiad zdrowotny
- RLS w Supabase, polityki dostępu
Pacjenci i wizyty
- Zarządzanie pacjentami
- Szablony zabiegów
- Formularz wizyty
Zdjęcia, porównywarka, udostępnianie
- Upload, kompresja, EXIF
- Porównywarka przed/po
- Moduł pacjenta + share karty
Raporty, eksport, panel lekarza
- Generowanie raportów PDF
- Eksport, lokalizacja PL/EN
- Powiadomienia
RODO i deployment
- Zgodność RODO
- Polityki zdjęć
- Deployment produkcyjny
Stack, wybór pod problem, nie pod CV
Po 12 dniach mieli działający produkt. Co zwykle dzieje się z MVP w tym momencie? Klient idzie do software house’u skalować, znika, lub deweloper kończy projekt i przechodzi do kolejnego. Tu stało się coś innego.
Czuję, że jesteś trochę ownerem tego produktu i doceniam. To Cię zresztą bardzo wyróżnia. Zajebisty mix.
Iteracja, od MVP do żywego produktu.
Kasia i Tomasz wrócili po dwóch tygodniach z listą zmian. Nie z claimów, że „coś nie działa”, z realnym feedbackiem od użytkowników, którzy zaczęli z aplikacji korzystać.
Druga faza objęła 18 nowych funkcjonalności i poprawek:
Niższy próg wejścia
- Konsultacja jako uproszczony typ wizyty
- Resetowanie hasła z weryfikacją cross-role
- Drobne poprawki UX zgłaszane przez użytkowników
- Przypomnienia o kolejnych zabiegach
Pogłębienie kartoteki
- Notatnik dwustronny, lekarz i pacjent w jednym wątku
- Zdjęcia profilowe (front, profil, półprofil) z porównywarką
- Wada wzroku z wersjonowaniem historii
- Powikłania z katalogiem
Pierwsze rozszerzenie zakresu
- Nowa kategoria wizyt, Dental
- Lokalizacja i dawka dla każdego zabiegu igłowego
Od MVP do tego momentu produkt urósł z 28 funkcji do ~46. Iteracja kosztowała ułamek pierwotnego budżetu, bo prototyp i architektura z fazy pierwszej były na to przygotowane.
To jest test, którego MVP nie zalicza:
czy po wdrożeniu da się dalej pracować bez przepisywania od zera.
Skalowanie: AI, RODO, desktop.
Trzecia faza, aktualnie w trakcie wdrożenia, dotyka trzech wymiarów jednocześnie.
Funkcje AI w produkcie
- Odczyt recepty / blankietu optycznego ze zdjęcia
- Odczyt dokumentacji medycznej z PDF i galerii
- Rozpoznawanie naklejki preparatu (nazwa + LOT)
- Wspomaganie wypełniania wizyt z formularza papierowego
- Analiza notatek pacjenta i lekarza
Zaawansowana zgodność prawna
- Autoryzacja podpisem na ekranie + PDF z timestampem
- SMS-owy flow zgody z 3 przypomnieniami i auto-usuwaniem
Dynamiczne moduły specjalizacji
- Estetic / Cosmetic / Dental, wybór przy onboardingu
- Każdy moduł aktywuje swój zestaw pól i terminologii
- Skalowanie w stronę kolejnych specjalizacji bez przepisywania core’u
- Wersja desktopowa, w planach
To nie jest już „MVP”. To produkt z trzema typami specjalizacji, modułami AI, RODO compliance i własnym designem. Z planem skalowania w kolejnych specjalizacjach medycznych.
Dane medyczne traktuję jak dane medyczne.
- 01Discovery i PRDMglisty pomysł → 28 konkretnych wymagań funkcjonalnych + niefunkcjonalnych.
- 02Design całej aplikacjiWszystkie ekrany, przepływy, system kolorów i komponenty, przed pierwszą linijką kodu.
- 03Klikalny prototypKlient widzi co powstaje, zanim wszystko wjedzie w build.
- 04Architektura i kodWybór stacku pod problem, nie pod CV. Frontend, backend, baza.
- 05Bezpieczeństwo i RODOArt. 6 i 9, RLS w Supabase, szyfrowanie zdjęć, polityki udostępniania.
- 06Wdrożenie produkcyjneCI/CD, środowiska, testy E2E w Playwright.
- 07Iteracja na bazie feedbackuDruga i trzecia faza, to nie był „support”, to było prowadzenie produktu.
- 08AI w produkcieProjekt i wdrożenie funkcji wykorzystujących LLM, od recepty po analizę notatek.
- 09Materiały marketingoweTeksty, propozycje landing page’a, formy prezentacji produktu.
Bez przekazywania między PM, analitykiem, designerem, developerem. Jedna osoba, która zna ten produkt od pierwszego dnia, każda kolejna iteracja jest tańsza i szybsza, bo nikt nie musi się od nowa uczyć kontekstu.
Med4You jest dziś w stealth mode, przed publicznym launchem.
Founderzy mają działający produkt zgodny z RODO, z architekturą gotową na skalowanie i rozwijanie z dowolnym zespołem. Plan rozszerzania na kolejne specjalizacje medyczne.
Po MVP relacja się nie kończy, tylko przyspiesza.