{ CASE STUDY DETAILS }
The problem, the decisions we made, and what actually changed for the client after launch
PROJECT NAME:
Clinic Management System
INDUSTRY:
Healthcare
ENGAGEMENT:
Full system build
PLATFORMS:
Web app, front-desk terminal
TOOLS USED:
Next.js, Node.js, PostgreSQL, Redis, AWS
LOCATION:
Dhaka, Bangladesh
Six doctors, a paper appointment book and patient histories in folders meant the clinic could not reliably answer who was booked when, what a returning patient had been prescribed last time, or how busy any doctor had actually been. The brief was to make availability, history and reporting into data — without asking a busy front desk to work harder than they already were.
A Paper Book Running A Six-Doctor Clinic
Appointments lived in a ledger at the front desk, patient history lived in a folder, and doctor availability lived in whoever happened to be on shift. Double bookings were routine, a returning patient's history often could not be found in the time available, and nobody could answer how many patients a given doctor had seen that month without counting by hand.
Key issues identified:
Availability As Data, Records As A Timeline
Each doctor's working pattern — days, hours, slot length, leave and breaks — is configured once and generates bookable slots automatically. The front desk can only book a slot that exists and is free, which removed double bookings by construction rather than by care. Patients get SMS reminders, and a cancellation releases the slot back immediately.
The patient record is a single timeline: visits, diagnoses, prescriptions and uploaded reports in date order, searchable by phone number or name. Prescriptions are written from a structured drug list with dosage templates, so they print cleanly and stay legible in the history. Role-based access separates front desk, doctor and administrator, and every record change is audited.
Remove The Chance To Make The Mistake
The double-booking problem was not solved by a warning dialog; it was solved by making an unavailable slot impossible to select. Most clinic software problems are the same shape — a process that depends on someone remembering something, replaced by a system where the wrong action cannot be taken at all.
What this project reinforced:
Double Bookings
0
Slots are generated from each doctor's working pattern, so an unavailable time cannot be selected at the front desk at all.
Record Retrieval
Seconds
A patient's full visit and prescription history is searchable by phone number, replacing a folder hunt during the consultation.
Doctors Scheduled
6
Six concurrent practitioners run on independent availability patterns, including split shifts, leave and variable slot lengths.
Reporting
Daily
Patient volume, no-shows and per-doctor utilisation are available the same day, so staffing decisions stopped being guesswork.
We do not just finish projects — we stay on after launch. Here is what the teams we shipped for have to say.
We were selling groceries, pharmacy items and household goods out of systems that did not talk to each other. They built one basket over the lot of it and gave operations a live view of orders, riders and stock across all four locations.
Boshir Ahmed
Signature Bangla
They scoped it honestly, told us which features were not worth paying for yet, and shipped on the dates they gave us. The questions they asked before writing anything were the useful part.
Shafin Ahmed
Textalyz AI
Every update arrived when they said it would, and we could open the thing they had built at the end of each one. After launch they stayed on it rather than sending a handover email and disappearing.
Redwan
Rongobuy
Still have questions?
Ask us anything
// A focused MVP usually ships in 8–12 weeks. Larger SaaS platforms and multi-tenant systems run 4–6 months, delivered in two-week increments so you see working software throughout rather than at the end.
