Skip to content
Enterprise telehealth platformiOS + Android + Web + Tablet

How much does it cost to build an app like Amwell?

Estimated US development cost, the features and surfaces involved, the team and timeline it takes, the infrastructure it needs at scale, and what it costs to run once it is live.

A telehealth platform sold to health systems, insurers and employers rather than directly to patients. The buying organisation configures its own branded virtual care service, staffs it with its own clinicians or a supplied network, and embeds it in existing patient channels. The product is a configurable platform first and an app second.

What this build involves

Enterprise telehealth platform
Features listed
32
Sides served
4
Industry
Healthcare
Sensitivity
5/5

The calculator returns

Cost rangeEngineering hoursTimelineTeam compositionRunning costs
Price a build like this

It is not one app — it is 4

The most common reason a budget for something like this comes in low is counting one application when the product needs several, plus the shared platform underneath that nobody sees.

Applications people use — 4

  1. Patient experience

    iOS · Android · Web

    Patients of the buying organisation

    Branded intake, waiting room and visit, embedded in the customer's own channels.

  2. Clinician workstation

    Web · Desktop

    Employed and network clinicians

    Multi-customer queue, charting, prescribing, escalation and documentation.

  3. Clinical cart & device mode

    Tablet

    Hospital rooms and remote sites

    Fixed-position tablet or cart endpoints with peripherals and always-on presence.

  4. Customer configuration console

    Web

    Health system administrators

    Branding, service lines, routing, users, reporting. The product's real differentiator.

Shared platform underneath — 9

  • Backend & API

    The shared data model, business rules and the API every side reads and writes through. Built once, and the single largest line in almost every estimate.

  • Identity & permissions

    Sign-in, sessions, second factors and a role model enforced on the server. Multi-sided products need one identity system that understands several kinds of user.

  • Notification system

    Templating, preferences, delivery across push, email and SMS, retries, and the suppression rules that stop a product becoming spam.

  • Real-time transport

    Persistent connections, presence, fan-out and reconnection. A separate scaling problem from the request/response API, with its own capacity model.

  • Media pipeline

    Upload, transcode, storage, delivery and the CDN in front of it. Egress is usually the largest single running cost in a media product.

  • AI services & governance

    Model access, retrieval over your own content, evaluation and guardrails. The governance half is the part that gets cut and then rebuilt after an incident.

  • Admin & operations console

    Where your own staff fix what customers cannot: account issues, refunds, overrides, escalations. Consistently underbudgeted, and consistently the reason support costs balloon.

  • Analytics & reporting

    Event instrumentation, a warehouse and the dashboards the business actually runs on. Retrofitting instrumentation costs several times what building it in does.

  • Infrastructure & delivery

    Environments, pipelines, secrets, monitoring, alerting and on-call. The work that makes everything above deployable more than once a month.

What has to be built

Split by the phase each capability realistically lands in. The MVP column is priced as its own configuration above, so the split is a real costing decision rather than a diagram.

MVP features

12

The smallest set that is still this product.

  • Email & password sign-in
  • Enterprise SSO (SAML / OIDC)
  • Roles & permissions
  • Consent & authorisation records
  • Video calling
  • Availability & booking calendar
  • Compliant secure messaging
  • Documents & file handling
  • Audit logging
  • White-labelling & theming
  • Push notifications
  • Admin console

Advanced features

10

What a credible competitor is expected to have.

  • Waitlists & overbooking
  • Approval workflows
  • E-signature
  • Dashboards & reporting
  • Notification centre
  • Multi-language support
  • Accessibility (WCAG 2.2 AA)
  • Organisations & team accounts
  • Search, filters & sorting
  • SMS notifications

Enterprise features

10

Scale, governance and the work nobody demos.

  • Self-service report builder
  • Scheduled exports & feeds
  • Public API & webhooks
  • Feature flags & remote config
  • Data warehouse pipeline
  • Speech-to-text & voice
  • Text generation & summarisation
  • AI evaluation & guardrails
  • Support tooling
  • Anomaly detection

The same features, by who uses them

Customer experience

What the people you are building for actually touch.

  • Email & password sign-in
  • Enterprise SSO (SAML / OIDC)
  • Roles & permissions
  • Consent & authorisation records
  • Documents & file handling
  • Audit logging
  • E-signature
  • Organisations & team accounts

Communication

