Most teams don’t realize that the operational friction they’re experiencing is a solvable problem. They’ve just kind of gotten used to it. It’s something that builds up gradually, so nothing ever really feels broken enough to fix.
Imagine putting on a backpack and someone puts a book in it—it probably doesn’t feel all that heavy. You then walk around for a little bit and someone puts another book in, and then another book and another book and another book. Each individual book or anything that you put in the bag isn’t going to noticeably change the weight of it. But by the end of the day, when you have a backpack full of books weighing you down, that is a problem and it’s creating a real issue. Which book was it that put you over the edge? It’s really hard to tell. The same holds true with the software your team is using.
There are, however, some symptoms that you can look out for as a mission-driven organization to figure out if your tools are creating unecessary friction:
- You find yourself spending more time moving data between systems than what you might consider “real work”.
- There could be particular people in your organization that have become chronic bottlenecks, not because of something about them or that they’re slacking or anything like that, but more that they’re required. They’re the required bridge between two concepts or data stores or systems, and until they bring that piece of information from one place to another or from their brain into the right place, it can’t move forward.
- Maybe work just feels harder than it used to a few years ago. There’s no real reason that you can identify, but things just don’t work as smoothly as they used to.
And because there’s no clear demarcation of when things become problematic, it’s usually hard to pinpoint the moment in which you realize that something needs to change. If that does happen, it’s usually because you’ve hit some sort of breaking point where things just aren’t simply harder or slower, but they just stop working. That might be because a key person in your workflow who was holding it all together leaves or they’re sick or just burns out. Maybe a particular tool you were relying on stops doing the thing you needed it to do. There’s any number of reasons why it could happen, but you might hit some sort of critical inflection point there. It’s not going to be a gradual realization. At that point, your instinct generally is that you want to just go out and find a tool to solve the problem, but that’s getting ahead of the questions you need to ask first. That first question is: should this be something we buy or something we build?
Off-the-Shelf
For most individuals and organizations, buying pre-made software has simply been the only option available. The costs of custom development have always been prohibitively high. That is now changing dramatically to the point where there’s a real choice to be made for all but the smallest organizations. But just because you can build something custom doesn’t mean you should. For needs where a common use case exists, there are often many well-designed and effective off-the-shelf products available. These should always be the first choice in all but the most-unique circumstances. As the saying goes, don’t reinvent the wheel. So how should you consider whether off-the-shelf is right for you?
When you think about buying off-the-shelf software, there are some costs you need to consider beyond just the monthly subscription fee, whether that’s per person or per organization. Most of these products have tiered pricing plans. Is that advertised price for the tier that includes the features that you need? Also, is that price a monthly or an annual monthly fee (where you have to pay the full year in advance)? What happens when your team grows or your needs change? Going into this exercise with a clear narrative of how you work or a list of requirements will help you determine which pricing tier includes the features you need. Model your total cost of ownership (TCO) across three years. Be sure to factor in your company’s growth and assumed pricing increases.
Beyond the financial costs, there are also workflow and training costs. Just because a program does what you need doesn’t mean it works like your team does. Consider your team’s current workflow. Is it ingrained and specific to your mission? Maybe it’s chaotic and in need of refinement. Your answer may rule out (or highlight) specific applications. Keep an eye out for feature bloat as well. Commercial software is built for the masses and publishers lock their most useful features behind higher pricing tiers. Will you be paying a premium to use only 20% of the included features? That might be worth the investment, but it might also point you towards other options.
Let’s also think about the long-term implications of going with off-the-shelf software. This is assuming you’ve already decided that the monthly (or annual) fees are worth paying indefinitely and that the features meet your needs close enough. For the sake of argument, let’s say long-term means three years or more. At this point, you have 36 months of data in the vendor’s system, you’ve invested thousands (likely tens of thousands) of dollars, and you’ve adjusted your team workflows to match the software. What happens if that vendor goes away, gets acquired, or decides to totally revamp their software?
Thinking beyond the next few years, consider the data you’ve been creating and presumably storing in their system. Can you regain ownership of it? Assuming you can, is it in a format that you can make meaningful use of? At what cost? And in what system?
Finally, consider what 3+ years of working their way will have done to your internal workflows. You’ve remade your processes to follow the vendor’s vision of what good looks like. Is that really the best way for your team to work? If you move off that software will you have to adjust those processes again when you find a new vendor?
Custom
On the flip side, there’s custom development. You can build your own software rather than buying it from somebody, but there are real costs there too. One obviously is the initial upfront cost of building the thing. That’s going to cost you a lot more upfront than the monthly payments for off-the-shelf software. However, that upfront cost is one time and then it’s yours—with some caveats.
The biggest caveat might be what if you build it and nobody likes it? If you build something without the proper upfront discovery and research, chances are you’re going to end up having built the wrong thing (unless you’re building software purely for yourself). You likely have good ideas for what people need. However, until they are put to the test with your actual audience, it’s really hard to know if that’s going to meet their need or not. You’re rolling the dice on a hunch worth tens of thousands of dollars. You need to do that upfront discovery. If you do that right, then you can get to a very confident MVP rather than an expensive guess.
Once you’ve built and launched your MVP, you get to reap the rewards of a tool built expressly for your team—but the work doesn’t stop there. MVP stands for minimally viable product, meaning that it’s just barely able to do the job. You’re likely going to have many tweaks, enhancements, and fixes you’ll want to implement in the first year. You likely built for the happy path…but what happens when work goes a bit off the rails? Your app should allow for that. Will it support the new service offering you’re rolling out in four months? What if two months in, everybody gets new devices with dramatically different specs and now the content renders weird? These are all common and expected issues that will arise once you launch…and they won’t stop coming. You’ll need an in-house team or development partner to cover these eventualities.
Building your own software can be great because you decide what the features are and how they work. But you are also the product owner and responsible for any future feature development. No one else is going to do this for you, so you either do it yourself or you pay someone to help, but those features don’t develop themselves.
The decision between off-the-shelf or custom software is truly a balancing of trade-offs. Neither one is inherently better than the other; they just have different pros and cons. While the opportunity to find a perfect match are greater than ever, it can be a confusing and overwhelming decision to make.
Once you’re ready to dive into this exercise, start with these foundational considerations:
When evaluating off-the-shelf tools, consider how they match the way your team actually works. If you’re able to do a demo or do some testing with that, maybe it works exactly the way you want it to, and that’s great, but try it out first. It also helps to have a list of key features, workflows, or requirements so you can evaluate each product equally.
Dig in beyond the monthly fees. Consider the true cost of ownership across the next three years. If you’re paying this regular monthly fee in perpetuity, what are you getting after three years versus if you’re paying more of an upfront fee with much lower maintenance costs for custom development? Beyond just the licensing fees what about workflow modifications or employee training and onboarding?
Weigh the importance of this tool in your workflow against your (lack) of control over its development. If you have truly sensitive data that you’re worried about sharing with anybody, maybe that’s a thing you need to build yourself to have control over the security and residency. Or you may want to have that data available to do different things with easily. These could be reasons to go down the custom route. If you don’t have a very long list of items or features that you need and aren’t concerned about the development of that product over time, maybe that’s more of an off-the-shelf approach for you.
The goal through all this, though, isn’t just to find the right software; it’s to find the right fit for how your organization operates and how it’s grown over time and will grow in the future. Once you understand those things, the choice should become far more obvious.
The software options before small and medium-sized organizations are greater than ever before. If there isn’t a tool out there that will help ease your team’s specific burdens then you can have one built. But the tyranny of choice can lead to analysis paralysis. You can head that off, however, with a thoughtful and forward looking approach to your search by weighing the topics covered above.
If the question of build-vs-buy is top of mind for you, Fabrik Labs built a free self-assessment to help you explore this topic further. In 5 minutes or less it will provide you with recommendations on actionable next steps you can take, specific to your organization and current challenges. Whether you’re well on your way to making a decision or just starting out, it can help you narrow in on the right approach.