How to Build an EHR System: Step-by-Step Guide

Switching an EHR isn’t like switching a mobile app. For a medical facility, it’s a high-friction reset: patient registration edge cases resurface, EHR users lose speed, care coordination gets noisier, and you spend real money training staff back to baseline, all while still protecting patient health information.

That’s why EHR decisions get treated like core infrastructure. In KPMG’s 2025 Healthcare CEO Outlook, 75% of healthcare CEOs call electronic health records “very important” for digital transformation (another 19% say “important”). KPMG’s other point: modernization expands the attack surface, and security has to keep up with it.

If you’re creating an EHR, what follows is the EHR application development picture end-to-end, from data migration to ongoing support. You’ll see how to make an electronic health record system that holds up at scale and stays defensible at audit.

 

Top Takeaways:

• Before you build an EHR system from scratch, see if you can plug into existing EHR data with a lightweight doctor- or patient-facing front end. The integration path is shorter than the green-field build more often than founders expect.
• Once you commit to a full EHR/EMR platform, expect to ship several apps, not one. Role-specific front ends for doctors, patients, and admin staff, with web and mobile variants where the role demands it.
• Rapid prototyping earns its keep in EHR development by matching an EMR system’s features to the way a specific practice actually works, before you spend real engineering money on the wrong workflow.

 

Table of Contents:
1. What’s the Difference Between EMR and EHR
2. Benefits of EHR Systems
3. Ready-Made vs. Custom EHR Solutions
4. Must-Have Features of a Modern EHR System
5. Types of EHR Systems
6. Complete EHR Software Development Roadmap

• Step 1: Establish a Data Migration and Interoperability Plan
• Step 2: Identify Core Modules
• Step 3: Get Key Functional Requirements
• Step 4: Ensure Compliance with Regulatory Standards
• Step 5: Design System Architecture
• Step 6: Choose Technology Stack
• Step 7: Create Custom UI/UX for Clinical Workflows
• Step 8: Integrate APIs and Third-Party Services
• Step 9: Implement Data Security, Encryption, and Backup Measures
• Step 10: Prepare for Launch
• Step 11: Execute Testing and Validate System Functionality
• Step 12: Roll Out in Phases and Train Clinical Staff
• Step 13: Provide Ongoing Support and Continuous Optimization

7. Tech Stack for Building EMR/EHR Software
8. EHR/EMR System Development Cost
9. Topflight’s EHR Development Expertise
10. Selected EHR/EMR Integration Projects

 

What’s the difference between EMR and EHR

People (including plenty of healthcare professionals) use “EMR” and “EHR” interchangeably, and honestly, a lot of EHR/EMR providers like Epic and Cerner don’t help, because they sprinkle both terms across their sites like seasoning.

Still, if you’re building software (or buying it), the distinction is useful: EMR usually describes a record that lives mainly inside one practice, while EHR implies the record is built to travel across organizations and support broader care coordination. Here’s the quick comparison:

Feature	EHR (Electronic Health Record)	EMR (Electronic Medical Record)
Definition	A digital version of a patient’s complete health record accessible by multiple healthcare providers.	A digital record of a patient’s medical history used primarily by a single healthcare provider.
Scope	Covers a broader view of a patient’s health across different settings and providers.	Focused on clinical history within a single practice or organization.
Interoperability	Designed to be interoperable (can share data across systems/providers).	Limited interoperability; often stays within the facility where it was created.
Data sharing	Moves patient data across multiple providers and facilities.	Data sharing is typically restricted to the organization that created the record.
Purpose	Supports continuity of care across the patient journey (multiple touchpoints).	Supports diagnosis and treatment inside one practice’s workflow.
Functionality	Often includes wider datasets (labs, meds, immunizations, history, etc.).	Often centers on diagnoses, treatment plans, and visit notes for that practice.
Patient access	More likely to support patient access via portals and cross-provider experiences.	Patient access is more limited or may be unavailable.

Why this matters for healthcare app development: if you’re building something meant to work across providers (referrals, labs, hospital + clinic handoffs, population health, multi-site networks), you’re in EHR territory, and interoperability expectations come with the job. If you’re optimizing one clinic’s internal workflow, you may be closer to an EMR pattern.

And yes, standards bodies like the ONC have their own definitions and nuance, but for most teams, this “scope + shareability” mental model is the only part that affects real product decisions.

An EHR system, in plain English

An Electronic Health Record (EHR) system is the digital system that holds patient health information and shares it across the care team. The key word is share: an EHR is built to move with the patient across clinics, hospitals, labs, and specialists, so healthcare professionals aren’t forced to treat every visit like a first date.

In practice, a real EHR usually bundles:

• demographics + patient registration
• problem list, allergies, meds, immunizations
• visit notes, orders, and results (labs/imaging)
• care plans + care coordination
• access controls + audit trails (because data breaches are a thing)

Benefits of EHR systems

Most clinicians don’t love clicking through an EHR. But there’s no going back to handwritten charts. Even if some still call modern EHR/EMR systems “glorified cash registers,” the right setup wins on speed, safety, and coordination.

The fastest ROI usually comes from boring wins: routing, reminders, and reconciliation, aka medical record automation done consistently.

One caveat: the benefits come from intentional workflow design plus trained staff working with a system that has the essential features people can actually use. Installation alone delivers none of that.

Some doctors still have to suffer through this (in our day and age!)

1) Efficiency: less busywork, fewer bottlenecks

Automation in EHR software can cut friction out of internal workflows in a healthcare facility, when it’s configured for how clinicians actually work (not how vendors demo).

• faster decision-making (less chart-hunting)
• fewer manual handoffs and duplicate admin tasks
• less overtime spent on documentation clean-up
• better morale because the system stops fighting the staff

2) Better patient outcomes when screen time goes down

When clinicians aren’t trapped in a maze of clicks, they can focus on patients.

• more consistent follow-ups and continuity of care
• fewer errors caused by missing context and poor data accuracy
• stronger patient–physician relationships
• lower avoidable readmissions (when discharge + follow-up workflows are supported)

3) Optimized costs from less waste

EHRs don’t magically “save billions,” but they can reduce leakage across clinical and administrative workflows.

• fewer duplicate tests and avoidable rework
• fewer revenue-cycle misses from incomplete documentation
• better throughput and capacity planning from cleaner operational data

4) Coordination is the benefit clinicians feel first

Care coordination is where an EHR either shines, or fails loudly. A good system keeps the care team on the same page.

