If you're starting a telehealth business or running one, you've probably framed the platform decision as a binary. Buy an all-in-one suite or build custom from scratch. One gives you speed and the other gives you control, and it looks like you have to pick a side.
There's a third option that most teams overlook, and once you see it the decision gets easier.
The all-in-one telehealth platform trap
All-in-one telehealth platforms are appealing at first glance. One vendor, one contract, one login. They run your checkout, patient portal, provider network, pharmacy routing, and marketing site. You sign up and things work. The demo looks clean, the sales team answers quickly, and launch timelines are short.
The problems usually start around day 90.
All-in-one platforms are built for the average customer, so every piece reflects compromises you didn't choose. The checkout flow is fine, but changing the intake logic means filing a feature request. The provider network works, but it's their network, with their credentialing process and their availability rules. The patient portal exists, but it doesn't connect to the CRM you already use.
That matters more than most teams expect up front. You'll want to add treatment categories, change pharmacy partners, adjust intake flows based on conversion data, or move to a provider network that fits your clinical model better. On an all-in-one platform each of those changes is impossible, expensive, or waiting on someone else's priorities.
Where the lock-in shows up
- You can use only the provider networks the platform contracts with. Finding a better partner for your niche often means switching platforms entirely.
- Conversion work needs iteration. If every checkout or intake change is a dev ticket to the vendor, you iterate at their pace.
- Different treatment categories often need different pharmacy partners, and all-in-one platforms usually support their preferred partners over yours.
- Your patient data lives in their system. Getting it out, or connecting it to your own analytics and CRM, ranges from awkward to adversarial.
- Off-the-shelf sites get you live fast and make it hard to stand out. Performance tuning and SEO work stop at whatever the platform supports.
None of these hurts on day one. By day 180 you've built your operation around the platform, and the switching cost is enormous.
What does building custom telehealth infrastructure actually cost?
If all-in-one platforms constrain you, why not build everything yourself? You'd have total control. Every integration would be exactly what you need, your checkout would be purpose-built, and your data architecture would be clean from the start.
Custom builds take months of engineering to reach production. They need a full engineering team, a dedicated product manager, and enough capital to fund development before you've generated meaningful revenue. Every API integration is its own project. Every compliance requirement is yours to research and implement, and every edge case in pharmacy routing or provider scheduling is yours to find and solve.
Choosing a custom build means choosing to become a software company that also does telehealth.
For well-funded teams with strong technical leadership, that can work. For most telehealth brands, especially those validating a market or trying to scale efficiently, the custom build is a trap of its own. You spend months building infrastructure while the clinical experience and patient acquisition wait.
The hidden costs of custom
- Six to twelve months before launch is common, which in telehealth is a long time to go without market signal.
- You need backend engineers, frontend engineers, someone for DevOps, and someone who understands healthcare compliance. That's a team of four to six before you've seen a single patient.
- Custom systems need maintenance once they're built. API partners change their specs, compliance requirements change, and every integration is another place for bugs to live.
- Every engineering hour spent on checkout plumbing is an hour taken from the clinical product, the patient experience or growth.
Custom builds charge for control in time, money, and focus, and most teams underestimate the bill.
A third path: fully managed on the network you choose
Modular infrastructure splits the stack into purpose-built products in place of one monolithic suite or a from-scratch build. Each product works on its own, and you can change one without touching the others. With many modular tools, though, your own team does the setup and connects the pieces.
A fully managed platform gives you that freedom with none of the assembly, and you launch as fast as you would on an all-in-one.
That's thimblehub. We set up and run your checkout and intake, your patient and admin portals, and your brand site, on any clinician network and any pharmacy you choose. No network yet? We match you with one that fits and set it up, and your agreement is with the network directly.
What that looks like in practice
thimblecart is checkout and intake on your brand, from the availability check through intake, plans, and payment. Your own intake form can run inside it, or ours can run after payment. Every paid order goes on to your clinician network.
thimblesites is your brand site, designed and built for you, hosted and kept running by us, and built to LegitScript's requirements. It links to your checkout and portal. Your team can edit the words itself or send us the change, and risky claims get flagged before they publish.
thimbleportal covers the patient and admin portals. Patients get refill check-ins, dose logs, care-team messages, and the option to pause instead of cancel. Your team adds products, sets prices, invites teammates, and reviews refills.
Next to an all-in-one platform
See where patient payments land and who holds saved cards, then run your own numbers next to one OpenLoop proposal Cuvo reported.
See the comparisonYou could start with the checkout, add the site when you're ready to spend on acquisition, and bring in the portal when patient volume calls for a better experience layer. Or start with all three.
Compared with an all-in-one platform, you get the same done-for-you setup and speed, on the network and pharmacy you pick, with your data and payment processor staying yours. Compared with a custom build, you skip months of infrastructure engineering before your first patient.
What to evaluate
The important questions are the same for all-in-one platforms, custom builds, modular products, and managed platforms. Most teams ask them too late.
Provider network flexibility
Can you change provider networks without rebuilding your platform? It's one of the highest-impact decisions in telehealth, and the right answer changes as your business grows. If your platform dictates who you can work with, a software decision is limiting your clinical model.
Checkout and intake iteration speed
Your checkout flow drives revenue directly. Can you test a new intake question, change how prices display, or reorder the steps without filing a ticket and waiting weeks? If not, conversion work happens at your vendor's pace, and in a competitive market that costs you.
Data routing and ownership
Does your patient data reach the systems where you operate? If you use a specific CRM or EHR, does the platform integrate with it natively, or are you exporting CSVs? Data that flows cleanly means less manual work, fewer errors, and faster operations. Data trapped in a vendor's system means your team spends its days working around the gaps.
How fast can you launch on each platform type?
Weeks or quarters? Time to market matters for revenue and for learning. Every week you're not live is a week without real patient feedback, conversion data, or operating experience. Ask each vendor what the launch date depends on and who owns each step, then judge the answer by how specific it is.
What happens when you need to change something?
Most teams forget this question. Six months in, you may need to change one piece of the stack: a new pharmacy partner, a different form builder, a CRM migration. If changing one component means rebuilding three others, your architecture is working against you.
- Can I switch provider networks without a platform migration?
- Can I iterate on checkout and intake without engineering resources?
- Does patient data flow into the systems my team uses?
- How soon can I be live and seeing patients, and what does that date depend on?
- If I need to replace one tool, does everything else keep working?
How the approaches compare
Four dimensions decide most of the difference in day-to-day telehealth operations.
Speed to launch
All-in-one platforms are fast, and several advertise launches in days or under a week. Building your own takes months of engineering. Modular tools move only as fast as the team assembling them. A managed platform moves as fast as an all-in-one, because the vendor does the setup. On thimblehub, you can go live as fast as 3 days after you sign. It takes longer if you still need a pharmacy or clinicians, are waiting on LegitScript certification, want website design revisions, are planning marketing with us, or need custom builds.
Flexibility over time
All-in-one platforms start rigid and stay rigid, and your flexibility ends where the vendor's roadmap does. Custom is flexible by definition but expensive to change, because every modification is an engineering project. A managed platform is built for change, because each piece sits alongside your other tools. On thimblehub, when you move to a new pharmacy or clinician network, we set up the change, and your checkout and portals stay as they are.
Cost structure
All-in-one platforms have predictable monthly costs, but they often include fees for features you don't use and surcharges as you scale. Custom builds cost a lot up front, and the maintenance that follows is hard to predict. On thimblehub you pay for what you use: thimblecart alone if checkout is the need, or thimblesites and thimbleportal too. The fee per order drops as you grow, and there's no revenue share.
Support and partnership
This one is underrated. Large all-in-one platforms can treat you like a ticket number. With a custom build, your support is whoever you can hire. thimblehub is fully managed and white-glove: every request gets a named owner on our team and a promised next update, from setup through launch and after.
Choosing infrastructure that works for you
The right approach depends on where you are now and where you're headed next.
If you're a funded startup with a dedicated engineering team and a long runway before you need revenue, a custom build gives you the most control. Go in knowing what it costs in time and focus.
If you need to be live next week, an all-in-one platform can get you there, and so can a managed platform like thimblehub, on a network and pharmacy you pick or one we introduce. Weigh what each leaves you with a year in.
If you want the network, the pharmacy, the patient data, and the payment processor in your name, with the option to change direction later without a migration project, look for a managed platform that leaves all four with you.
thimblehub gives you the speed of an all-in-one on the clinician network and pharmacy you choose.
Frequently asked questions
- What is modular telehealth infrastructure?
- It means running a telehealth operation on purpose-built components that each own one layer of the stack: checkout and intake, the patient portal, the marketing site, the EHR, and pharmacy routing. It sits between buying one all-in-one platform that ties every layer together in ways that are hard to change and building everything from scratch with custom engineering. You can replace any single piece without rebuilding the whole system. With many modular tools your own team sets up and connects the pieces. On a fully managed platform such as thimblehub, the vendor sets up and runs each one for you, on the clinician network and pharmacy you choose.
- Is modular telehealth more expensive than all-in-one?
- Not necessarily, and over the full picture it often costs less. All-in-one fees frequently include features you don't use, per-patient or per-transaction markups that grow as you scale, and lock-in that shows up as migration cost when you eventually need to change. When each layer is priced on its own, you pay for what you use: a checkout alone if that's the need, all three layers when you want the full stack. The fairer comparison is total cost of ownership over two to three years, including engineering time spent on workarounds, revenue lost to a checkout you can't improve, and the cost of eventually moving off a platform that stopped serving you.
- How long does launch take on a managed platform?
- It depends on your network, your pharmacy, and your intake more than on the software. On a managed platform the integrations and compliance groundwork are already in place, and the vendor configures them around your brand. On thimblehub, you can go live as fast as 3 days after you sign. It takes longer if you still need a pharmacy or clinicians, are waiting on LegitScript certification, want website design revisions, are planning marketing with us, or need custom builds. The first call sets the steps and who owns each one. You bring your products and your brand, plus your network and pharmacy if you have them; if you don't, we match you with a network that fits. We set up your checkout, portals, and site, connect them to your network and pharmacy, and test end to end before you go live. Building your own platform from scratch typically takes six to twelve months, and moving off an all-in-one platform means mapping and migrating your existing data before you can go live.
- Can I keep my existing EHR?
- Usually, yes. The patient-facing layer works next to your clinical systems and sends data to them, so clinicians keep working where they already chart and your ops team keeps its workflows. You aren't asked to migrate medical records or retrain your clinical team to improve the portal or checkout. With thimblehub, we set up the connections for you: each order routes to your clinician network and its status shows back to the patient in the portal. Scale adds a developer API for connecting your own systems.
- What are the risks of all-in-one telehealth platforms?
- The biggest risk is lock-in that compounds over time. On day one an all-in-one platform feels safe, with a single vendor and a single contract to manage. By month six the constraints show. You want to change pharmacy partners and the platform supports two. You want to test a new checkout flow and it's a feature request with a six-week timeline. You want to connect your CRM and the API is thin or missing. You want to leave and find your patient data in a format that's expensive to migrate. The second risk is roadmap dependency. If the vendor drops a feature you need, raises prices, or gets acquired, you have little recourse, because your whole operation is tangled up with their system.
- Is thimblehub modular or all-in-one?
- thimblehub is fully managed, so it launches like an all-in-one: we set up and run your checkout and intake, your patient and admin portals, and your brand site. It runs on any clinician network and pharmacy you choose, and if you don't have a network yet, we match you with one that fits and set it up. Your patients, data, and domain stay yours, payments land in your own payment processor, such as Stripe, and every customer gets a signed BAA. You can start with one product or take all three.
- Who is thimblehub for?
- Anyone starting or running a telehealth business: founders with clinician relationships and an idea, clinicians and clinician groups launching their own offering, DTC brands launching or moving off another platform, and teams whose engineers would rather work on the product than on checkout, intake, portals, and HIPAA plumbing.
Questions, or a topic you'd like us to cover? Book a call or email hello@thimblehub.com.