Build vs. buy for NEMT software: we usually say buy

We build custom software for a living. So it is worth saying up front that most non-emergency medical transportation operators who approach us about a custom platform should not build one.

That isn’t false modesty. It is what the market looks like right now. NEMT software handles trip scheduling, dispatch, driver management, GPS tracking, and Medicaid billing for non-emergency medical transportation providers, and mature products already do all of it. Rebuilding them is a poor use of capital.

What follows is our attempt at an honest version of the build-vs.-buy conversation, including the parts that cost us work.

Should I build or buy NEMT software?

Most operators should buy an off-the-shelf solution. Existing NEMT platforms already handle trip scheduling, standing orders, driver manifests, GPS tracking, pickup windows, ambulatory and wheelchair service levels, routing, no-shows, dry runs, vehicle management, billing workflows, and operational reporting. If your workflows fit those assumptions, buying is faster, cheaper to start, and the vendor carries the maintenance burden.

There is nothing inherently better about custom software. A custom platform gives you control, and control arrives attached to development, testing, hosting, security, monitoring, support, maintenance, and every future change.

And the maintenance part matters more than it looks on a spreadsheet. When Apple changes a mobile requirement, an API is deprecated, or something breaks for dispatchers on a Monday morning, the vendor owns that. With custom software, you do.

That trade is worth making when software gives the business something it cannot otherwise get. It is very hard to justify when the project recreates features that already exist.

When to build custom NEMT software?

Build when an existing product cannot support a business-critical requirement, and the constraint cannot be removed through configuration, an integration, middleware, or a different vendor. Four situations recur: a broker integration your platform will not support, a transport workflow that starts inside a hospital system, building a product to sell to other operators, and vendor data or exit terms you cannot accept.

We should be clear about where we are speaking from. We have shipped offline dispatch systems, hardware-connected operational applications, healthcare data integrations, and software that had to fit a workflow rather than the other way round.

Does NEMT software automatically import ModivCare and MTM trips?

Providers receive trips from brokers and managed care organizations, including ModivCare, MTM, Access2Care, Veyo, One Call, and Safe Ride Health, each with its own approach to trip assignment, acknowledgements, status updates, cancellations, mileage, authorization, and encounter data. Custom development becomes relevant only when your current vendor is the blocker.

Getting trip data into and out of the systems around dispatch is often the hard part, rather than dispatch itself.

When the workflow requires a dispatcher to read one portal and retype into another, that step is a cost and an error source. In concept, the fix is simple: trips arrive automatically, changes stay synchronized, drivers get the right information, completion data flows back.

Whether you can actually build that depends on API access, integration methods, commercial agreements, authentication, and what your software vendor permits. If your platform already supports the broker, there is no problem to solve. If it exposes the right APIs, a smaller integration project probably solves it.

Can hospitals send trip requests into NEMT software directly?

Hospital systems send trip data through REST APIs, HL7, or FHIR, moving patient, appointment, authorization, and status data between the hospital’s clinical system and the transport platform. Getting from the hospital into your NEMT software is much easier with a custom solution, especially when you are working with several hospitals, each with individual software.

Patient transportation becomes a different software problem when the request originates in a healthcare organization rather than with a dispatcher. A hospital may want transport requests created in its own clinical or operational system instead of having staff duplicate them somewhere else.

This is closer to work we have done. On Rheo, we built a mobile application that presents a real-time vitals platform to hospitals, with live data demonstrations in front of a clinical audience. The lesson from that kind of project is that the interface is rarely the hard part. The difficulty lies in making two systems with different assumptions behave like one workflow — access control, auditability, and predictable behaviour when data is incomplete, delayed, or duplicated.

It is also where HIPAA, business associate agreements, role-based access, audit logs, SSO, and data residency start to matter more than the dispatch screen does.

Building NEMT software to sell

Selling software to other operators usually requires multi-tenancy, organization-level permissions, white labeling, usage controls, customer-facing APIs, separate billing logic, and a roadmap you control. A third-party platform is useful for validating the business model, but it makes a poor foundation when another company owns the infrastructure, the API, and the commercial terms.