• smoother handoffs across departments and external providers
• fewer “fax it to me” moments and missing-history surprises
• everyone working from the same problem list and plan

5) Stronger security and compliance, if you actually configure it

Centralizing patient data raises the stakes. The upside: EHR platforms can enforce consistent controls across the team.

• role-based access and audit trails, with deny-by-default permissions
• data encryption (in transit and at rest) baked into the baseline
• fewer compliance fire drills because the records and logs follow a standard pattern

6) Decisions and engagement, once the data is structured

Once data is structured, EHR software turns into a clinical decision support layer.

• reporting and analytics to spot bottlenecks and quality gaps
• outreach (e.g., missed follow-ups, chronic care reminders)
• portals and self-service that reduce phone tag and keep patients in the loop

That’s the “why” behind EHR/EMR systems. Up next: what you’re building, and which features matter first.

Ready-made vs. custom EHR solutions

With software, there are really only two ways it goes: you adopt it, or it adopts you. If you’re still in vendor land, this checklist helps you avoid picking a shiny demo over a workable reality: choosing an EHR system.

The seemingly easier route is to install one of the well-known EHR systems (Epic, Cerner, Allscripts, you name it) instead of custom EMR/EHR software development. Each path has its tradeoffs:

Implementing an out-of-the-box EHR system

Pros	Cons
relatively fast setup off-set initial cost due to the subscription model ready ecosystem	might not work with your stuff long-term cost will be higher than with a custom-built EHR total dependence on a vendor walled garden extensive personnel training required

That’s the scenario where the software adopts you. You learn how to use it, work around its quirks, integrate it with everything else, train personnel, etc.

Alternatively, you can build your own EHR platform, and it doesn’t have to be that scary hairy thing from the 90s. If we like working with Gmail or Facebook, why can’t we create EHR software that works and feels just as natural?

Related: How to integrate your health app with EPIC EHR/EMR and Allscripts EHR integration.

Spoiler: yes, we can. Here’s what custom EHR software development actually entails.

Developing a custom EHR system

Pros	Cons
integrates with everything you need works the way you need further improvements at your will minimal personnel training no hidden costs additional revenue via the SaaS model	takes longer to implement than a ready-made EHR system still need a dedicated team to maintain and support will need to take care of licensing to offer your EMR via the SaaS model

EHR custom software development lets healthcare providers tailor the system to specific needs, from patient record management to clinical decision support. That’s the advantage out-of-the-box solutions can’t match: real flexibility for the way different medical practices actually work.

For the full breakdown of EHR cost, see our guide on EHR implementation.

Must-have features of a modern EHR system

Every EHR vendor has a different list of “must-haves.” The cards below cover the six feature modules that show up in every serious build, plus the standards each one speaks and the KPIs that tell you whether it’s actually working.

Clinical documentation module development

• Scope: SOAP/APS/OCT notes, reusable templates, smart phrases, structured fields (SNOMED CT, LOINC), ICD-10 capture, vitals.

• Builder notes: Offline-first edits, autosave, versioning, merge/conflict resolution for concurrent edits, e-sign, full audit trail; insert points for CDS Hooks.

• Interop model: FHIR Encounter, Observation, Condition, Procedure, Composition/DocumentReference; map to USCDI.

• Guardrails: Field-level permissions, “break-the-glass,” minimum-necessary views, PHI redaction for analytics exports.

• Ops KPIs: Note-closure time, coding accuracy, template reuse rate, addendum frequency.

• Gotchas: Free-text bloat, template rot, copy-forward risks, duplicate Observations across apps.

E-prescribing system integration

• Capabilities: New/change/cancel Rx, refills, eligibility/formulary checks, interaction/allergy screening, prior auth, EPCS (DEA 2-factor), pharmacy directory sync.

• Standards: NCPDP SCRIPT; RxNorm/NDC; FHIR MedicationRequest, Medication, MedicationStatement.

• Compliance: Identity proofing for prescribers, EPCS token management, immutable audit, clock drift checks on 2FA.

• Ops KPIs: eRx success rate, renewal turnaround time, hard-stop override rate.

• Gotchas: State-specific eRx mandates, test→prod cutover quirks, cancellation flows missed in QA, DEA audit readiness.

Laboratory information system integration

• Capabilities: Order entry (panels), specimen labeling, results ingestion, abnormal flag routing, delta comparisons, attachments (PDF/DICOM refs), send-out tracking.

• Standards: HL7 v2 (OML/ORU), LOINC mapping; FHIR ServiceRequest, DiagnosticReport, Observation.

• Workflow: Result reconciliation with provider acknowledgment and patient notification rules.

• Ops KPIs: Result turnaround time, unmatched result rate, abnormal acknowledgment SLA.

• Gotchas: LOINC drift across labs, one-off compendium codes, multi-lab normalization.

Revenue cycle management components

• Capabilities: Charge capture, coding assist (ICD-10-CM, CPT/HCPCS), claims (837), ERA posting (835), denials management, real-time eligibility (270/271).

• Standards/Data: FHIR Coverage, Claim, ClaimResponse, ExplanationOfBenefit.

• Controls: Segregation of duties, PHI tokenization for exports, payer-rule cache with versioning.

• Ops KPIs: First-pass acceptance %, days-in-AR, denial rate, clean-claim velocity.

• Gotchas: Clearinghouse edge cases, missing superbills from quick visits, payer-specific bundling rules.

Patient portal & messaging

• Capabilities: Appointments, results, secure messaging, intake/e-consent, telehealth join, payments, proxy access (pediatrics/elder care).

• Standards: SMART on FHIR/OAuth2; FHIR Patient Access APIs; map disclosures to USCDI.

• Safety: MFA, session limits, message retention policies, teen privacy flags, minimum-necessary threading for staff.

• Ops KPIs: Portal activation %, message SLA, no-show reduction, intake completion rate.

• Gotchas: Identity proofing, duplicate patient accounts, untriaged inbox overload, “right of access” conflicts with clinical judgment.

Clinical decision support & quality reporting

• Capabilities: Rules engine for alerts/ordersets/care gaps, registries, measure tracking (MIPS, HEDIS, eCQMs), care plans.

• Standards: CDS Hooks, CQL, FHIR Measure/MeasureReport, PlanDefinition, Library.

• Governance: Tiered alert severity, fatigue monitoring, post-deployment review loops, change management for rules.

