What a solo doctor needs, and what a ten-doctor clinic needs

Vendors sell the same product to a solo practitioner and a ten-doctor polyclinic, then price it differently. The feature list barely changes.

That is backwards. The feature list is not what changes with size. The failure mode is. What goes wrong in a one-doctor clinic is not what goes wrong in a ten-doctor one, and buying for the wrong failure mode is how clinics end up with software that is simultaneously too complicated and not enough.

One doctor: the queue and the record

With a single doctor, almost every problem is the same problem — the waiting room.

There is no coordination overhead because there is nobody to coordinate with. The doctor and the receptionist can simply talk. Roles and permissions solve a problem you do not have.

What you actually need:

• Registration that takes under a minute, including a returning patient found by phone number
• A visible queue the front desk and the doctor both see
• A prescription that prints or sends without retyping
• Records that come back instantly when the same patient returns in eight months
• Money in and money out, simply

What you do not need: multi-role permission matrices, departmental workflows, elaborate approval chains, analytics dashboards nobody will open.

The commonest mistake at this size is buying hospital software at a discount. It will work, technically, and every task will take four clicks more than it should — which across forty patients a day is the whole margin of the working day.

Two to three doctors: the handoff appears

The moment there is more than one doctor, a new failure mode arrives: the handoff.

A patient seen by one doctor last month sees another today. A nurse takes vitals for whoever is free. A prescription written in one room is dispensed in another. Nobody can hold the whole picture in their head any more, and the informal system that worked with one doctor quietly stops working.

What you need on top of the solo list:

• One shared record each doctor can see, with a clear history of who wrote what
• A queue that assigns to a doctor, not just a single line
• Notes readable by someone who was not in the room — this is a culture problem as much as a software one, but the software should make good notes easy
• Basic separation between what the front desk sees and what clinical staff see

This is also the size at which no-shows and scheduling start to cost real money, because an empty slot for one of three doctors is harder to fill on the fly.

Four to ten: roles stop being optional

Past three or four doctors, plus nurses, plus a pharmacy or lab counter, two things change.

Permissions stop being paperwork and start being protection. With a dozen people touching records, "everyone can see everything" is both a data protection problem under the DPDP Act and an operational one. You need roles that reflect real jobs, and an audit trail that answers who opened a record and when.

The clinic stops being visible from one desk. Nobody can see the whole day any more. That is when reporting becomes genuinely useful rather than decorative — which doctor is running late, where the queue is backing up, what the pharmacy is short of.

What you need here:

• Real role separation, with an audit trail
• Modules that connect — a prescription reaching the pharmacy counter without paper, a lab order returning to the doctor who raised it
• Reporting a manager will actually use daily, not a dashboard for an investor
• Concurrency that holds — ten people in the system at once on a Monday morning

Buying ahead of your size

Tempting, and usually wrong. Complexity has a running cost: more setup, more training, more clicks per patient, more things to get wrong. A solo doctor running a ten-doctor configuration pays that cost every day for a capability that is not needed yet.

The better protection is not buying big — it is buying something that adds modules and users without a migration. Ask what happens when you add a third doctor, or switch on a pharmacy. If the answer involves reimplementation, that is the constraint that matters.

Buying behind your size

The opposite failure is quieter and more expensive. Software that fits three doctors will run at seven — badly, with workarounds accumulating until somebody proposes a spreadsheet alongside it.

The signals you have outgrown it: staff maintaining a parallel record "because it is faster", nobody trusting the reports, and the same reconciliation being done by hand every evening.

The practical version

Buy for the failure mode you have now, from someone whose product grows without a migration.

At one doctor, optimise the queue and the record. At three, fix the handoff. At ten, fix roles, connections and visibility.

And judge any demo by your busiest hour rather than your calmest — the difference between sizes shows up under load, and nowhere else.