Build vs Buy: Scheduling automation software
Building software can be an exciting journey.
However, in our fast-evolving tech industry, many great ideas go to market daily. This means that every extra day you spend developing, your competitors spend selling their product. Generally, you’ll want to build the modules that capture the value proposition of your product yourself, but buying parts of your system is an effective way to accelerate your time-to-market.
Scheduling automation is growing in popularity, saving considerable time for businesses and individuals alike. They can use this automation for scheduling meetings, interviews, and appointments. However, automated scheduling is one of the most complex features to self-build.
In this article, I'll draw on my own product development experience to best advise whether you should build or buy your scheduling automation software and where it is in your product roadmap.
Pretotyping vs. Prototyping vs. MVP (minimum viable product)
Each product has to go through several different stages. The first three of them are pretotyping (optional), prototyping (required), and MVP (required). We realized that we should buy our scheduling automation at the MVP stage of product development. I’ll briefly explain what each stage looks like to provide some context.
Pretotyping
Pretotyping is a term that I first heard from 'Pretotyping It' by Alberto Savoia. Alberto’s main point is that you should build the right 'it' before you build 'it' right. He disincentivizes any software development before you are absolutely sure that you've got the proper demand. For instance, if you have an idea for a new product, build a sales page with a ‘Buy’ button before it has been created. In this way, you'll see if anyone is actually going to buy it. If you spend $1000 on ads and no one has tried to purchase your product – there's no point in building it.
Understandably, many Developers are wary of taking this approach. It sounds outrageous to sell a product that doesn't exist. But the more I work with products, the more I realize that while this is extreme, pretotyping points us in the right direction regarding product development.
Prototyping
Prototyping is much more natural. When talking about a product prototype, we usually mean a first version of the product, which is very rough. It doesn't work perfectly and hasn't covered any edge cases. A prototype usually does the main job and shows what a product could be. In the context of building a prototype for any scheduling system, buying an existing solution saves a substantial amount of time and effort as it's a complex system to build.
A prototype should take you a couple of days at most. Your scheduling-related prototype could be some proprietary code on top of a ready-made solution.
MVP (minimum viable product)
A minimum viable product is the most basic version of whatever product you are building. Many people confuse the prototype stage with the MVP. While they can be the same thing, usually an MVP is a working product that could be sold but only has basic features. A prototype may be a broken, half-code half-image software whose whole purpose is to prove a point. An MVP should be a product that works well enough to be sold to customers but doesn't have any advanced capabilities.
If you are building your MVP you have one goal: build it and sell it as quickly as possible. It's all about the time from idea to market. The fastest way to achieve this is by buying parts of the system like scheduling automation and building the rest.
“Generally, you’ll want to build the modules that capture the value proposition of your product yourself, but buying parts of your system is an effective way to accelerate your time-to-market.”
Product value proposition
The first and most important question you must answer for yourself is, “why are people buying my software”?
In our company, 3veta, we used the Cronofy scheduling automation API to build our MVP. We realized that our value proposition centers around team collaboration and team communication. We bring together white-label video conferencing, booking pages, appointment reminders, payments, and various other types of team collaboration. In other words, we are selling an “all in one place” solution.
It’s essential to realize that each of the problems we solve has been solved before; Zoom works for video conferencing, Stripe for receiving payments, etc. Therefore, our value proposition lies in our ability to make the remote-work process as simple as possible for teams by providing all of these capabilities at once.
Build vs buy: factors to consider
We needed automated scheduling to help us reach our goals and beat the competition, and had to decide whether building or buying was the better option for us. Here are the factors we took into consideration.
Time
When weighing up the pros and cons, one of the main issues for us was how time-consuming building ourselves would be. For each day we would spend on building the scheduling system, we lose an opportunity to further our team collaboration edge. For instance, it could take us six months to develop a proprietary scheduling automation system. That means in six months’ time we would be in the exact same spot product-wise as we are right now.
As we were assessing whether or not to build or buy scheduling automation, I went to our CTO and asked him about his perspective.
“Automated scheduling is one of the most difficult features to build, especially when considering time zones”, he told me. “My opinion is to buy a ready-made solution and focus our efforts on the other elements of our offering.”
Buying a scheduling API has given us more time to focus on making the product as high-quality as possible in a shorter time, allowing us to generate profit quicker.
Cost
Costs can quickly pile up when building a new product. You have to factor in the spending on the initial build, support, testing, upgrades, and the state of the market, while also preparing contingency plans if things don’t turn out as expected. According to the Pulse of the Profession study from the Project Management Institute, one in six IT projects have a cost overrun of 200% due to delays. As I mentioned previously, building scheduling automation is time-consuming and can add up to substantial delays to your product timeline.
Still, the consideration that most often deters businesses from buying software is the price. True, it can require a considerable upfront cost, but the long-term investment is undeniable. Since it’s ready to use, there are no unpredictable issues on the development side. It saves you from all the financial headaches associated with building in-house software.
“Building scheduling automation is time-consuming and can create substantial product timeline delays. These delays have huge cost implications; according to the Pulse of the Profession study from the Project Management Institute, one in six IT projects have a cost overrun of 200% due to delays.”
Security
Security is crucial, especially as many tech businesses deal with incredibly sensitive data. It’s important to consider access to information and the limits necessary. You may opt to build your own firewall of safety and reduce the risk of data leaks. You can put restrictions on the tools you buy, or build your own firewall to reduce the risk of data leaks. If you are going to buy scheduling software, choose a provider with the highest level of privacy controls and security certifications. A confidentiality agreement with service providers also protects you, eradicating any risks.
Security was a big contributing factor in why we chose Cronofy as our scheduling partner, as they meet the highest quality standards and run a robust security program. From the outset, the team emphasized that security was of utmost importance to them, and they prioritized that above all else.
Maintenance
When you build yourself, your team is responsible for launching, maintaining, updating, and fixing any bugs that may crop up. This is a lot of additional work for tech teams that are likely already at their full bandwidth, and could result in you needing to make additional hires to deal with the increased workload.
Buying software means the provider handles all the maintenance behind the scenes and includes the cost in your subscription. Their team can help launch the platform, manage maintenance, and push out product upgrades.
With Cronofy, we knew their team had a wealth of experience in providing automated scheduling as an add-on solution for products like ours, so we could trust they knew the best practices for launching and maintaining the solution.
Control
As a buyer, you never have total control over a SaaS platform’s product roadmap. If you choose to build in-house, you have 100% of the control over how software functions. However, with that control comes a great deal of responsibility. You make all the decisions, and that can create burnout among busy teams. Buying lessens the heavy burden, and if you select the best provider for you, they should be open to suggestions. With our journey, Cronofy was always quick to respond to our feedback and make the relevant changes. Ask these questions at the demo stage of the buying journey to ensure the provider is flexible and there should be no issue with buying a solution.
To build or to buy?
After weighing up the pros and cons, it’s time for the decision: will you build or buy? From what we now know, building scheduling automation in-house is a time-consuming, complex task that can result in increasing overrun costs and burnout for your team.
Building, launching, maintaining, fixing and updating any software is a huge undertaking. When you work with the right scheduling automation provider, the burden is lifted, leaving your team time to focus on your product's core value proposition features.
To sum up: don’t build it, just buy yourself some time.
Iliya Valchanov is Co-Founder and CTO of 3veta.com; an end-to-end solution which integrates video conferencing and scheduling automation for better team collaboration. He is also Co-Founder of 365 Data Science, and is a Data Science Instructor on Udemy with more than 800,000 students.