• Ops KPIs: Alert acceptance rate, override reasons, measure pass rates, documented gap closures.

• Gotchas: Stale rules, version chaos across environments, “global” measures that miss specialty nuance.

In practice, AI in EHR automation can extend these capabilities with ambient documentation, note summarization, and workflow automation.

Types of EHR systems

EHR builds split along care-setting lines, because the workflows really are different. Here are the four most common types and what each one demands from the build.

Primary care EHR development

Primary care lives and dies on panel management: chronic disease follow-up, preventive care gaps, fast refills, and same-day acute visits without melting the inbox. Your EHR should make a 15-minute visit feel like 20 by front-loading context (last A1C, BP trend, care gaps) and giving clinicians one place to order, document, message, and close out the visit.

• Design for flow: single-screen vitals→assessment→orders; templated chronic-care notes that auto-pull recent Observations.

• Close care gaps: registry views + eCQM dashboards; care plans tied to tasks, not PDFs.

• Right boundaries: FHIR at the API edge (USCDI), internal domain models inside; eRx with EPCS where needed.

• Inbox sanity: triage rules and quick-actions for renewals; proxy access policies for families.

Watch out: overstuffed templates and free-text creep will nuke your quality reporting and burn minutes you don’t have.

---

Specialty practice EHR systems

Specialists need precision in the EHR: laterality in ortho, regimen tracking in oncology, trimester context in OB, validated screeners in behavioral health. Start by mapping the true clinical artifacts (flowsheets, calculators, imaging priors) and only then design notes and ordersets around them.

Make the imaging loop first-class: order routing, PACS viewer, priors side-by-side, and structured impressions mapped to LOINC/SNOMED. For behavioral health and SUD, plan for data segmentation and consent at the field or section level upfront.

Checklist

• Purpose-built flowsheets with decision support at order time (CDS Hooks), not post-hoc alerts.

• Exact coding semantics (laterality, staging, devices) to avoid “miscoded but documented” outcomes.

• Segmentation controls for sensitive notes/results and narrow sharing scopes.

Pitfall: forcing generic templates onto specialists guarantees junk data and alert fatigue.

---

Hospital EHR implementation

Hospitals are interface factories. You need bulletproof ADT, orders/results that never get “stuck,” and closed-loop meds that keep patients safe during outages and shift changes. Think of the build as four areas you have to land together: clinical reliability, identity, safety ops, and reporting.

• Core plumbing: HL7 v2 (ADT/ORM/ORU) for systems of record; C-CDA for document exchange; FHIR R4 for APIs/SMART apps.

• Identity & access: SSO (SAML/OIDC), patient identity via IHE PIX/PDQ, and “break-glass” with reason + immutable audit.

• Safety ops: downtime/read-only modes, barcode MAR, escalation rules for critical results and device alarms.

• Reporting: eCQMs and service-line dashboards built on PHI-aware data marts; CSVs in email don’t count.

Pitfall: wiring interfaces before governance and runbooks, your first 2 AM outage will become a safety event.

---

Ambulatory EHR solutions

Ambulatory is throughput and cashflow: tight scheduling, clean claims, fast telehealth joins, and a portal that actually reduces calls. Design around visit velocity, self-check-in, eligibility checks before the rooming starts, and note templates that don’t require a scavenger hunt.

• Scheduling that behaves: FHIR Schedule/Slot/Appointment, templated provider calendars, and no-show reduction via reminders + portal.

• Lean RCM: real-time eligibility (270/271), estimates at check-in, 837/835 clean-claim loops, and denial feedback into templates.

• Patient experience: secure messaging, e-consent/intake, proxy access; SMART on FHIR add-ons for niche workflows.

• Ops analytics: cycle time, show rate, first-pass acceptance; review weekly and adjust templates monthly.

Pitfall: untriaged inboxes and ad-hoc scheduling rules will drown staff; set triage protocols and guardrails early.

Complete EHR software development roadmap: step by step

EMR software development isn’t rocket science, and it pays back in real dividends over time. The playbook for how to build an EHR system starts here.

Skim the steps below and how to create an electronic medical record system reads like a checklist, not a maze.

The 13 phases of how to build an EHR system, at a glance:

Step	Description
Step 1: Get data migration plan	Prepare your EHR to absorb legacy data without loss and talk to external systems via FHIR and HL7.
Step 2: Identify core modules	Define essential modules: patient records, scheduling, billing, eRx. Prioritize MVP features so the build stays lean.
Step 3: Get key requirements	Gather user-specific requirements and validate them against real clinical and administrative workflows before code starts.
Step 4: Ensure compliance	Address HIPAA, SOC 2, and ONC certification early. Patching them on later costs more than baking them in.
Step 5: Design system architecture	Map data flow through backend services and security layers. Match the UI and core feature architecture to agile rhythms.
Step 6: Choose technology stack	Pick backend, frontend, database, and hosting technologies that fit your team’s skill set and compliance scope.
Step 7: Create custom UI/UX	Build user-centered designs from real workflows. Prototype with clinical users and refine until the UI fits how they actually work.
Step 8: Integrate APIs, etc.	Add connectivity to labs, pharmacies, telehealth, and wearable data through secure APIs and an event-driven architecture.
Step 9: Implement data security	Apply HIPAA-compliant encryption and access control. Automate backups so patient data survives a hardware failure.
Step 10: Prepare for launch	Finalize documentation and run readiness checks. Coordinate the go-live as one rehearsed handoff.
Step 11: Testing and validation	Run functional, load, security, and penetration tests. Simulate edge cases against real clinical environments.
Step 12: Phased roll-out, train staff	Deploy the system gradually and tailor training by user role. Both decisions cut go-live friction.
Step 13: Support and maintenance	Monitor feedback and ship regular updates. Keep the EHR in step with regulations as they change.

Onto the actual roadmap.

Step 1: Plan migration and interoperability first, or pay for them twice

Tackle data migration and interoperability in phase one. Bolt them on later and the cost compounds. It’s a two-track job: absorbing legacy data from previous systems, plus making the new EHR talk to other platforms in the healthcare ecosystem.

That includes planning for:

• Legacy data cleanup and validation
• Mapping historical records to new data models
• Choosing interoperability protocols (e.g., FHIR, HL7)
• Establishing connections to labs, imaging systems, pharmacies, and even health information exchanges (HIEs)

If your EHR can’t talk to the systems your partners and clinicians already rely on, adoption stalls.

Data migration