There is a large difference between an operator that needs internal software and a company building an NEMT product for other operators.

In the second case, ownership is not an IT preference but a product strategy.

How to switch to another NEMT software?

That depends on the vendor’s export capability, not only on the ownership clause in the contract. A NEMT business accumulates years of trip history, standing orders, driver and vehicle records, mileage, broker identifiers, billing information, encounter data, operational notes, and audit history. Confirm before signing that all of it can be exported completely, in a usable format, with the relationships between records intact.

One question deserves an answer before you sign anything: what can we take with us if we leave?

Some organizations also have requirements about hosting location, access, retention, and auditability. If a vendor meets them, buy. If none can, infrastructure ownership becomes one of the better arguments for building.

How much does NEMT software cost?

Entry-tier NEMT software commonly costs $50–$200 per vehicle per month. A 20-vehicle fleet therefore pays roughly $1,000–$4,000 a month, or $36,000–$144,000 over three years. Above about 50 vehicles, pricing usually moves to negotiated terms, so multiplying a list price stops producing a reliable estimate.

Two mistakes make most build-vs.-buy comparisons useless. The first is comparing one month of subscription against the total price of a build. The second is taking an entry-level per-vehicle rate and multiplying it across a large fleet as though enterprise pricing stayed linear. It does not.

For a small fleet, the entry-tier maths is still a reasonable starting point.

Those are not quotes, and they are not enterprise pricing. Above roughly 50 vehicles, go and get a negotiated number rather than multiplying a list price.

The custom side deserves the same honesty, and the honest answer is that a single published figure for “a custom NEMT platform” would be meaningless. A focused first release and a multi-tenant commercial product differ by an order of magnitude.

What you can insist on — from us or anyone else — is an estimate broken into the parts that drive it: backend and API, dispatcher application, driver application, each integration priced separately, billing workflows, multi-tenancy if you need it, QA, deployment and infrastructure, monitoring, project management.

A quote that does not separate those is not a quote you can compare against anything. Integrations are where estimates go wrong most often, because the cost depends almost entirely on what the other side exposes — and that is usually unknown until somebody reads the documentation and requests access.

Is it cheaper to build your own NEMT software?

Divide three-year custom ownership by three-year SaaS cost per vehicle, and the result is your crossover fleet size. Three-year ownership is the initial build plus three years of maintenance and infrastructure; three-year SaaS per vehicle is the monthly rate times 36. A $100,000 build with $15,000 a year in maintenance over three years costs as much as 80 vehicles at $50 per vehicle per month.

Maintenance costs for NEMT software after launch

Typical maintenance cost is between 5% and 15% of the development budget per year. Maintenance covers dependency updates, external API changes, operating-system requirements, infrastructure monitoring, security work, and bug fixes — everything needed to keep the software working. Product development, which changes what the software can do, is a separate budget line. Broker and payer integrations deserve their own allocation, because they are maintained by someone else and change on someone else’s schedule.

The build budget gets the attention because it is the largest figure that catches the eye. It is not the cost of ownership.

Once software is live, real users find the cases nobody imagined. Funding maintenance but not product development is how teams end up with a system that runs reliably and slowly stops fitting the business.

We wrote more about this in app maintenance costs in years one to three.

When not to build NEMT software

When the requirement amounts to scheduling, dispatch, GPS tracking, driver management, and reporting with different branding, existing products already solve those problems, and rebuilding them buys ownership cost without business value. Before replacing anything, check whether configuration, middleware, an API integration, a separate small application, or a different vendor removes the constraint.

We would not recommend a custom platform because a team dislikes its current interface. Replacement should be the consequence of a constraint, not the opening assumption.

That order matters because a rebuild resets everything that currently works — the scheduling logic your dispatchers trust, the billing exceptions someone spent two years discovering, the undocumented workarounds. All of it has to be found again and rebuilt. A narrower fix that leaves the working parts alone is almost always cheaper and lower risk.

