Buy vs. Build: Digital Product Development
At RevUnit, one of the many decisions we help our clients navigate when taking on new projects is whether or not to buy an existing technology or build from scratch. As with most technology & digital product development questions, the answer typically is “It depends.”
What follows are a few of the questions we work through in making the decision:
Is this feature or component core to your business?
If something is core to your business, you will probably want more control and be unwilling to compromise on features. For example, if you are building an online dating site, you should probably own and have complete control over the code and algorithms to match potential partners. In that case, it probably makes sense to build that particular component. However, if you are a web-based startup and your app needs to send emails, it’s probably not worth setting up and maintaining your own mail servers. Just pay someone a few bucks a month and consider it a solved problem.
How important is it for you to differentiate?
This is somewhat related to the previous point, but if you are looking to truly set yourself apart from your competitors in a particular area, building makes a lot of sense. Just remember that if you can purchase an off-the-shelf solution and have it live in a month, so can your competitors.
Does it do everything you want it to do?
Prior to vendor evaluation, have you defined what features need to be present to solve the problem at hand? If not, you run the risk of becoming enamored with a solution and compromising on what you originally set out to accomplish. If you have documented those features, make sure that the potential solution can meet all of those needs. If it doesn’t, you’ll need to decide if the potential cost savings is worth losing a desired feature.
Does it do too much?
A mistake that a lot of folks make is choosing a solution that has a ton of options that look great on a feature matrix spreadsheet. However, when it comes down to it, only a small amount of those features are really relevant. This can lead to longer implementation time as you struggle to turn off or hide a number of features you don’t want. A cluttered and confusing interface can lead to lack of adoption just as easily as missing features.
Does the vendor’s long-term roadmap align with yours?
Can the vendor articulate where they want to go with their product? Is that roadmap heading the same direction as yours? If your product is successful, you’ll have a long-term relationship with this particular vendor. You want to ensure that they’ll still be around and still be focused on helping you grow your business a few years from now. Things to watch for here are the age of the company, whether or not this is a side-project or their core offering and whether or not they are on the cutting edge of technology in their space.
We love building new products for our clients (a process called digital product development), but the part that we love the most is solving the unique business problems at hand. If someone else has a great existing solution that helps us solve those problems more quickly, we’ll recommend it.
So in summary, buy where you can but build where it counts.
In our work with companies across industries like CPG, retail, and transportation/logistics, these few guiding questions have continuously risen to the top — check out our Build Vs. Buy decision-making flowchart next.