Migrating existing patient records into a new system is a foundational step in building EHR software. Every detail has to survive the move so continuity of care and regulatory compliance (HIPAA, audit trails, data retention) stay intact.

Most teams already keep patient data in some system. Migrating it into the EHR without losing anything is the whole point of EMR software development. Caching is the other piece worth planning for.

On mobile, cache patient data so offline edits don’t get lost. When the device comes back online, the app has to upload the missing data AND pull back anything other team members entered in the meantime, without overwriting or losing anything.

APIs

API integration is what makes an EHR interoperable. It moves data between labs, pharmacies, imaging centers, and third-party services in real time. That’s what keeps clinical workflows running.

APIs handle EMR interoperability: moving data (e.g., lab results) between platforms in the right formats, then processing it where it’s needed. That’s where FHIR by HL7 and other data standards (CPT, DICOM, CCD) earn their keep.

Specode’s AI-assisted toolkit speeds up custom healthcare software development for EHR/EMR systems, especially the API integration scaffolding.

APIs do the heavy lifting in EHR custom software development. They pull patient visit data, manage medication lists, sync treatment plans across platforms, and trigger e-prescriptions back to pharmacies.

Step 2: Map core modules before you scope features

Before you design an EHR system, map out the core modules. What has to exist day one, what can wait. The modules are the backbone of your clinical and administrative workflows.

Some of the most common modules to consider:

• Patient records and charting
• Appointment scheduling
• Lab and imaging integration
• Billing and insurance handling
• E-prescriptions
• Communication tools (internal chat, patient messaging)
• Reporting and analytics
• Role-based access control

You won’t need them all upfront. Identifying the initial core is what makes the MVP work.

See Must-Have Features of a Modern EHR System for the full breakdown.

EHR builds are multi-app from day one

EHR system development almost always means building a suite: patient portals, clinician dashboards, and admin panels. Each one supports unique workflows and needs its own secure data access.

This is hard to miss. Yet most companies talking about EHR development skip the part where they tell you you’ll be building multiple apps. The multi-app reality clicks during the strategy workshop, once you walk through who’ll actually use the system.

Nurses and doctors fill in patient details and look up vitals. Front-office staff, administrators, IT, and management use the system too, often on different devices.

The question becomes: how do we fit all of that into a single EHR platform? How do we create EMR software that works equally well for all users on smartphones, desktops, and tablets?

The simple answer: you build multiple applications for different use cases. Your EHR is a layer cake. Zoom out and you’ll see:

• multiple front-ends (that’s how developers refer to apps we, users, interact with)
• APIs layer
• security mechanisms
• back end with databases

Related: Complete Guide to Building a Healthcare App

The simplest sketch of a typical EHR platform: you and your team will be working on several separate applications. Something like:

• a tablet app optimized for doctors and nurses
• a smartphone app for clinicians on the go
• a web dashboard for administration and management
• a patient portal for self-service tasks

When you build your own EHR software, nothing stops you from shipping independent applications (that still sync clinical data in the background) for each user role.

Your MVP defines what comes first

When creating EHR software, a tightly scoped MVP keeps you lean. You validate the critical features in real healthcare environments first: patient charts, scheduling, lab orders, e-prescriptions.

A clinic, private practice, hospital, or telehealth provider may benefit from every module that makes up an EHR system. Pick the modules with the strongest ROI first.

Which parts of the system pay back fastest? Start there. You don’t need to ship every EHR/EMR module on day one with all the bells and whistles.

Related: MVP App Development: Everything You Need to Know

Our preference is to begin with a single app for doctors and nurses (the interface adapts based on user role) plus another for admins. Even then, trim features to the bare minimum that moves a real number, for example:

• faster test results from labs
• built-in e-prescribing
• on-the-go access to patient medical history
• secure clinician-patient messaging

Once metrics confirm the value, you’ll keep improving on the MVP, drawing funds from cost savings or new revenue. Use a minimum viable product healthcare approach: ship the smallest workflow that proves real clinical value, then iterate once you’ve seen what users actually do (not what they say they’ll do).

The MVP question and your call on where to start belong to the strategy step.

Step 3: Nail functional requirements before code starts

Before any code is written, you’re defining how the EHR supports patient care, clinical documentation, billing, and compliance reporting. The goal: a sharp, reality-checked picture of what your EHR must do, for whom, and why. Every design and engineering decision downstream traces back here.

Three parts:

Assessment

Start with your current pain points. What workflows are inefficient? Where do you lose time or data fidelity? Where are clinicians and admins complaining loudest?

Scope definition

Once the gaps are clear, define which features are must-have versus nice-to-have. Set boundaries too: what won’t your EHR do in v1?

Business case

Tie functional needs back to measurable outcomes: readmission rates dropping, billing accuracy climbing, appointment cycles shortening, clinical documentation time falling. These anchor your MVP and long-term roadmap in ROI logic, since wishlist thinking doesn’t survive contact with the build.

The product vision has to match clinical reality and financial viability. List-making alone won’t get you there.

Any project, EHR system development or clinic construction alike, needs thorough research and planning. You’ll have to answer questions like:

• Who’s actually using this EMR system?
• What’s the end goal for implementing an EHR?
• Are there target dates for delivery?
• How do I measure success?

These and many more need answers to shape project scope. The strategy session usually closes with:

• lean canvas (just a clever word for business plan/model)
• high-level, prioritized feature list
• approximate diagram of the EHR’s architecture
• rough timeline and milestones

When planning EHR system design, the system has to fit your healthcare organization’s workflows. Every role that’ll touch it matters: whether you’re looking to create an EMR system or build an EHR platform, administrative staff and doctors need different functions.

Most development agencies love when a customer comes in with a ready plan and a clear vision, so they can start building without delay. Others, like Topflight, prefer to help you form your strategy, sometimes starting with nothing but a napkin sketch.

We’d take you through a discovery process and help shape your EHR vision around specific ROI metrics.

By the end of this step, you’ll have a clear sense of why you’re building the EHR system and a rough vision of its components. The next one is compliance, which a lot of EMR software development conversations breeze past.

Related: How to Build a Medical Startup

Step 4: Bake compliance in from day one

Building a HIPAA-compliant EHR system means regulatory work is baked into every feature, from user authentication to audit logs. Validate certifications and privacy protocols early or you’re patching them three months before launch.

For U.S.-based products, HIPAA compliance is non-negotiable. But depending on your scope, you might also need to meet:

• HITECH regulations
• ONC-ATCB certification for meaningful use
• CE Marking (if entering the EU market)
• SOC 2 or ISO 27001 (for enterprise partnerships)

Bake compliance into your product architecture, access policies, operational workflows, and vendor contracts from day one.

Security and HIPAA compliance

HIPAA compliance is table stakes for any healthcare software touching PHI.

We covered the topic ad nauseam in separate blogs, e.g., here: Comprehensive Guide HIPAA-Compliant Application Development.

To make EHR software HIPAA compliant: lock down access control to patient data by role, and run automated logs that capture every action for audit.

Patient privacy sits at the center of EHR system design, especially when the data is sensitive: allergies, disease history, ongoing treatment records.

When you create an EHR platform, hitting certification standards (ONC-ATCB or CE Marking) is how you prove the system meets safety and performance regulations.

These certifications give healthcare providers confidence and shorten the approval process for new features like e-prescriptions, lab integrations, clinical decision support tools, and remote monitoring.

Step 5: Design system architecture

Architecture is where EHR system design splits in two: the screens clinicians touch and the data plumbing underneath. Both decisions lock in early, and getting either wrong costs you on every feature you add after.

Core features: UX meets system logic

One thing easy to miss when designing an EHR system: check with your developers whether a screen is too complex to build cleanly. They call it technical UX validation.

Developers will spot shortcuts when they see a cleaner way to build a feature. Any design can be coded eventually. What you want is the version that ships on time and works for the user role it’s built for.

Look at most EHRs and you’ll see screens packed with checkboxes, fields, tabs, and menus. Past about seven major interactive elements on a single screen, your user is lost. That happens when designers and developers don’t sit with the actual user roles before locking the layout.

EMR software design has to work for both sides: the doctors clicking through patient visits up front, and the scheduling, billing, reporting, and privacy modules running underneath. When your EHR and EMR software development process bakes usability into the interfaces, medical staff stop fighting the tool.

Data architecture: blueprint for information flow

Your EHR software development needs data architecture that survives HIPAA audits and talks cleanly to outside systems: labs, payers, claims clearinghouses, and health information exchanges.

You’re deciding how patient data moves across modules: appointments, billing, e-prescriptions, lab tests, and clinical notes. Pick a relational database like PostgreSQL or document-based storage like MongoDB. Either way, build in HIPAA audit logging and role-based access from the first sprint. Retrofitting those is expensive.

Plan real-time sync between front-end clients and backend services, especially if you need offline mode for clinical environments with patchy connectivity. And design for FHIR and national network integrations now, even if you won’t turn them on until later.

Architecture that fits agile

The design stage is where agile actually kicks in. Agile isn’t novel and we won’t pretend otherwise, but it’s the industry default for a reason.

Related: Agile App Development: Building Winning Products

Agile means iterations on the design and every step that follows. Iterations don’t stop at release either, since the products that survive keep growing as users and the market shift.

The agile approach sets up the team composition and tooling you’ll need to sustain an EHR past launch.

Step 6: Choose technology stack

Your tech stack decisions shape four things at once for an EHR system: how fast it ships, how reliably it runs under load, whether it clears HIPAA, and how painful maintenance gets a year in. Pick well and your engineers stop fighting the tools every sprint.

Stack and team composition

In EHR custom software development, your stack has to match what your team can actually ship. The choices boil down to four layers: front-end, back-end, database, and APIs. For each, pick the version your engineers have shipped to production before. Hot frameworks they haven’t used will bite you in month 3.

You also need a team with real experience building EHR solutions. Building an EHR system from scratch, your minimum team looks like this:

• front-end devs (iOS/Android/React, depending on the apps you’re shipping)
• full-stack back-end developer for core logic, database, and security work
• dedicated API developer
• QA engineers
• UX/UI designer
• product manager
• project manager

Product manager and project manager are different jobs. The product manager makes sure your vision lands with the healthcare app developers building it. The project manager owns the day-to-day mechanics of getting it shipped.

Stack choices follow team skills and what the EHR product actually has to do. A typical set:

• Front-end: React (web), React Native or Flutter (mobile) for cross-platform speed.
• Back-end: Node.js, Django, or .NET. Pick based on the load you expect and what your team has shipped before.
• Database: PostgreSQL or MongoDB. Structured vs. flexible schemas, depending on how your clinical data is modeled.
• APIs: REST or GraphQL. FHIR compatibility is non-negotiable for EHRs that need to talk to outside systems.

Cloud platforms (AWS, Google Cloud, Azure) offer HIPAA-ready environments with the compliance plumbing in place. If you’re adding AI features, plan GPU-ready infrastructure and frameworks like TensorFlow or PyTorch into the stack early.

Where emerging tech earns its place

Modern EHR platform development pulls in AI, wearables, real-time alerts, and tighter telehealth integration. The real question for each: does it improve patient care, or just add another vendor to the chain?

If you’ve worked clinically, you know the basics an EMR needs: patient records, charting, e-prescriptions, and reports. Our bet is, if you’re looking to build an EHR, you’re after more than that. Some advanced features worth budgeting for:

• AI and machine learning for parsing medical records, flagging high-risk patients, supporting clinical decision-making, and catching missed allergies or medication conflicts
• IoT and wearables that feed the EHR with patient vitals in real time
• Telemedicine integrations
• Blockchain-based EHR for trustless operations across a consortium of providers

Related: IoT App Development Guide and Blockchain in the Healthcare

Also Read: How to Build a Wearable App for iOS and Android

Integrations like e-prescriptions and lab tests cut real friction from clinical workflows. Adding chat for inter-staff communication or a mental health tracking module widens what the system can do across different healthcare settings.

Provider EHR experience has room to improve. Ambient scribes, automatic handwriting recognition, and AI-based imagery analysis are where the next round of ergonomic wins is coming from.

Step 7: Create custom UI/UX for clinical workflows

UI design in an EHR comes down to one job: take friction out of clinical workflows. The best interfaces disappear into the work, and clinicians stop thinking about them. That’s the bar.

Why doctors complain about EHRs

Good UI and UX in EHR custom software development cut clinician fatigue and speed up patient data access. Legacy systems do the opposite: every feature buried two clicks deeper than it should be.

Why do doctors and nurses constantly complain about EHR systems? Why do they call them 800-pound gorillas and scold them for their click-to-death nature? Because many of them were built for the billing department, not the clinicians using them all day.

