Custom CRM Development: Replacing Paper and Spreadsheets With One System
Paper, spreadsheets, and a booking app that didn't fit. One custom CRM replaced all three.
G
Georgiana Nutas
·9 min read
Custom CRM development is often talked about as a luxury, something only large companies with large budgets can justify. This case study runs the other way. A client came to us running several optometry offices on a mix of paper files, spreadsheets, and a generic booking app that was never designed for eye care. Nothing connected to anything else. We built them one system that did. Here is how the project actually went, what we chose to build, and what any founder can borrow from it, with no invented numbers to make the story look better than it was.
The client did not walk in asking for "a CRM." They asked for a way to stop losing time. That distinction matters, and it shaped every decision that followed.
The starting point: a handful of tools that never spoke to each other
Every office ran as its own island. Patient details lived partly on paper, partly in spreadsheets, and appointments sat in a generic scheduling tool that had no idea what an optometry consultation involves. A prescription written last year might be in a folder, in a spreadsheet cell, or in someone's memory. To pull a patient's full history, a staff member often had to check two or three places and hope the most recent version was the one they found.
If that sounds familiar, it is because it is extremely common. Around 90% of organizations still keep some of their most important business data in spreadsheets, according to research reported by TechRadar. Spreadsheets are easy to start with and quietly expensive to keep. The moment more than one person edits them, versions drift, and small errors creep in. A mistyped prescription or a double-booked slot is not a rounding error in a healthcare setting.
The deeper problem was not the spreadsheets themselves. It was the gaps between the tools. When information is scattered across systems that do not connect, people spend a surprising amount of time just locating it. Forrester Research, cited by J.P. Morgan, found that knowledge workers lose roughly 12 hours a week chasing data across disconnected systems. For a small team running multiple locations, that is not an abstract figure. It is a receptionist on the phone while a patient waits, digging for a record that should take two seconds to find.
Multiply that friction across several offices, several staff members, and a full day of appointments, and you get the situation the client described to us on the first call: everyone was working hard, and the tools were the reason it felt harder than it should have.
Tagged:#CustomCRM#CRMDevelopment#SaaS
G
Written by
Georgiana Nutas
Building modern web applications at BluDeskSoft. We write about what we learn along the way.
Why "just buy something" was the wrong answer here
The obvious question is why not buy an existing optometry or practice-management product. Plenty exist. For this client, none of them fit cleanly.
Generic CRMs are built for sales pipelines, not clinical workflows. Practice-management suites tend to be heavier, priced for larger chains, and packed with features this client would never touch while still missing the specific ones they needed. Every option on the table would have forced the team to bend their process to the software, rather than the other way around. And because the client operated several offices with different staff and different roles, they needed clean separation between locations, which most ready-made tools handle awkwardly, if at all.
Build versus buy is a genuine tradeoff, and buying is often the right call. We tell clients that regularly. A subscription you can start tomorrow beats a custom project you wait months for, most of the time. Here, though, the workflow was specific enough and the multi-office requirement central enough that a tailored build was the more sensible long-term option. They would own the system outright, and it would match how they actually work rather than approximate it.
What we built
We designed the system around the real sequence of a visit: booking, consultation, charting, and prescription. Not around a feature checklist.
The core of it is a real-time dashboard that shows each office its day at a glance, including the appointments booked and how the day is progressing. Booking runs on a proper calendar rather than a spreadsheet, so the front desk can see availability without cross-referencing. Patient records hold what optometry actually needs, including illness history and glasses prescriptions, in one place instead of three.
Access is scoped by role and by office. A staff member sees only their own location and the parts of the system their role requires, which keeps the interface simple and keeps sensitive records where they belong. And because so much of an optometrist's day involves paperwork, the system generates medical letters directly rather than having someone rebuild the same document by hand every time.
None of these features are flashy on their own. Booking calendars are not new. Neither are patient charts. What makes the difference is that they live together, in one system, with one login, showing one version of the truth. Together they replace the daily friction of hunting, re-typing, and double-checking with a single place to work.
The technical decisions behind it
For anyone weighing a similar build, the stack matters less than the reasoning, so here is both.
The front end is built with Next.js and TypeScript, styled with Tailwind CSS. In plain terms, that combination produces fast, reliable pages and code that stays maintainable as the application grows, so features can be added later without the whole thing becoming fragile. For data handling, we used TanStack React Query and React Hook Form, which keep the interface responsive and the data entry clean. A medical CRM lives or dies on accurate input, so the forms doing the heavy lifting was not a detail we skipped over.
The back end runs on Supabase, which bundles a managed Postgres database, authentication, and file storage into a single platform rather than stitching together several separate services. That let the team move quickly without babysitting infrastructure. We have written before about when Supabase is and is not the right choice for production, and this project sat squarely within its strengths: a relational database, real security requirements, and a client who wanted to launch without unnecessary overhead.
The most important architectural decision was multi-tenancy, the ability for many separate offices to run within the same application without ever touching each other's data. Each office operates independently, with its own users, roles, patients, and schedule. We enforced that separation at the database level using row-level security, so one office simply cannot query another office's records, even by accident. That is not something you bolt on later. Deciding it at the start is exactly what turns adding a new office into a matter of onboarding rather than rebuilding.
For a system holding patient histories and prescriptions, that isolation is also a safety property, not just a convenience. Keeping each office's data walled off by default is far easier to reason about, and far easier to trust, than a shared pile with permissions layered on top after the fact.
From fragmented to unified: what actually changed
This is the part where a case study is tempted to invent a number. I am not going to. We did not run a controlled before-and-after measurement, and pretending we did would be dishonest and easy to see through. What we can describe honestly is how the work changed.
Before, pulling a patient's history was a small scavenger hunt across paper and sheets. After, it is one record on one screen. Before, each office kept its own spreadsheets and quiet conventions, so nothing was consistent across them. After, every office works in the same system, which means a process improvement in one location applies everywhere at once. Before, opening a new office meant starting a fresh pile of files and a fresh set of spreadsheets. After, it means creating accounts and assigning roles.
The receptionist is not toggling between a folder, a spreadsheet, and a booking app to answer one question. The optometrist is not waiting on the front desk to track down a letter from six months ago. The owner can glance at a dashboard instead of calling each office to ask how the day is going.
The value is not a percentage we can drop onto a slide. It is time that used to vanish into looking for things, handed back to the people doing the work. That is the quiet return on custom CRM development that rarely makes it into a headline. It is less "revolutionary growth" and more "the day stops fighting you." In our experience, the second thing is what actually keeps a small-business owner sane.
What founders can take from this
A few lessons carry over to almost any custom build, whether you run optometry offices or something else entirely.
Start from the workflow, not the feature list. The client's system works because we mapped it to booking, consultation, charting, and prescription, in that order. Any feature that does not serve the real sequence of work is just clutter you pay to maintain forever.
Decide the hard structural things early. Multi-tenancy and role-based access are painful to retrofit and straightforward to design in from the beginning. If you already know you will serve multiple locations, teams, or clients, build for that on day one rather than promising yourself you will "add it later."
You do not need everything at launch. A focused system that does the core job well beats a sprawling one that does everything poorly. You can always extend a clean foundation. Untangling a rushed one is a different kind of project, and a more expensive one.
Weigh ownership honestly. Off-the-shelf tools are faster to get started and are often the right choice, especially when your process looks like everyone else's. But when your workflow is specific and central to how you operate, owning software that fits you exactly can be worth far more over time than renting software you constantly have to work around.
Wrapping up
This was not a moonshot. It was a practical build that took a business off paper and out of disconnected spreadsheets, putting it on one system that matches how the team actually works. No invented metrics, no drama, just fewer places to look and less time lost between them.
If you are sitting on a stack of tools that do not talk to each other and wondering whether a tailored build is worth it, that is exactly the conversation we like having. You can see more about this project on our optometry CRM case study page, read about how we approach our own builds, or just tell us what your current setup looks like, and we will give you a straight answer about whether custom is the right call. Start the conversation at bludesksoft.com.
We built great sites for clients while our own sat broken. Here's how we fixed it in 4 weeks.
BluDeskSoft-1600x900.webp)