How the product reaches people and how they reach each other.

  • Video calling
  • Compliant secure messaging
  • Push notifications
  • Notification centre
  • SMS notifications

Operations & staff

The consoles your own team lives in. Rarely demoed, always needed.

  • Availability & booking calendar
  • Admin console
  • Waitlists & overbooking
  • Approval workflows
  • Support tooling

Data & intelligence

Reporting, analysis and anything model-driven.

  • Dashboards & reporting
  • Search, filters & sorting
  • Self-service report builder
  • Scheduled exports & feeds
  • Data warehouse pipeline
  • Speech-to-text & voice
  • Text generation & summarisation
  • AI evaluation & guardrails
  • Anomaly detection

Platform

The cross-cutting obligations — access, languages, configuration.

  • White-labelling & theming
  • Multi-language support
  • Accessibility (WCAG 2.2 AA)
  • Public API & webhooks
  • Feature flags & remote config

Technology a build like this would use

Derived from the platforms and capabilities above.

These are typical choices for building a product of this shape today. They are derived from the platforms and capabilities described above — not a claim about what Amwell actually runs on. We do not publish other companies’ internal technology, and you should be sceptical of anyone who does.

Mobile

  • React Native or Flutter (one codebase)
  • Swift / SwiftUI (native iOS)
  • Kotlin / Jetpack Compose (native Android)

Two native codebases buy platform fidelity and cost roughly 66–70% more on the client than one shared codebase. Cross-platform is the default unless a specific capability forces native.

Web

  • TypeScript
  • React with Next.js
  • Tailwind CSS or a component library

Server rendering matters here if the pages need to be indexed; if the web surface is an authenticated console only, it does not.

Tablet

  • The mobile codebase with genuinely adaptive layouts
  • iPadOS multitasking and pointer support

A tablet app is not a phone app with more padding. Budget for a distinct layout and interaction pass, plus its own device test matrix.

Backend

  • Node.js or Go for the real-time edge
  • Python or Java for domain services
  • gRPC or REST between services

A real-time product usually ends up with two server profiles: a connection-handling tier tuned for many idle sockets, and a conventional application tier behind it.

Data

  • PostgreSQL (primary transactional store)
  • Redis (cache, sessions, queues)
  • Snowflake or BigQuery (analytics warehouse)

One relational database plus a cache covers more products than teams expect. Add a specialist store when a real query pattern demands it, not in anticipation.

Cloud & delivery

  • AWS, Google Cloud or Azure
  • Containers on a managed orchestrator
  • Terraform or equivalent for infrastructure as code
  • GitHub Actions or similar for CI/CD

The architecture tier this product needs is driven by traffic, not preference — see the scale section below.

Messaging & notifications

  • APNs and FCM for push, usually via a delivery service
  • Twilio for SMS and voice
  • SES, SendGrid or Resend for email

Deliverability is an operational discipline: warm-up, domain authentication, bounce handling and suppression lists. It is not solved by picking a vendor.

Video

  • LiveKit, Daily or Agora for real-time calls
  • WebRTC directly if you have the expertise

Building video transport in-house is a multi-year specialism. Buy the transport; spend your engineering on the product around it.

AI

  • A hosted model provider (Anthropic, OpenAI) or Bedrock
  • Prompt and context management
  • Evaluation harness and output guardrails

Token cost scales with usage, so unit economics need modelling before launch. The evaluation and guardrail layer is what separates a demo from a product.

Observability

  • Sentry for errors
  • Datadog, Grafana or an equivalent for metrics and traces
  • Structured logging with retention matched to your compliance regime

Instrumentation is cheapest when added during the build. Retrofitting it after the first production incident costs several times more.

How an app like Amwell works

Because each customer runs its own branded instance, nearly every user-visible element is configuration: branding, service lines, intake questions, routing rules, consent text, pricing and which clinician pool answers. That multiplies the engineering surface — every feature must work under every combination a customer can select — and it moves cost from building screens to building the configuration system, the deployment model and the tooling that lets an implementation team stand up a new customer without writing code.

In costing terms that shape matters more than the feature count. A workflow / operations in healthcare inherits obligations before anyone designs a screen — this sector rates 5 out of 5 for regulatory and procurement difficulty on this site, and that rating is what drives the security posture, the audit work and the integration surface any estimate has to carry.

MVP versus the full product