Related: The Ultimate Guide to UI/UX Design and Healthcare App Design

Custom EMR development changes that equation. You can design distinct front ends for different user roles, so the EMR software doesn’t get in their way.

From user flows to prototypes

Designers start by mapping what each user role actually does day to day. The output is a set of flowcharts showing the cleanest path through the software for each role.

Low-fidelity designs

From those flows come rough mockups, also called low-fidelity wireframes. Picture sketching application screens on a napkin, except in Figma.

Figma (which we use too) is popular because it lets designers wire all the screens together. Static mockups start responding to taps and gestures, which turns the wireframe into a clickable prototype.

Lately our team goes straight from design to code using Figma’s built-in handoff tools. Where the project allows, we prefer a fast coded prototype over a clickable mockup.

High-fidelity designs

Next comes turning that rough prototype into a high-fidelity version, where the graphics match what users will actually see in the app. Why not start at high-fidelity? Because iterating on rough wireframes is faster and cheaper than re-rendering polished screens every revision.

Validate with real clinical users

The interactive prototype exists for one reason: design validation. We test with real users before any code gets written. The EHR software we’re building has to match how clinicians actually work in their environment, and that’s hard to guess from a kickoff meeting. It has to come from testing.

We use tools like usertesting.com to gather feedback and tighten the prototype before we build EHR software.

Test prototypes with real clinical users: doctors, nurses, medical assistants, and admin staff. Their feedback surfaces bottlenecks that don’t show up in planning meetings.

Step 8: Integrate APIs and third-party services

No modern EHR is an island. Your system has to plug into the services clinicians already use: e-prescriptions, lab orders, telehealth platforms, patient intake forms, and the rest of the stack at the practice. Integration quality usually determines whether the EHR actually gets adopted or quietly gathers dust.

API-first or pay for it later

An API-first EHR architecture means every core function, from patient record retrieval to appointment booking, is available through documented endpoints. The payoff comes when you layer on new features later without ripping into the core.

Support the data exchange standards your future integrations will require: FHIR (Fast Healthcare Interoperability Resources) and HL7. Skipping either closes off the providers and national networks that demand compatibility with their existing clinical systems.

Common third-party integrations

Connecting an EHR system to the outside world starts with a handful of named providers: Surescripts for eRx, Twilio or Zoom for Healthcare for telehealth, and the lab networks (LabCorp, Quest) your clinicians order through. Each saves real time in workflows that would otherwise stay manual.

Typical EHR integrations:

• E-prescription platforms (e.g., Surescripts)
• Lab and diagnostic systems
• Telehealth providers (e.g., Zoom for Healthcare, Twilio)
• Payment processors for billing modules
• Scheduling tools (both internal and external-facing)
• Wearable and IoT devices to feed real-time vitals
• CRM and patient engagement tools

Once you start piping reminders and recall outreach, you’ll want a clean EHR CRM integration pattern. Skip it and you end up rebuilding a call center inside your EHR.

These services come with SDKs or APIs your EHR development team has to integrate and keep maintained over time. Vendor APIs change; budget for that.

Webhooks aren’t optional

Your EHR application development needs webhooks and real-time event triggers from the start. They’re how lab result alerts reach the ordering doctor before the patient does, and how vitals from a wearable trigger a callback when blood pressure crosses a threshold.

That’s a real user experience win.

Step 9: Implement data security, encryption, and backup measures

When developing HIPAA-compliant EHR software, security has to be baked in from day one. Encryption, backups, access controls, and audit logging all show up in the OCR investigation when something goes wrong. Patient trust shows up earlier than that.

Lock data down by role

Set up role-based access controls so users only see what they need for their job. Log every action, especially around patient data. Cover the basics: session timeouts, brute-force protection, anomaly alerts on access patterns, and forced re-auth on sensitive routes.

Encrypt everything, keys included

Encrypt all data in transit (TLS 1.2+) and at rest (AES-256). Use managed services from HIPAA-compliant cloud providers to handle encryption keys and access policies without reinventing the wheel.

Backups you’ll actually need to restore

Automate encrypted, offsite backups with clearly defined RPOs and RTOs. Run restore tests regularly. The worst time to find a broken backup strategy is during an actual incident.

Step 10: Stage the launch before you flip the switch

Before launching your new EHR system, you need a controlled rollout strategy, compliance checks, a fully briefed support team, and a tested rollback plan. Patient care and operational safety depend on the go-live going well.

Get your launch checklist in order

Make sure you’ve covered critical pre-launch checks:

• Confirm role-based access is correctly configured
• Validate all third-party integrations (eRx, labs, scheduling) are stable
• Ensure performance under expected user loads (especially during peak hours)
• Review HIPAA compliance touchpoints, including logging, backups, data retention, and audit trails

Also, verify that your go-live version reflects all final content from stakeholder sign-off and that a rollback plan exists, just in case.

Timing the launch and team coordination

When the product does what it’s supposed to do, you launch publicly.

Pick a low-traffic day for go-live. Make sure your devs, QA, product team, and on-call ops are all on standby. Assign a point person to triage post-launch feedback and hotfix requests in real-time.

Launch success comes from trust with your clinical users on day one. Stability alone doesn’t get you there.

Step 11: Test against real clinical chaos

Stress-testing matters when you’re building EHR software. QA should simulate real clinical chaos so performance, accuracy, security, and uptime hold up under pressure.

Quality assurance from the start

Testing runs alongside development. Every new version of the healthcare software gets tested before shipping. Developers bake automatic tests into code. Then a QA engineer walks through every realistic scenario, trying to “break” the system from every angle they can think of.

Related: QA Guide: Steps, Tools, Best Practices and More

Go beyond basic QA during EHR development

System validation should include:

• Functional testing (do features work as expected?)
• Regression testing (did recent changes break anything?)
• Load testing (can it handle real-time usage from multiple users?)
• Security testing (is your data leak-proof under stress?)

You should also test edge cases, like poor Wi-Fi, outdated devices, simultaneous data edits from different roles, or partial sync failures, to mimic real clinical environments.

Include clinical validation

Finally, validation must involve real end users: physicians, nurses, billing admins, and front-desk staff. Their hands-on feedback during final testing rounds will surface workflow friction points that automated tests can’t catch.

Step 12: Phase the rollout and tailor training by role

A phased rollout makes EHR implementation work, and targeted training lifts staff adoption. Both belong in your EHR implementation plan.

