A UK healthcare company had 1.5 months to replace a platform a contractor had left behind in pieces. The new system had to handle HD video consultations, let doctors review offline medical forms between calls, manage prescriptions, and connect to multiple third-party clinical tools.
The team they brought in shipped it in 6 weeks.
That kind of delivery doesn't happen through raw speed. It happens because the requirements were tight, specific, and actionable before a single line of code was written. The dev team knew exactly what they were building, why each feature existed, and what "done" meant.
Most founders starting a telemedicine build don't reach that point. They find a guide that hands them a feature checklist ("you'll need video calls, scheduling, EHR integration...") without explaining how to decide what to actually build for their specific use case. Or they spend 3 months in requirements workshops that still leave the dev team asking for clarification every other day.
The part that determines whether you ship in 6 weeks or 9 months happens before the build. How to read the existing market, extract what you actually need, and hand your dev team a brief they can work from.
That's what this guide covers.
What the leading telemedicine platforms actually offer (and what they don't)
You don't need to build everything from scratch. The telemedicine market already has answers to a lot of the questions your product will face, answers that took real engineering time and real customer feedback to develop.
Before you write your first requirement, understand what the existing platforms decided to build, and why.
Here are the 6 platforms that come up most in the market:
| Platform | Best for | Core differentiator | Honest limitation |
|---|---|---|---|
| Doxy.me | Independent practitioners and small clinics | No download required, HIPAA-compliant, free tier available | Limited for multi-provider workflows or complex clinical operations |
| Amwell | Multi-specialty health groups | Deep EHR integration, insurance network partnerships | Enterprise pricing and setup overhead; too heavy for most startups |
| Zoom for Healthcare | Organizations already running on Zoom | Familiar UX with a HIPAA compliance layer | Covers video and compliance only; clinical features require additional platforms |
| VSee | Low-bandwidth and rural environments | Works on slow connections, FDA Class II cleared | Dated interface; limited support for modern feature expectations |
| Mend | Patient engagement-focused practices | Self-scheduling, automated reminders, payment collection | Less clinical depth; not built for complex care workflows |
| SimplePractice | Mental health and behavioral health providers | Notes, billing, scheduling, and video in a single tool | Purpose-built for behavioral health; limited outside that vertical |
Look at the decisions each team made.
Doxy.me solved for accessibility: zero friction, no download, one link. Amwell solved for scale and integration: hospital systems with existing EHRs need a platform that connects cleanly. SimplePractice solved for a specific vertical: therapists who bill insurance and need documentation in the same product. Each platform is a set of product bets about who the user is and what problem matters most to them.
Your job is to figure out which bets are already made, and which ones your use case requires you to make yourself.
How to analyze these platforms as competitors for your own product
Looking at competitor platforms is standard practice. But most founders look at them the wrong way. They catalog features and try to replicate or improve each one. That produces a feature list. A product direction requires a different question.
What you actually want to extract is this: where do these platforms hit the wall for your specific users?
Step 1: Map the functional clusters
Every telemedicine platform, regardless of how it's packaged, handles roughly the same 5 functional areas: scheduling, video communication, clinical records or forms, prescriptions or orders, and billing or payment. The difference between platforms is how deeply they built each one, and what they deliberately left thin.
Go through each of the 6 platforms and score how much they invested in each area. The patterns come through quickly. Doxy.me went deep on video and access, shallow on clinical forms. SimplePractice went deep on documentation and billing, adequate on video. Amwell went deep on integrations and multi-specialty workflows, shallow on ease of onboarding for small teams.
Do the same exercise for your own product. Which areas need to be deep for your users, and which can be adequate?
Step 2: Find the gaps your use case exposes
Every platform has a failure mode. The place where a user's workflow runs into a wall. Read the negative reviews on G2, Capterra, and app stores for the platforms you're comparing against.
One-star reviews are a free requirements document. They describe, in exact user language, what the platform promised and couldn't deliver. "Video drops every 15 minutes on slow rural connections." "Can't issue a prescription without leaving the consultation screen." "Patients can't reschedule without calling the front desk."
If any of those sound like your users' situation, you've found a requirement.
Step 3: Understand who the platform was built for
Each platform has an embedded assumption about who's using it. Doxy.me assumes an independent practitioner with patients technical enough to click a link. Amwell assumes an IT team who can manage integrations. Zoom for Healthcare assumes you already have Zoom at scale and just need compliance on top.
If your users don't match the embedded assumption, the platform won't fit. That mismatch has nothing to do with quality. It was built for a different person.
The output of this analysis
After working through these 3 steps, you'll have 2 lists.
The first: what you're building that already exists in the market and doesn't need reinventing. You can rely on proven approaches, adopt standard patterns, and move quickly through those sections of the build.
The second: what you're building that doesn't exist yet, or exists but fails your users. That's where careful requirements work earns its keep.
How to turn that research into requirements your dev team can act on
This is where most product briefs fall apart. The competitive analysis is done, the enthusiasm is high, and the requirements document ends up as a list of features with no context for why they exist or what "done" means.
Here's how to structure it so your dev team can actually build from it.
Start with user roles, not features
A telemedicine platform typically has 3 user roles: patient, provider, and admin. Before listing a single feature, define what each role needs to accomplish. Write jobs, not features.
A provider needs to: see the patient's history before the consultation starts, run a video call without switching applications, complete a post-visit note, and issue a prescription without leaving the platform.
A patient needs to: book an appointment without calling anyone, join a consultation from any device, and access their prescription or follow-up instructions afterward.
An admin needs to: manage the schedule, see which consultations are running over time, and handle cancellations or rescheduling without manual back-and-forth.
Once these job descriptions are written, features become obvious. The requirements follow from the jobs.
Separate functional from non-functional requirements
Functional requirements describe what the system does. Non-functional requirements describe how it does it.
Most product teams write the functional requirements and forget the non-functional ones. Then the dev team builds a system that technically does everything on the list but drops calls at anything under 10 Mbps, or takes 8 seconds to load the patient history, or can't handle 200 concurrent consultations.
For a telehealth platform, the non-functional requirements that matter most:
- Video quality floor: minimum acceptable call quality at a specified bandwidth (rural users will have slower connections than a city clinic)
- Latency ceiling: maximum acceptable lag for prescription submissions or form saves
- Uptime requirement: what percentage availability does a 24/7 platform need, and what does downtime cost clinically
- Data residency: where patient data must be stored and processed (this changes significantly between UK and US regulations)
Write these down before the build starts. They shape architectural decisions that are expensive to reverse later.
Name your compliance requirements explicitly
"The platform needs to be HIPAA compliant" is not a requirement. It's a category.
What your dev team needs to know: which data flows are regulated, what encryption standard applies to data in transit and at rest, how access control must work, who can see which patient records and under what conditions, and what the audit log needs to capture.
For US-based platforms: HIPAA. For UK-based: NHS digital standards and UK GDPR. For EU markets: GDPR. If your platform spans multiple jurisdictions, name all of them explicitly. Don't leave this for the team to figure out mid-build.
List your integrations before you list your features
If your platform connects to an EHR system, a payment gateway, a lab information system, or a pharmacy network, those integrations determine the architecture. They're constraints that shape everything else, not features that get bolted on later.
A platform integrating with Epic (the most common enterprise EHR in the US) has very different technical requirements than one integrating with a regional system or launching without EHR integration in v1. Name the specific integrations needed in v1, and which ones can wait.
Define what the MVP does not include
Scope expands in the direction of silence. If your requirements doc doesn't say "v1 does not include analytics dashboard, does not include multi-language support, does not include video recording," your dev team will get asked about those features midway through the build.
Write the exclusions. A short "out of scope for v1" section prevents 3 months of scope drift.
The requirements checklist
Before handing off to your dev team, make sure your document covers:
| Area | What to include |
|---|---|
| User roles | What each role needs to accomplish (jobs, not features) |
| Functional requirements | What the system does, organized by role |
| Non-functional requirements | Video quality, latency, uptime, load capacity |
| Compliance standards | Specific regulations by market, with data flow implications |
| Integrations | Named systems, v1 vs. future |
| MVP exclusions | Explicit list of what's not in scope |
| Go-live constraint | Hard deadline, soft target, or "when it's ready" |
A full System Requirements Specification (SRS) document is a more formalized version of this. Your dev team's business analyst will typically produce one from your inputs during the discovery phase. But the clearer your inputs, the faster that process goes, and the more accurate the initial estimate will be.
How Brocoders built CoreHealth's telehealth platform in 6 weeks
CoreHealth has been building telemedicine platforms in the UK since 2006. In mid-2023, their major client needed a doctor consultation platform rebuilt from scratch. The previous contractor had left behind a codebase that was outdated and impossible to integrate with modern tools. CoreHealth gave themselves 1.5 months, no buffer.
The scope was real: HD video consultations, offline medical forms that doctors could review between calls, a prescription module, and multiple third-party integrations live from day one.
Team: 5 people. One frontend developer, one backend developer, one QA engineer, one UI/UX designer, and a project manager. Each owned a defined lane with no overlap.
Before any production code was written, we ran a proper discovery phase. That meant reviewing the entire existing application, mapping every user flow and integration point, and breaking the platform into modules that could be built and tested independently. By the end of discovery, we had Q&A documentation, user story documentation broken down by role, a project estimation with a roadmap, a low-fidelity prototype reviewed with the client, and completed UI/UX design.
That phase is where most timelines are saved or lost. Teams that skip it to start coding faster hit integration blockers mid-build. Fixing those blockers costs more time than the discovery would have taken.
For the stack: React.js on the frontend, Node.js on the backend. The platform needed multiple third-party integrations from day one, and the JavaScript ecosystem is well-suited for API-heavy architectures. We also work with AI-augmented workflows across coding, QA, and CI/CD. Our architects own the structure; AI handles the repetitive implementation work. A 5-person team working this way builds at a pace a larger traditional team often doesn't reach, because coordination overhead drops out of the process.
The build followed from discovery. Video consultation layer first. Prescription workflow second. Offline forms third. Integrations running in parallel.
The platform shipped in 6 weeks.
But that delivery wasn't the end. The architecture we built was designed for the complexity CoreHealth operates in, and it held. Over the following months, the same codebase expanded into 3 distinct telemedicine products:
- Doctor consultation platform: patients book consultations online, browse doctors by specialty, and join real-time video sessions
- SaaS platform for pharmacies: patients consult a licensed doctor by video; approved prescriptions go directly to the pharmacy for collection; patients who don't need a live session can submit a medical form instead
- Healthcare platform for prisons: a secure telemedicine solution running on Samsung Tab A8 tablets, letting prisoners consult healthcare providers from their cells; physical assessments can be conducted remotely via the tablet camera
All 3 share the same core architecture from the original 6-week build.
| Before | After |
|---|---|
| Legacy codebase, unmaintainable | Modern React + Node.js architecture |
| 1.5-month deadline, no buffer | MVP delivered in 6 weeks |
| No external integrations | Multiple third-party integrations live from day one |
| 1 product | 3 telemedicine products on shared architecture |
Read the full CoreHealth case study
What to expect from a dev team: timelines, process, and what you need to bring
The most common source of friction in telemedicine builds is the gap between what founders expected and what the engagement actually looks like.
Timeline and cost benchmarks
These are real ranges based on project complexity:
| Scope | Timeline | Cost range |
|---|---|---|
| Simple MVP (video + scheduling + basic auth) | 2–3 months | $30K–$55K |
| Mid-level platform (video + EHR integration + scheduling + forms + billing) | 4–6 months | $80K–$150K |
| Full clinical platform (prescriptions + multi-provider + analytics included) | 9–12 months | $200K–$350K+ |
EHR integrations are the biggest variable. Connecting to a major system like Epic can add 3–6 months regardless of where you start in the table above. Decide early whether that's a v1 requirement or can wait for v2.
Hourly rates vary significantly by region: $50–$80/hour for Eastern European teams, $120–$200/hour for US and Western European teams. Both can produce high-quality work. The difference is mostly cost and timezone overlap with your team.
Who you'll work with
A standard telemedicine build involves:
- Project manager: your day-to-day contact, owns the timeline and communication
- Business analyst: translates your requirements into dev tasks and writes the SRS
- 2–3 frontend and backend developers: scope and mobile requirements determine the exact number
- QA engineer: testing throughout the build, embedded in each sprint
- DevOps engineer: infrastructure, deployment pipelines, and environment setup
For a US build, a regulatory consultant is worth adding early. Someone who reviews the data architecture against HIPAA requirements before it's built, not after. That review is inexpensive when the code doesn't exist yet. Expensive when it does.
What to bring to the first meeting
If you come to a discovery call with these 5 things, you'll get a proposal that reflects what you actually need:
- A description of your user roles and what each one needs to accomplish
- The 2–3 telemedicine platforms you've looked at, and specifically what didn't work about them for your use case
- Your compliance requirements: US, UK, EU, or multiple markets
- Known integrations, even a preliminary list: EHR systems, payment gateways, labs
- Your go-live constraint: hard deadline, soft target, or no fixed date
You don't need a complete requirements doc. But these 5 inputs cut the discovery process in half and produce estimates that hold up.
The custom software question
The platforms listed earlier are real products built by real teams. If your workflow maps reasonably well to what they offer, use one of them. The economics are hard to argue against for standard use cases.
The case for custom software is specific: when your differentiation lives in the workflow itself, when a generic platform will always require workarounds that frustrate your users or providers, that's when you build. CoreHealth's 24/7 GP access model required clinical workflows and integration requirements that existing off-the-shelf platforms couldn't support cleanly. The decision to build was the right one for that reason, not because building is always better.
The cost of custom software has come down as AI-augmented development teams work faster. That's part of why a 6-week delivery is achievable for a well-scoped project. But the starting assumption should still be: buy before you build, unless you can clearly articulate what the existing market has gotten wrong for your specific use case.
We've built telehealth platforms on tight timelines and tighter requirements. If you're at the requirements stage and want a team that's done this before, start with a conversation.