Sitting together in the same room with the sales team all day long is quite critical for a marketer who tries to deliver the right message to the audience. The good thing is that I can always get a grasp of what stage the deal is at and, more importantly, what topics have been covered during the sales conversations. And one of the most widely covered discussions is definitely the ‘Build vs. Buy’ discussion.
‘You product is great, but… we can build the same thing with our developers’ Does that sound familiar? It is understandable that IT teams, at the early stage, tend to spend a couple of months home-growing a small, tentative solution for mobile test automation from the perspective of financial consideration and basic need satisfaction. But as the needs grow, you will find it’s not sustainable and scalable because of the following three challenges.
Maintenance: Making it from scratch is totally different than maintaining it to be 24/7 functioning. It is an ongoing process that takes up internal resources to maintain the service. And the worst case is, your engineer that build it might move on to another project and you’ll end up looking for a replacement.
Growing needs: Just like enriching features and adding values to your applications, your homegrown solution needs to be evolved and further developed so mobile DevOps teams could enjoy better functionalities and advanced features to support the needs of mobile app development and testing.
Troubleshooting: Service downtime is unacceptable for every business, so is to your homegrown solution. This is especially critical to larger organizations that have geographically distributed teams. When issues occur at the midnight where the solution is built and located, your mobile teams from other time zones will just be suffering time-to-market delays.
Cost, Value and Urgency
The decision around building or buying a mobile DevOps solution from Bitbar or other vendors normally is made based on answering two sets of questions.
- First – What is your company’s core value? Do you really want to allocate resources to build your own mobile DevOps solution versus invest them in your core offerings? Does building your own solution add extra values to your customers?
- Second – How urgent is your need? Would it be ok to constantly delay or slow your mobile app releases for the next 6 months or even one year? How would that impact your competitiveness, brand reputation and customer satisfaction?
Once you get clear of what you are looking for, it is time to calculate the total cost of ownership (TCO). Keep in mind here, instead of solely looking at the initial build or acquisition cost, you’d really need to take into account all the upfront investment and unforeseen cost including license fee, operation cost, change management, training, ongoing maintenance and support. In the landscape of agile delivery, maintaining a not-that-perfect mobile DevOps solution comes at a higher price – low employee productivity, workflow delays, release delays, extra meetings, etc.
At the end of the day, companies that embrace and practice DevOps are looking to reduce application cycle time and bring values to customers faster. If it is not your core competency, then maintaining the homegrown solution is not worthwhile. If you can’t afford the delayed application launches, then investing in a reliable solution to reap the full potential of mobile DevOps is a no-brainer.