Nearly every founder building an online prescribing platform gets the same offer at some point. A freelancer, often found on a marketplace, will build the whole thing for a few thousand pounds. Next to a specialist quote it looks like an obvious decision, and we've watched plenty of people take it and then rebuild eighteen months later.
This article covers ten mistakes people make when launching an online clinic, most of which start with that choice. You'll learn what a cheap quote genuinely includes, what it quietly leaves with you, and how to test whether a builder actually understands regulated healthcare.
Key takeaways
- 01The cheapest quote understood the least: a fixed price is calculated against your brief, and in regulated healthcare the brief always misses the parts that matter most.
- 02Nobody will flag what's missing: a generalist builds exactly what you asked for, and won't raise the clinical questions you didn't know existed.
- 03Demos show the happy path: ask to see a rejection, a refund, an abandoned assessment, and a returning patient before you judge anything.
- 04Accountability never transfers: your regulator and the ICO deal with you, not with whoever built the platform, and that stays true long after they've moved on.
- 05Compare two years, not two quotes: build price, subscriptions, your own admin hours, phase two, and the rebuild, or you're not comparing anything real.
- 06Specialists have already made the mistakes: Clinic Pro has built this pathway before, so you're buying decisions that are already correct rather than paying somebody to discover them on your project.
1. Comparing quotes before you can write the specification
The cheapest quote is usually the one that understood the least, and that isn't a criticism of whoever wrote it. Fixed prices are calculated against your brief, so a brief that misses half the pathway produces a number that looks wonderful and describes something you can't run a clinic on.
Here's the trap. You can't write a complete specification for a prescribing platform until you've built one, and you're building your first. So you brief what you can picture, which is the website, the treatment pages, a questionnaire, and a checkout. You get quoted for exactly that, and everything you couldn't picture becomes a change request later, at a price set after you're committed.
| What the brief usually covers | What it usually misses |
|---|---|
| Website and treatment pages | What holds an order while a clinician reviews it |
| A questionnaire | Branching, hard stops, and version history |
| Payments | Refunding what can't be supplied, automatically |
| A patient login | Re-screening and reordering for returning patients |
| An enquiry form | Role-based access and an audit trail |
Read that right-hand column again. It's the entire regulated half of the business, and none of it is in the quote because none of it was in the brief.
2. Assuming somebody will tell you what's missing
A generalist builds what you ask for. That's the job, they're doing it properly, and it's exactly why the arrangement fails in this sector.
If you don't mention what happens to the payment on a rejected order, nobody raises it, because it isn't an obvious question unless you've built a clinical service before. The same applies to assessment versioning, to who can see an uploaded photograph, to what a returning patient does four weeks later, and to what stops an order reaching dispatch without approval. These aren't exotic requirements. They're the basics of the domain, and they're invisible from outside it.
This is the difference you're actually paying for with a specialist team. Not the code, which plenty of people can write, but the list of questions that get asked before anything is built. A team that's delivered this pathway before arrives with the gaps already mapped, because they've been caught by them on somebody else's project.
Test it with one question: what physically prevents an unapproved order reaching dispatch? A specialist describes a control in the system. A generalist describes a person checking a list.
3. Judging the build by the demo
Demos are the happy path, and the happy path is the cheap part. A patient who fits your criteria, answers sensibly, pays first time, and gets approved will look flawless in any build, including one assembled in a fortnight.
Everything difficult lives outside that walkthrough. What happens when a clinician rejects the case, when a payment needs refunding, when somebody abandons the assessment halfway through, when a card is charged twice, when two staff open the same case, or when a patient comes back next month needing more of the same treatment. That's where most of the engineering effort in a real platform goes, and it's why a serious quote looks expensive next to one priced only for the demo.
| What gets demonstrated | What rarely does |
|---|---|
| A suitable patient ordering successfully | A rejection, and what the patient is told |
| The payment going through | The automatic refund when supply is declined |
| A completed questionnaire | An assessment abandoned at question eight |
| The clinician approving | Two clinicians opening the same case at once |
| The confirmation email | A returning patient reordering four weeks later |
Ask to see the right-hand column before you sign anything. Those answers tell you whether you're buying a platform or a very good prototype.
4. Mistaking the price for the cost
£3,000 against £10,000+ isn't a comparison, because the two numbers describe different things. One is a build price. The other is a working clinic.
What the low number leaves out arrives weekly instead. Somebody moves questionnaire answers into the patient record. Somebody chases half-finished assessments. Somebody watches an inbox so a clinician knows there's a case waiting. Somebody issues refunds through a payment dashboard. Somebody handles returning patients by hand because there's nowhere for them to do it themselves. We call that the Integration Tax, and it's paid in staff hours rather than invoices, which is precisely why nobody budgets for it.
| What you're comparing | What you should compare |
|---|---|
| Build price | Build price plus two years of running it |
| Monthly subscriptions | Subscriptions plus the hours spent joining them up |
| The quoted scope | The quoted scope plus the phase two you'll need |
| Launch date | Launch date plus the weeks lost to rework |
| This build | This build plus the rebuild |
Small clinics commonly lose 10 to 20 hours a week to manual work a proper platform would absorb. Price that at any honest rate and the original saving is gone well inside the first year, and you still own the platform that caused it.
5. Assuming regulatory responsibility travels with the build
It doesn't, and this is the one founders find hardest to hear. Your regulator and the ICO deal with you. Whoever built the platform has no registration, no inspection, no accountability, and frequently no involvement at all by the time anybody asks a question.
That means the way your system handles clinical review, record keeping, access control, and evidence is your obligation regardless of who wrote it. The GPhC's guidance for services provided at a distance sets out what's expected of online services, and you'll also be registered with the ICO and paying the data protection fee as a controller of health data. None of those obligations can be delegated to a supplier.
A builder who's never worked in UK healthcare isn't withholding this. They genuinely don't know it applies, so they'll build something that functions perfectly and evidences nothing. You find out when you're asked to demonstrate that a specific clinician reviewed a specific case before supply, and the honest answer is that it's somewhere in an email account.
6. Buying hours instead of domain knowledge
This is about specialism, not geography, and it's worth being clear about that. There are outstanding developers working in every country on earth, and plenty of poor ones within a short drive of wherever you're sitting. Where somebody lives is close to irrelevant.
What matters is whether they've built this specific thing before. A regulated prescribing pathway is a well-defined problem with a lot of non-obvious answers, and the value of a specialist is that those answers already exist rather than being discovered slowly at your expense. When you hire on price alone you're usually buying capable hands attached to no map, which means your project becomes the place where the map gets drawn.
There's a practical test that works regardless of where a team is based. Describe your clinic for ten minutes, then ask them to explain the patient pathway back to you. If they add steps you didn't mention, they've built one before. If they repeat what you said in slightly different words, you'll be teaching them, and you'll be paying for the lessons.
7. Leaving clinical nuance to asynchronous messages
A prescribing platform is decided in dozens of small clarifications, and they're the first thing lost to a long message queue. This has nothing to do with language or competence. It's a structural problem with how detail travels.
Consider a single question like which combination of answers should stop an assessment rather than flag it. In a conversation that takes four minutes and one follow-up. Through a marketplace chat with a significant time difference it takes two days, arrives as a written answer with the reasoning stripped out, and gets implemented slightly wrong. Multiply that by the fifty similar decisions in a real pathway and you can see how builds quietly drift away from what the clinician meant.
The founders who make remote arrangements work do one thing consistently. They write the clinical logic down in full detail before the build starts, rather than answering questions as they arrive. If you can't do that yet, and most first-time founders genuinely can't, you need somebody involved who already has.
8. Not agreeing what happens after handover
Most cheap builds end cleanly, and that's the problem. The project finishes, the invoice is settled, the relationship stops, and you're left holding health data on software nobody is now responsible for keeping current.
It rarely breaks straight away. It just falls further behind each month while continuing to work, until something stops, and by then the person who built it has a full-time job elsewhere and limited memory of your project. Keeping software up to date is among the highest-value protections available to a small organisation according to the NCSC's small business guide, and it isn't a service you got quoted for.
Run the Handover Test before you sign anything. In twelve months, without the person who built it, can you change a price, add a clinician, publish a new page, and apply a security update? Then ask who's applying those updates, what the response time is when something fails on a Sunday, and whether any of it is written down anywhere.
9. Letting phase two be priced after you're locked in
The first quote is competitive because it's a bid. Every quote after it is a negotiation with somebody who knows you've nowhere else to go.
The sequence is predictable once you've seen it a few times. The build launches, gaps appear within weeks, and each fix is priced individually against a codebase only the original builder understands. Nobody's behaving badly. It's simply what happens when the initial scope came from a brief that couldn't have been complete, and the economics of the second phase are nothing like the first.
Deal with this at the start rather than discovering it later. Ask what a new treatment costs to add, what a change to the assessment costs, what happens when a second clinician joins, and whether any of that is included. Then ask what it would cost somebody else to take the project over, and watch how the conversation goes.
10. Building something nobody can migrate you out of
Ask about the exit before you commit to the entrance. It feels premature and it's the most valuable question on this list.
What makes a prescribing platform hard to leave isn't the code, it's the patients. By the time you've outgrown the build you're holding live patients partway through treatment, historic assessments tied to the questions as they were asked at the time, clinical decisions with attribution, order and supply records, uploaded documents, and messages. A migration has to carry all of that across without breaking the clinical thread, and that's only possible if the original build kept it in a structure somebody else can read.
Get three things agreed in writing while you still have leverage: accounts and domains in your own name, full access to everything, and an export of patient data and records in a usable format on request. A builder who's comfortable with all three is probably worth working with. Hesitation on any of them tells you more than any reference will.
When is a freelancer genuinely the right choice?
Often, and it would be dishonest to pretend otherwise. We'd point people towards one for plenty of jobs.
| A good fit | A poor fit |
|---|---|
| A brochure site for an existing clinic | A regulated clinical pathway |
| A landing page for one campaign | Anything holding patient records |
| Design work and brand assets | The clinical review and supply process |
| A specific, well-defined integration | A system you can't yet specify |
| Content, photography, and copy | Anything you'll be inspected on |
The pattern is straightforward. Where you can describe the outcome precisely and you'd know immediately if it were wrong, a freelancer is efficient and sensible. Where the value sits in knowing which questions to ask, you need somebody who already knows, and no hourly rate makes up for not having that.
How a specialist team is actually different
It isn't better code. It's a shorter list of things you'll discover the hard way.
- The questions come first. A team that's built this pathway before arrives with the gaps already known, so your brief gets challenged rather than quoted.
- The unhappy paths are already built. Rejections, refunds, abandoned assessments, duplicate payments, and returning patients are solved problems rather than change requests.
- Evidence is designed in. Attribution, audit trails, access control, and assessment versioning exist because somebody knew they'd be needed.
- There's no phase two to find. The parts you didn't know to ask for are already in scope, because the scope came from experience rather than from your brief.
- Somebody's still there. Maintenance, security updates, and changes have a named owner and a response time.
That's what the difference in price buys. Not more hours, but fewer mistakes, made on somebody else's project instead of yours. If you want the full picture of what belongs in the build before you brief anybody, our guide to starting an online clinic in the UK maps the whole pathway.
Build your online clinic on Clinic Pro
We've built this pathway enough times to know where it goes wrong, which is the only reason this article exists. Clinic Pro is one platform covering the whole clinic, so the gaps above aren't yours to find, fill, or pay for twice.
- A pathway that already works. Treatment page, assessment, clinical review, supply, and reorder designed as one route rather than assembled from parts. See our services.
- Assessments built as clinical tooling. Branching, hard stops, flagging, and version history, written around your protocols. See digital forms.
- Review and records in one place. Role-based access, clinical notes, secure messaging, and a full audit trail, so evidence exists without anybody assembling it. See clinical admin.
- Returning patients handled properly. Short check-ins instead of the full assessment, reordering in a few taps, and approvals routed to your clinical team. See the patient portal.
- Pages that bring patients in. Treatment pages built to rank, published during the build rather than after it. See clinic websites.
- Maintained by us, permanently. Updates, security, and changes are ours. There's no handover cliff and no phase two to negotiate.
If you've got a freelance quote in front of you and you want an honest second opinion on what's missing from it, send it over and we'll walk a patient journey through it with you. We'll tell you if it's fine.
You're not buying a build, you're buying the decisions inside it
The reason a specialist costs more has almost nothing to do with the code. It's that somebody has already made the two hundred small decisions your platform depends on, and made them correctly, after getting several of them wrong on earlier projects.
A cheap quote doesn't remove those decisions. It moves them to you, months later, one at a time, while patients are waiting.
Work out what you'd be taking on. Then decide whether the saving is real.
