Earlier this year, our team at Adamo Software shipped a full-scale healthcare platform for a European startup. The system covers telemedicine consultations, lab and imaging orders, e-prescriptions with a pharmacy bidding mechanism, and family member management across four interconnected portals: Patient, Provider, Pharmacy, and Admin.
This post is not a tutorial. It is a honest breakdown of the decisions we made, the problems we ran into, and what we would do differently. If you are building anything in healthcare, some of this might save you a few weeks of pain.
The Scope (Bigger Than It Looks)
What the client described initially sounded like "a telemedicine app." What we actually built was four separate applications sharing a common backend:
Patient portal allows users to manage family members, dependents, and caregivers under one account. Patients can book consultations (video, home visit, or in-office), order lab tests and imaging based on doctor referrals, and purchase medications through an integrated pharmacy system.
Provider portal serves clinics. Each clinic manages multiple facilities and doctors. Freelancer doctors can either join a facility or offer services independently. The portal handles consultation scheduling, clinical notes, file uploads, and prescription management.
Pharmacy portal receives prescriptions and manages a bidding system where pharmacies compete on pricing. Patients can also request prescription refills.
Admin portal ties everything together with role-based access control across all three user-facing applications.
On top of this, the entire platform had to meet HIPAA compliance standards.
Tech Stack and Why We Chose It
Frontend: ReactJS (web) + React Native (mobile)
Backend: PHP
Database: MySQL
Video: Agora
Payments: Stripe + PayPal
Clinical AI: Isabel AI (diagnostic decision support)
AI features: OpenAI integration
Project management: Jira
The client was a startup. Budget optimization was not a preference, it was a survival constraint. We chose open-source technologies and scalable cloud infrastructure with a serverless model where possible. PHP and MySQL are not trendy, but they are battle-tested, well-documented, and significantly cheaper to maintain than trendier stacks when you need to hire or scale a team quickly.
Agora was chosen for video consultations over building a custom WebRTC implementation. For a startup racing to market, spending three months on video infrastructure would have been reckless. Agora gave us stable, low-latency video with HIPAA-compliant encryption out of the box.
Isabel AI handles clinical decision support, helping doctors cross-reference symptoms against a medical knowledge base during consultations. OpenAI powers additional features like note summarization and patient-facing explanations.
Four Problems That Almost Derailed Us
1. Medical data is wide, deep, and unforgiving
Healthcare data is not like e-commerce data. A single patient record can reference lab results, imaging files, prescriptions, consultation notes, referral chains, insurance information, and family relationships. And every field has clinical implications if it is wrong.
We solved this by designing a modular architecture with clear separation between clinic, lab, imaging, and pharmacy modules. Each module owns its data domain but shares patient identity through a secure central layer. This made the system easier to reason about and significantly easier to extend when the client inevitably asked for new features mid-development.
2. Every clinical action needs expert confirmation, which slows everything down
In healthcare, a doctor writes a prescription, but a pharmacist must verify it. A doctor orders imaging, but a radiologist must confirm appropriateness. A lab result comes back, but a clinician must review it before the patient sees it. These confirmation chains are the core workflow, not an edge case.
We built an automated approval workflow with real-time notifications, audit trails, and role-based confirmation gates. Doctors, specialists, and patients interact within the same platform, and every action is logged and traceable. This reduced the approval bottleneck from days (in the client's previous manual process) to hours.
3. Twelve-hour time zone gap between our team and the client
Our development team is based in Vietnam. The client is in Europe. That is a 5-6 hour gap in winter and the communication window shrinks further with daylight saving changes.
We could not rely on synchronous communication. Instead, we built a semi-automated workflow: daily async standup reports, structured Jira boards with clear acceptance criteria per ticket, and twice-weekly video syncs during the overlap window. The PM owned a daily progress digest that the client received every morning their time.
This is not glamorous, but it works. The key insight is that timezone gaps are not solved by more meetings. They are solved by better documentation and clearer task definitions so that both sides can make progress independently.
4. HIPAA compliance touches everything, not just the database
Most developers think HIPAA means "encrypt the database." It means much more. Audit logging for every data access. Role-based access control that prevents a pharmacy from seeing consultation notes. Encrypted video streams. Secure file uploads for medical images. Consent management. Data retention policies.
We addressed this from architecture, not as an afterthought. Every API endpoint has access control checks. Every data mutation is logged. Video sessions through Agora use end-to-end encryption. File storage uses encrypted-at-rest cloud buckets with signed URLs that expire.
If you are building healthcare software and your HIPAA plan is "we will add encryption later," stop and rethink. Retrofitting compliance into an existing system costs three to five times more than building it in from the start.
Team Structure and Timeline
Total team: 15 members
- 4 ReactJS developers (web)
- 3 React Native developers (mobile)
- 2 PHP backend developers
- 3 QA testers
- 1 Project Manager
- 1 Business Analyst
- 1 UI/UX Designer
Timeline: 8 months for the web application, followed by 5 months for the mobile application.
The BA was critical for this project. Healthcare workflows are not intuitive for developers. Having someone who could translate clinical requirements into technical specifications prevented dozens of misunderstandings that would have become expensive bugs later.
What We Would Do Differently
Start mobile earlier.
We built web first, then mobile. In retrospect, designing the API layer with mobile constraints in mind from day one would have saved rework. Mobile has different data fetching patterns, offline requirements, and UX constraints that affect backend design.
Invest more in the pharmacy bidding logic upfront.
The bidding system where pharmacies compete on prescription pricing was conceptually simple but operationally complex. Edge cases around partial fills, refill pricing, delivery logistics, and payment splits consumed more time than expected. We should have prototyped this module independently before integrating it.
Document clinical workflows visually before writing any code.
We did this partially, but not comprehensively enough. Healthcare has invisible dependencies everywhere. A prescription refill, for example, might require re-verification of the original diagnosis, insurance eligibility check, and pharmacy availability confirmation. Flowcharts for every clinical workflow would have caught integration issues earlier.
Takeaways
If you are building a healthcare platform, here is what I would tell you over coffee:
Modular architecture is not optional. Separate your clinical domains (consult, lab, imaging, pharmacy) cleanly. You will thank yourself when requirements change, and they will change.
HIPAA is an architecture decision, not a feature. Build compliance into your data layer, API layer, and infrastructure from the first commit.
Timezone gaps are a process problem, not a people problem. Invest in async workflows, clear documentation, and structured handoffs.
Choose boring technology for startups. PHP and MySQL are not exciting, but they ship, they scale, and your next hire already knows them.
If this kind of work interests you, we write about healthcare software development on our blog at Adamo Software.
I work at Adamo Software, a software development company that builds healthcare, travel, and AI solutions. This is a real project we delivered. Client details are anonymized per our NDA.
Top comments (0)