When we started building FalconCare, our polyclinic ERP, we thought the hard part would be the code. It wasn't. The hard part was understanding how a clinic actually runs on a busy Monday morning — and then making software disappear into that flow instead of fighting it.
This is a look back at what shipping a real product taught us: the decisions that aged well, the ones we'd make differently, and what it really takes to get software into the hands of people who don't have time for software.
Start with the messy reality, not the happy path
Every clinic we visited did things slightly differently. One ran on a whiteboard and a shared notebook; another had three disconnected tools that no one trusted. The temptation is to design for the version of the workflow that's clean on paper.
We did the opposite. We sat at the front desk, watched receptionists juggle phone calls and walk-ins, and built around the interruptions. The patient lookup had to be instant because there's always someone waiting. The invoice had to print in one click because the queue doesn't pause.
If a feature needs a training session to use, it's not finished. The front desk should be able to learn it between two patients.
One source of truth, or none at all
The single most important architectural decision was refusing to let data live in two places. A patient's history, their appointments, their invoices, and the doctor's payout all reference the same records. Nothing is copied; everything is linked.
That sounds obvious until you're under deadline pressure and a shortcut would save a week. We held the line, and it paid off the first time a clinic asked for a report we hadn't explicitly built — the data was already connected, so the answer was already there.
Roles are a feature, not an afterthought
A receptionist, a doctor, and an administrator see three different products even though it's one system. We learned to treat role-based access as a core feature rather than a security checkbox:
- Reception sees the queue and billing, not the financial reports.
- Doctors see their patients and prescriptions, not other doctors' payouts.
- Admins see everything, with an audit trail behind it.
Getting this right early meant we never had to retrofit permissions onto screens that assumed everyone could see everything.
Onboarding is where products live or die
The best feature is worthless if a clinic can't get their existing data into it. We spent real engineering time on bulk import — messy spreadsheets, inconsistent date formats, duplicate patient names — because that first import is the moment a clinic decides whether to trust you.
When a clinic sees their own patients show up correctly on day one, the rest of the adoption takes care of itself.
What we'd tell our earlier selves
Ship the boring parts well. Nobody is impressed by a clever dashboard if the invoice is wrong. Make the everyday actions fast, make the data trustworthy, and earn the right to add the impressive features later.
If you're building software for a domain you don't live in, go sit in it. The product gets better every time you watch someone actually use it.