Should you buy off-the-shelf software or build custom?
Introduction
So your current software is confusing, inefficient, and doesn’t match your current needs. Most organizations in your position see three basic options:
- Throw it all away and move to an off-the-shelf system. (“Someone has solved this”)
- Completely rebuild the current system making long-sought improvements in the process.
- Tinker with and keep patching current systems. (“It’s not a lot, but it’s what we got”)
Most organizations stick with option 3 until the pain is so great that they start exploring options 1 and 2.
How do you know when to go with an off-the-shelf product vs. custom solution?
Commercial off-the-shelf software is often designed to work for the widest possible audience. So, the selling point tends to be the number of features — all the things their systems can do — with the assumption that more is always better (“It slices, it dices…)”. If your specific business needs line up with the way these features work out of the box, or if you’re willing to change your process to accommodate an existing software tool, then off-the-shelf could be a good fit.
The primary goal of a custom development project, on the other hand, isn’t to create a tool with a long list of features. It’s to identify and understand your exact business needs, develop software that meets these exact needs to help you meet your goals, and build it to adapt over time as those goals evolve. So if a software tool is supporting your critical business functions — processes that make you “you” — a custom solution will save you from compromising the core of what makes your business unique and spending more on features you don’t need.
The custom approach: Start small, test, use feedback, and keep moving
At Pixo, we’re focused on delivering working software quickly. We do this by collaborating with you to define and develop an MVP (Minimal Viable Product), which is the smallest useful version of working code. The MVP approach allows us to try out the vital, highest priority parts of the system, test our assumptions with real people, and use that validated learning to select the next highest priorities for development.
Why don’t we build all features up front? Because it’s better for your users.
Software is supposed to make tasks easier, but can end up making things more difficult if you build based on assumptions and not input from the people who will actually use it. To define the MVP, we start by interviewing stakeholders and end users to gain valuable context and insight that informs design and development decisions. This way, we set ourselves up to create a good user experience (UX), when people can instinctively and consistently understand how to navigate a system, and avoid inefficiencies and frustration that can cause many folks to give up.
Once we have working code, we get it into the hands of as many people as is practical and observe. We expect some things to work well but are looking for what missed the mark. It could be the order, the labels, the flow, or something missing that would provide valuable context to users to help them complete a task. By incorporating this feedback into the app, we will better match user expectations and encourage adoption of the tool.
Weigh your options and business functions
The more peripheral a piece of software is to your operations, the higher chance it is that an off-the-shelf product will work for you. If you’re just looking to create a blog for your website, for example, WordPress will likely serve you well (and you should check out “How to bring modern development best practices to WordPress” from Pixo’s lead web developer Jason Rambeck). But if you need software to serve core business functions — a custom solution is likely worth the investment in the long term.
Considering an off-the-shelf product and want to talk through your options? We’re happy to explore the challenges you have — get in touch.