A first version of this is a materially smaller build than the mature product, and the calculator will show you by how much. It gets there by shipping fewer features, on fewer surfaces, at a launch-sized audience rather than the traffic the mature product carries.

What it does not cut is compliance. A regulated product is regulated from its first user, so the primary regime stays in the MVP even though almost everything else is deferred. Teams that defer it discover that retrofitting audit logging, access control and data retention costs several times what building them in would have.

Monetisation

How products of this shape make money

  • Platform licensing to health systems and plans
  • Per-visit or per-member fees
  • Implementation and integration services
  • Clinician network supply fees

Generic to the category, not a description of Amwell’s commercial arrangements.

What these numbers are, and are not

This page carries no figures deliberately. What it sets out is the shape of the build — the sides, the tiers, the stack, the compliance — because that is what an estimate is derived from and what you can check. The calculator turns your own version of that shape into a planning estimate with a stated confidence band; use it to decide the order of magnitude, then spend two to four weeks on a technical specification and get a real quote against that document.

Nothing here is a statement about Amwell as a company. We do not know and do not publish what any business spent building its product, what it earns, how many people it employs, or what technology it runs on. What we describe is the product shape any user can observe — the surfaces it presents, the roles it serves, the capabilities it evidently has — and what building that shape would cost in the United States today.

Building an app like Amwell, answered

How much does it cost to build an app like Amwell?

There is no one figure, because "an app like Amwell" covers three very different builds: a first version with only the essential features, a complete and credible competitor, and a rebuild of everything the mature product does at the traffic it carries. Those are several-fold apart. What this page gives you is the shape of each — the sides, the feature tiers, the stack and the compliance — and the calculator turns whichever one you actually mean into a cost range, hours and a timeline.

Why is an app like Amwell more expensive than a typical app?

Because it is not one app. It is 4 separate applications — patient experience, clinician workstation, clinical cart & device mode, customer configuration console — sharing one backend, each with its own design, release cycle and test matrix. Most quotes that come in low have counted one of them. Configuration is the product: Multi-tenant configurability of branding, workflow, routing and consent is where the engineering goes. Each new toggle multiplies the test matrix, and there is no shortcut — customers buy precisely because they can differ.

Could I build a cheaper version first?

Yes, and you should. A first version ships the essential feature tier rather than all three, on fewer surfaces, at a launch-sized audience — materially less than the full product, and the calculator will show you by how much. What it does not cut is compliance: healthcare obligations apply from the first user, so those stay in whatever else is deferred.

How long would it take to build?

It depends on the same three things the cost does — which tier of the product you mean, how many surfaces you ship, and how settled the scope is. The calculator returns a timeline alongside the cost, derived the same way: hours divided across a realistic team shape, never a target date worked backwards from.

What does it cost to run once it is live?

Cloud infrastructure, third-party services and annual maintenance, and the calculator reports all three separately from the build. They are kept out of the build figure deliberately: they are operating expenditure rather than capital, and adding the two together produces a number that means nothing. Maintenance in particular is not optional — an app that receives none stops working within about a year as OS releases and SDK deprecations accumulate.

Are these real figures for Amwell?

This page carries no figures at all, and nobody outside the company has real ones. What it describes is the product SHAPE, observed from what any user can see — the sides, the feature tiers, the stack, the compliance. Nothing here describes what Amwell actually spent, earns, employs or runs on. The calculator prices building something of that shape today, for the United States market, at our own blended delivery rate.

Does my healthcare app need to be HIPAA compliant?

Only if you handle protected health information as a covered entity or on behalf of one. A fitness tracker you sell directly to consumers generally is not in scope. A patient portal for a clinic, an app a provider gives to patients, or anything where you sign a business associate agreement absolutely is. The distinction is about your relationship with the provider, not the type of data — and it should be settled before you design your data model, because retrofitting HIPAA controls costs several times what building with them costs.

What does EHR integration actually cost?

A single HL7 v2 interface through an integration engine is $30,000–$70,000. A FHIR R4 API layer is $45,000–$90,000. An Epic or Oracle Health app-program integration runs $60,000–$160,000 and is gated by their onboarding and review timeline rather than your engineering speed, so it belongs on the critical path from day one. Read-only access is dramatically cheaper than write-back, and starting read-only is usually the right call.

Price your own build, not Amwell's

Every control on one page, a live spec sheet beside it, and nothing behind a form.