Roll out in stages

Start with a controlled group like a single department or clinic, before scaling across the organization. This lets you validate workflows, uncover edge cases, make adjustments, and gather first-wave feedback without overwhelming your staff or support team.

Once the pilot proves stable, you can extend rollout site-by-site or team-by-team, gathering real-time feedback at every stage.

Don’t skip the training

Even the cleanest UI won’t help if staff don’t understand it. Build training programs tailored to each user role, physicians, nurses, admins, billing teams. Include:

• Hands-on sessions
• Role-specific cheat sheets
• Shadowing workflows in real scenarios
• In-app guided tours

Set up dedicated support channels during rollout to answer “how do I…?” questions quickly. The smoother the handoff, the faster the adoption.

Step 13: Post-launch is where the product actually gets good

Post-launch, your team should keep iterating on the EHR software based on real user feedback. Regular updates, issue resolution, feature improvements, and security patches keep the system in step with healthcare needs as they shift.

Support and iteration

Development doesn’t stop at launch. You’ll keep shipping new features, improvements, bug fixes, and EHR software updates.

If “optimization” to your org means “we’ll revisit it next quarter,” steal a real playbook here: EHR Optimization

This phase is way less intensive than the initial EHR implementation. Still, plan for a retainer team to handle it.

Feedback loops and product evolution

Establish ongoing feedback channels with your users: monthly surveys, quarterly check-ins, in-app feedback tools, or office-hours sessions. Clinical workflows evolve, and your EHR should too. When the real pain is adoption and performance, you’re often better off planning an EHR upgrade than a rebuild.

Assign a product owner or clinical informatics lead to translate user feedback into real updates. Prioritize updates that reduce friction, improve performance, meet new compliance standards, or address security gaps.

Coding is one of the most important parts of EMR software development, but business owners rarely understand it well. And rightly so, developers have an even harder time parsing the daily healthcare routine of clinicians and admins.

That’s why post-launch support matters. The job is translating the messy reality of care delivery into ongoing product updates that make life easier for clinicians and devs alike.

Tech stack for building EMR/EHR software

Pick the team first. The tech stack comes with them. Walk into a Microsoft .NET shop and that’s the stack you’re getting, regardless of what looked clever on the last blog you read. That’s fine. All the major stacks work in the right hands, and the team’s reps with their chosen tools matter more than the tools themselves.

Related: How to choose the right tech stack for your application

Two non-negotiables for the team: clean integrations with your existing systems and third-party services, and a microservices-based EHR architecture. Any capable team will agree to both without argument.

FHIR-based EHR development

• Modeling: Map clinical data to FHIR resources (Patient, Encounter, Observation, Condition, MedicationRequest, etc.) with a clear profile/version strategy and validation on write.
• Auth and app model: OAuth2/OIDC plus SMART on FHIR launches (EHR-to-app and standalone). Token scopes follow the minimum-necessary principle.
• Patterns: Native FHIR store vs. FHIR façade over internal models, with eventing (subscriptions and webhooks) to decouple modules.

Common trap: pushing “everything as FHIR” through internal layers slows ops. Use FHIR at the API boundaries and let your internal domain models stay clean.

Cloud vs. on-premise EHR architecture

For most EHR builds, cloud is the default. On-prem only makes sense when a customer contract or regulator requires it. Major providers ship the infrastructure pieces you need for HIPAA-ready operations:

• BAAs
• KMS/HSM
• private VPCs
• regional controls
• autoscaling
• managed databases

You design for RTO/RPO with cross-region backups, and on-prem only enters the picture when a customer or regulator forces it. The bill there includes hardware lifecycle, patch windows, HA/DR complexity, physical security, on-call rotation, and spares. Hybrid setups (edge devices or hospital data centers feeding cloud analytics) sit in between, with strict egress controls and audit replication.

The “lift-and-shift” pattern turns expensive faster than teams expect. Costs explode without explicit budgets for egress, logs, backups, and observability.

Interoperability standards implementation

• Clinical: HL7 v2 (ADT/ORM/ORU) for messaging, C-CDA for documents, DICOM for imaging, and FHIR R4 at the API edge for USCDI compliance.
• Rx: NCPDP SCRIPT and EPCS, plus directory sync and cancellation/change flows tested end-to-end.
• Billing: X12 270/271 eligibility, 837 claims, and 835 ERA posting, plus a payer rules cache with versioning.
• Quality: eCQMs/QRDA or FHIR Measure/MeasureReport to support MIPS-compliant EHR systems without bolt-ons.
• Pitfalls: Silent version drift across partners is the recurring failure mode. Build contract tests using the real production payloads partners actually send; vendor-provided happy-path samples won’t catch the drift that will hit you in week 12.

EHR data migration strategies

• Inventory: Source systems, tables, documents (PDF/DICOM), and code sets. Decide authoritative sources per domain before writing any mapping code.
• Mapping and QA: Deterministic mappings plus exception buckets, with count reconciliation and clinical “golden patients” run end-to-end.
• Cutover: Dual-run window, read-only freeze plan, rollback checklist, comms to clinical ops, and a post-go-live defect triage queue ready to staff.
• Privacy: De-identify lower environments by default and tokenize PHI for analytics.

Free-text notes and orphaned attachments cause more cutover headaches than anything else. Handle both well before the weekend go-live; the post-go-live version of that work is always more painful and more public.

Security & compliance baseline

• Controls: Role scopes, break-glass with reason capture, field-level permissions, immutable audit trails, key rotation, secrets management, and two-factor authentication.

Technical controls are the table stakes layer. Operational rigor underneath is what drives clean audits:

• Processes: Vendor BAAs, incident playbooks, backup/restore drills that actually prove RPO/RTO, and least-privilege IAM enforced through code review.
• Evidence: Centralized logs, alerting on PHI access anomalies, quarterly access reviews, and deploy gates that block on privacy checks.

Audit prep stops being a fire drill when all three layers wire in during the first build. Retrofitting under audit pressure costs multiples of what wiring it in early would have cost.

Observability & operations

Every request touching PHI needs structured logs, metrics, distributed tracing, and request-ID propagation wired in from day one. SLOs come next: define your SLIs around the metrics that matter:

• latency
• error rate
• message backlog
• integration partner availability

Wire alerts into your on-call rotation with runbooks attached. For resilience in HL7/FHIR/X12 pipelines, the patterns that hold up under load are circuit breakers, idempotent consumers, and DLQs with retry logic. Run chaos days against non-prod environments to find the failure modes before your customers do.