The cases that do justify building are specific. Drivers lose connectivity on part of the route and dispatch still has to function. A hospital needs the workflow to begin in its clinical system without anyone retyping requests. An operator is turning an internal workflow into a product other companies will use.

Those are engineering problems. “Let’s build our own dispatch software” is a project idea.

How to build NEMT software

It starts with mapping the trip lifecycle end to end — request, authorization, scheduling, assignment, driver workflow, pickup, transport, drop-off, billing or encounter data, reporting — and then deciding which parts genuinely need to be owned and which can keep relying on existing services. The difficult areas are integration failure handling, dispatch modelling, offline driver applications, and capturing the right billing data at the right moment.

We would validate the workflow and the integration constraints before proposing an architecture, because we have built the components rather than the whole category.

A few things we would look at closely.

Integrations

The happy-path API call is rarely the problem. Retry behavior, duplicate events, partial failures, data conflicts, and manual recovery matter more. An integration that works perfectly until the broker has an outage, and then needs a dispatcher to rebuild four hours of trips by hand, is not a solution you need.

Dispatch modelling

Standing orders, will-call trips, pickup windows, wheelchair and stretcher requirements, multi-load assignments, deadhead mileage, manifests, no-shows and dry runs are not variations on a generic job record. The goal is not to put every NEMT term in the database, though — it is to model the workflows that actually change a dispatch decision.

The driver application

The crew app must solve several problems. First, it has to be very simple to use. Crew members come and go, and a new crew member must be able to use the app after a five-minute explanation from a teammate. Second, it has to be reliable. The app should work with and without an internet connection, sync data correctly, and have a fail-proof flow that is impossible to get wrong. We built something similar for our UK client — 136 Gateway.

Making the decision

If an existing platform supports your workflows, integrations, compliance, and data requirements, buy it. It is faster, cheaper to start, and somebody else carries the maintenance.

Build when the constraint is structural — the integration does not exist, the workflow cannot be bent to fit, the application has to work in conditions the product does not support, the software is becoming something you sell, or control of infrastructure and data is a business requirement.

The financial crossover is worth calculating, but it should not be the reason. The better question is whether ownership gives you something the market cannot.

If you are somewhere in the middle of that decision and not sure which side you are on, we are happy to talk it through. It is usually a shorter conversation than people expect, and it sometimes ends with us telling you to keep what you have.

FAQ

How much does it cost to build custom NEMT software?

A first production release of custom NEMT software typically costs $50,000–$80,000 and takes four to six months. Maintenance and infrastructure cost around $5,000–$6,000 a year after launch.

How long does it take to build an NEMT platform?

A first release built around one operational workflow — dispatch, scheduling, and a driver app — typically takes 4 to 6 months. Adding billing and one broker integration pushes it to 7 to 10. A multi-tenant product to sell to other operators runs 12 to 18 months. Broker and EHR onboarding adds weeks to months on the other organization’s calendar, not yours.

Rough phase durations on a first release:

• Discovery and scoping — 2 to 4 weeks
• Core dispatch, scheduling and trip management — 8 to 12 weeks
• Driver app, iOS and Android — 6 to 10 weeks, overlapping the above
• Billing and claims export — 4 to 8 weeks
• First broker integration — 4 to 8 weeks of development, plus the broker’s own onboarding
• Hospital or EHR connection — 6 to 12 weeks of development, plus review cycles on their side
• Hardening, pilot, and rollout — 4 to 8 weeks

Is your NEMT software HIPAA compliant?

We build to HIPAA requirements and sign business associate agreements. In practice that means encryption at rest and in transit, role-based access control, per-user audit logging, defined retention and breach notification terms, and hosting in a region you approve. Compliance is a property of the whole arrangement — software, hosting, contracts and operating procedures — so we scope it explicitly rather than treating it as a checkbox.

Can you customize existing NEMT software instead of rebuilding it?

Often, and it is worth testing before anything else. If you own a legacy system that needs maintenance and improvement, the research comes first: the software may be outdated enough that rewriting costs less than maintaining it, and we will say so if that is what we find. If rewriting is not an option, we will help with maintenance work instead.