I once spent three months on a small task force with one job: prototype a new case management platform fast enough to help leadership answer a single question. Should we build it, or buy it? The prototype itself mattered less than what it taught us about our own requirements. By the end, we understood our data and our workflows far better than we had at the start, and the decision got much easier.
The timeline was tight, the stakes were real, and not everyone started out agreeing on what we were trying to prove. That turned out to be useful. Our job was never to make the prototype win. It was to find the best product for the people who would use it every day and give leadership an honest picture of the options. We put everything we had into the prototype, and then we let what we learned speak for itself. The best idea always wins, and it does not much matter whose idea it was.
That experience shaped how I think about build vs. buy, especially for case management, where the software sits at the center of how case managers and analysts spend their day.
- Data and people come first. The decision comes last.
- The real test is fit, and a quick prototype finds it faster than a feature checklist, even if it is not the option you choose.
- Build, extend, and buy are all valid answers. The best idea always wins.
Select the diagram to enlarge.
The diagram reads from the bottom up. On one side is the data: how a request comes in, becomes part of the system of record, and flows out to the reports and downstream consumers that depend on it. On the other side are the people: the case owners and team leads who will live with the decision, and the engineers and business partners whose job is to challenge it. Both feed one question in the middle, which is whether an option fits the way the work actually happens. Only once that question has a real answer does the choice at the top come into focus.
Fit matters more than features
Build vs. buy conversations tend to drift toward feature comparisons. A vendor demo can check every box on a list and still struggle with your data, your workflows, or your audit trail. The questions that have mattered most to me are less about what a product can do and more about how well it fits the way the work actually happens.
Martin Fowler describes a useful split between utility and strategic systems. Utility functions, like payroll, are necessary but not differentiating, so buying a package and adapting your process to it usually makes sense. Strategic functions are where an organization’s advantage lives, and those often justify building. Case management can land on either side. A generic ticketing workflow is utility. A case process shaped by specific regulations, data sources, and decision points may be strategic, whether the cases are investigations, claims, or customer complaints.
Feature lists are popular because they feel objective. Everyone can count checkmarks, and a spreadsheet full of them looks like progress when a deadline is close. A checkmark only says a capability exists. It says nothing about whether a case manager can get through a real case without three workarounds. Fit is harder to measure, and it is the thing users actually notice.
When time is short, it is tempting to let the checklist decide. A few focused sessions watching people work through realistic scenarios usually tell you more than another week of scoring, and they keep the conversation anchored on the people the product is for rather than on whichever option has the loudest supporters.
I start with the data
Before I look at any vendor, I want to understand our own data model. Where does case data come from? Which systems own it? What has to flow in from intake and alerting, and what has to flow back out to reporting and downstream consumers?
A user interface is a visual layer on top of data, with actions attached. If I understand the data well enough, I can picture how each table and field would sit inside a screen, and I can tell pretty quickly whether a vendor’s model will bend to ours or force us to bend to it. That second case is not always a dealbreaker, but it is a cost that rarely shows up in a demo.
I also want to know who is allowed to see what. Some records are restricted to certain teams, some fields are visible only to certain roles, and some combinations of data are more sensitive than any single piece. A platform that cannot represent those rules cleanly will push the problem somewhere else, usually into manual steps that are easy to get wrong.
Then there is the value of bringing data together. Combining information that used to live in separate places depends entirely on how the data is modeled. When the model is clear and the pieces are modular, new sources can be added and new views built without starting over. When it is not, every new question becomes its own project.
This is also where I spend a lot of time with engineers. I would rather sit with them over the actual tables than send a list of questions and wait. It is faster, and some of the most useful moments in an evaluation come from an engineer pointing at a column and saying, “this one is going to be a problem.”
The questions I keep coming back to
- How unique are our workflows, really? Some of what feels unique is habit, and a vendor’s standard process may be an improvement.
- Where does the data live, who owns it, and how hard is it to get it in and out?
- What does the platform cost to run for five years, not just to license for one?
- What happens when regulations change? Who makes the change, and how long does it take?
- How much can we learn from a quick prototype before we commit?
The last question is my favorite. A few weeks of hands-on prototyping, even a rough one, will usually surface more real requirements than months of documentation. It also gives stakeholders something concrete to react to instead of debating hypotheticals.
Prototypes change the tone of a discussion, too. Build vs. buy debates can get heated. A working prototype gives everyone the same thing to look at. It is much easier for two people who see a problem differently to agree on what is in front of them than on what they each imagine.
Under a tight deadline, it is tempting to treat the prototype as an argument for one side. Its job is to surface the truth about our requirements, including the parts that make a favored option look worse. If it shows a vendor platform handles something better than we could, that is a good outcome.
Extending is a third option
The choice is rarely binary. Many teams already own a platform that can be extended, and low-code tools have made that path more realistic than it used to be. Extending can be the fastest route to value, but it comes with its own trade-offs: you inherit the platform’s limits, and customization can quietly turn a bought product into a built one that nobody planned to maintain.
I like to ask what we would be extending into: how much of the platform we would use as designed, how much we would work around, and who would maintain the custom pieces once the project team moves on. Extensibility only pays off when a platform was built for it.
It is also the option most likely to be set aside early, sometimes because it is not exciting and sometimes because it touches a system someone cares a great deal about. I have found it worth having those conversations anyway, respectfully and early. The people who own an existing platform often know its limits better than anyone, and when they are part of the evaluation, they tend to become partners rather than gatekeepers.
People make the decision work
Whichever way the decision goes, the people who will live with it need to be part of it. I have seen technically sound choices struggle because the users felt the decision was made for them. When case managers and analysts help shape the evaluation, they become the ones who explain it to their peers later.
I also do not expect them to be experts in the data layer. That part is my job. I go to them, sit with their work, and translate what the data could do into terms that matter to their day. Moving records over cleanly, keeping them in one reliable place, showing them where they are needed, and combining them into a single view all sound technical. To a case owner, they mean less swivel-chairing between screens, fewer gates and handoffs to finish a task.
The bigger opportunity is what comes next. A lot of data in older systems is technically there but hard to use. It cannot be reshaped, combined, or asked new questions without a project. When a platform bends to the data instead of the other way around, the data stops being a supporting actor behind each feature. The features are built to serve the data, and that opens the door to things a team cannot do today, like seeing related cases in one place or getting an answer without waiting on a report. I keep the data layer front of mind for my own work, and I keep it subtle in conversations with the business. They care about the outcome, and that is where the conversation belongs.
In the diagram, I split the people into two groups. Case owners and team leads live with the decision every day, so they help shape what we evaluate and how. Engineers and business partners challenge it. Their role is to poke holes, ask the uncomfortable questions, and point out what we are missing. I try to make it clear that challenging the work is a contribution, not an obstacle, and when a competing idea turns out to be the better one, I would rather adopt it than defend my first instinct.
Not every conversation is easy. When timelines are compressed and people care deeply about the outcome, some discussions will be tense. What has worked for me is staying curious, assuming good intent, and showing people how a change makes their own work simpler. Skepticism tends to soften when someone sees their day getting easier, and the people who question an approach most closely often end up helping the most, whether by pointing to a data source nobody had mentioned or catching a workflow detail the rest of us missed.
A lot of this is quiet work: a short conversation before a meeting instead of a surprise during it, credit for the person whose idea changed the direction, and making sure leadership hears who did the hard parts. None of it shows up in a scoring matrix, and all of it shapes whether the decision holds.
What I aim for
The goal is not to win the build vs. buy argument. It is to choose the path that serves the people doing the work for the next several years, at a cost the organization can sustain. Sometimes that is a vendor platform. Sometimes it is a custom build. Often it is something in between. Getting there with a clear view of the data, an honest look at total cost, and the users involved has served me better than any scoring template.
Whether or not the option a team prototypes is the one that gets chosen, the work is not wasted. The requirements it uncovers carry forward into whatever comes next, the data is better understood, and the relationships built under pressure make the next project easier. That is what I mean when I say the best idea always wins. It is not about being agreeable. It is a reminder that the product belongs to the people who use it, and the job is to find what serves them best, together.
Working through something similar? I’m always happy to compare notes. Send me a message or connect on LinkedIn.
This article reflects my own experience and opinions, not those of any current or former employer. It is a personal perspective, not legal, compliance, or implementation guidance. For requirements that apply to you, rely on the current official rules and your own compliance or legal advisors.
Sources
- Martin Fowler, Utility Vs Strategic Dichotomy.