Reality check: tools matter less than execution. When evaluating a custom EHR development company, look for these patterns already wired in by healthcare software architecture experts who’ve shipped them before. Avoid vendors who deflect integration questions into a vague “integration phase” later. One terminology note for RFPs: the phrase “ONC-certified EHR developers” shows up everywhere, but it’s a misnomer; ONC certifies products and modules. What you want is a team with modules shipped through ONC 2015 Cures Update testing on previous projects.

EHR/EMR system development cost

$400,000+ for a mid-level EHR system. Up to $1,000,000 for a full-blown platform. Eye-watering. Depending on your needs, you may just need integrations, which often fall well within the $100K range. A decent prototype for the web (without mobile clients) should be doable in the $150K-$200Kish range.

And if you’re benchmarking build vs buy against the 800-lb gorilla, here’s a grounded breakdown of Epic EHR pricing dynamics.

Related: App Development Costs: The Complete Breakdown

Topflight’s EHR development expertise

As certified healthcare technology developers, Topflight helps teams scope, build, integrate, and migrate EHR/EMR projects without turning clinics into QA labs. We’re pragmatic builders. We ship features that move clinical outcomes and revenue, and we document what auditors actually read. Audit trails come standard. Slideware doesn’t count.

Most clients ship on a prebuilt EHR foundation: auth, audit, consent, documentation, patient portal, and the other plumbing every clinical app needs. Less re-plumbing, earlier pilots, fewer integration landmines, and lower audit-prep cost downstream. Up to 5× faster to MVP compared to greenfield builds of similar scope (based on internal project baselines and module reuse).

Why it’s faster (and safer):

• Shared auth/audit/consent across modules → no “integration phase” to make them agree.
• FHIR/HL7 edges standardized; internal domain models stay lean.
• Migration playbooks (golden patients, exception buckets) reduce cutover risk.
• Ops baked in: BAAs, immutable audit, least-privilege IAM, PHI-aware logging from day one.

Most healthcare teams want integration help first: connecting an existing EHR to a new clinical app, or wiring a vendor EHR into the rest of their stack.

Check out our EHR integration services

Building your own EHR from scratch is usually a year-plus timeline and a substantial budget. Some EHRs are deliberately smaller. A tight clinical-data use case can ship in a few months at a fraction of the cost.

Take the RPM platform with a built-in EHR we made for Dedica. The build was deliberately lightweight and still landed where it needed to. The client went on to license the platform to other practices on a subscription model and closed his first $300,000 ARR deal soon after.

Selected EHR/EMR integration projects

#1. GaleAI: medical coding accelerator (Epic & Cerner)

Cross-EHR + AI deployment with marketplace distribution: SMART on FHIR integration, FHIR compliance across targeted resources, and mini-apps packaged for both Epic and Cerner marketplaces. Mirth Connect was the interoperability backbone where needed; we also simplified the prior-auth loop across payers and providers (pre-check + status).

Reported 97% reduction in coding time and ~15% revenue uplift from improved coding accuracy.

#2. Epic EHR integration: teleradiology workflow across facilities (NDA)

A hospital group needed radiologists to read studies remotely while keeping billing, orders, and results in sync across multiple PACS and partner sites. We implemented Epic EHR integration that tied ADT to billing, routed imaging orders to downstream systems, and posted solicited results back to Epic to close the loop.

Interfaces/standards used: HL7 v2 ADT, ORM, ORU; PACS integrations; Epic messaging to downstream systems.

#3. Epic EMR integration project: census & level-of-care dashboards (NDA)

For an operations vendor, we built an executive and care-team view of inpatient census and appropriate level-of-care, driven by Epic ADT feeds and discharge orders. DRG context and location signals improved bed-board decisions and ED-to-inpatient flow.

Interfaces/standards used: HL7 v2 ADT (demographics/service level/location), ORM (discharge orders), DRG coding.

#4. Cerner + LIMS + hospital systems: imaging & lab data in a unified app (NDA)

A non-profit chain needed a clinician dashboard that pulls imaging and lab context together. We delivered SMART on FHIR authentication with Cerner, fetched patient data from Cerner FHIR by MRN sourced from the in-house LIMS, and blended orders/results into a searchable, editable view, no writes back to Cerner by design.

Interfaces/standards used: SMART on FHIR (Cerner), FHIR R4 resources, HL7/LOINC mapping for observations, LDAP for internal SSO.

---

We don’t say it often, but Topflight is the right place to ship your EHR automation work. The team has deep knowledge of what medical workers actually deal with, and what it takes to help them get better results without burnout.

More on edge computing for healthcare and what it can do for your system’s performance.

Whether you decide to make EMR or build EHR software from scratch, the result should help your healthcare facility offer better patient care and cut friction out of operational workflows. Custom solutions let you integrate features like reporting, scheduling, real-time clinical decision support, and e-prescriptions, so your system evolves with your practice.

Even if you don’t have millions to invest in a new EHR but have secured a $100,000-$200,000 budget for IT automation, we can build something your staff and patients will actually want to use.

Related Articles:

1. HIPAA Compliant App Development
2. Patient Portal App Development Guide
3. SMART on FHIR Appp Development
4. How to build a doctor’s appointment application
5. How to develop a hospital management system
6. Guide to collecting healthcare data
7. How to create a telehealth application
8. E-Prescription App Development Guide
9. EHR for Medical Billing
10. Surescripts Integration: Main Steps

[This blog was originally published in January 2022, and has been updated in light of more recent information]

FAQ

 

What's the difference between EHR and EMR?

One uses the term health and the other medical, perfect synonyms. Some say that EMRs usually work within a single practice while EHRs work across multiple healthcare organizations. In practice, though, both EHR and EMR are used interchangeably.

Can you help us integrate third party software with our EPIC/Cerner/AllScripts EHR?

Absolutely.

How long will it take to create EHR software from scratch?

12-18 months; 6-9 months for an MVP.

What's the biggest mistake you can make with EHR development?

Demand agile development from your development partner. You’ll need incremental roll-out and validation, which only works with the agile pattern.

What technology stack do you recommend for building an EHR system?

Absolutely any tech stack will work as long as you pick the right team. You shouldn’t limit yourself to specific technologies; it’s all about niche expertise and the right mix of design and development talent. Probably one exception is cloud hosting: you need it, but again, that can be anything.