Scheduling Functionality Build vs. Buy Whitepaper
Building a scheduling solution internally may seem like a simple feat until one considers all of the features required for the smooth and effective operation of basic scheduling.
Like every other cloud-based solution, our scheduling platform is tied to and reliant on a cloud service provider. We use Microsoft Azure as the cloud host of OnSched.
Just like many companies outsource hosting, many companies outsource entire services. Herein lies the justification for Software as a Service (“SaaS”) solutions. Companies outsource to SaaS providers because outsourcing in this case means to transfer the responsibility of delivering reliable scheduling to the company whose core proficiency and sole objective is the delivery of reliable scheduling services. Under this business model, the SaaS provider assumes care and responsibility for maintenance, developing cutting-edge features, product updates, and compliance with legal regulations.
Finally, the most profound justification for outsourcing is that doing so will be cheaper than building the solution internally.
BUILD
At the outset, it is important to note that when we discuss “building” a solution, we mean this to encompass the design, development, testing, training, and implementation of the software. This is undoubtedly a massive undertaking, and so the first question one should consider is:
Is my project big enough to commit to building your own scheduling service?
Services like Amazon Web Services, Microsoft Azure, and DigitalOcean exist because economies of scale allow them to. To analogize, it would be virtually impossible to build a more cost-effective hosting solution for your business. Considering the possibility of failure of the project, the opportunity cost just may not be worth it.
We would argue that the same logic applies in developing a complex web service, such as scheduling: given the complexity involved in the solution and the high likelihood of encountering failure, it is not advisable to build out a scheduling solution from the ground up.
In our experience, the below scope represents a high-level outline/roadmap of what is typically involved in an enterprise build-it-from-ground-up-project:
PHASE 1 - DESIGN AND CONSULTATION
Product manager (1 FTE)
18-month minimum engagement;
Management of all aspects of the project and solution.
Analyst (1 FTE)
4-month minimum engagement;
Consult with external and internal stakeholders; and
Investigate the use case and scope-out all workflows to hand off to the design team.
UX & UI Designer (1-2 FTEs)
4-6 month minimum engagement; and
Build-out wireframes all the way through final designs
Depending on the agility of the organization, the Design and Consultation Process requires a 3-4 person team and upwards of six months of exploration, consultation, and discovery before the project commences in earnest with the development team.
After the preliminary design and consultation phase:
PHASE 2 - BUILD, TEST, and MAINTAIN
Senior back end developer (2 FTEs)
12-18 month minimum engagement;
Front end developer (1-2 FTEs)
12-18 month minimum engagement
Security tester (1 FTE)
1-6 month engagement.
QA tester - 2 months
This is a high-level assessment and is not meant to be instructive but rather illustrative of our experience.
At a base-level of functionality, that is what we believe would be required to achieve a minimum viable product. We submit that most enterprise organization lack the agility that companies such as ours have and - these estimates would accordingly be larger.
That said, a fair middle-ground assessment is that one should typically anticipate a team of 9 FTEs involved in the project from start to finish, with at least 4 others for 2-6 month periods in between - working anywhere from 12 - 24 months.
Conservative estimates suggest that a build from the ground up would cost ~$800k in hard costs. More likely $1M+ and 18 months to do it properly. This doesn't take into account the custom integrations that would have to happen across the board. Once you get into security permissions and different levels of the organization, it can easily draw out the timeline well past 18 months into the 2+ year range.
What needs to be done to support the solution, long term?
Maintenance updates and compliance with GDPR or HIPAA regulations.
Research to identify the best booking flow and customization to fit vendor needs like custom hours of operation, multiple resources available for booking within one slot, or identifying how to route new leads to correct sales representatives.
Building the scheduling functionality yourself
PROS
Visibility into product design and data model.
CONS
Management efforts during development and deployment;
Developer time and increased headcount;
Maintenance and updates still require significant time to implement;
Focus switch;
Legal regulations regarding security;
High chance of failure;
Responsibility for the project.
BUY
Using a third party massively increases the safety of the investment. Instead of a long development process, you can build an MVP and test new features with customers to get real market feedback and gather analytics in order to make adjustments.
OnSched’s API was designed to fit the needs of digital and brick-and-mortar enterprises with varied booking use-case requirements. A fully working integration with OnSched is usually completed in 30 days or less and our team is ready to talk directly with your developers and help you with API implementation.
Integration with the OnSched API
PROS
Reliability (99.9% uptime)
Minimal risk of investment
Integration speed
Professional support
Existing integrations
Regular updates
Security compliance
CONS
Not applicable if you sell on-premises software
With detailed documentation and support from OnSched developers, we help you balance your immediate needs. When it comes to security and reliability, we make sure that we comply with all GDPR regulations and can enter into a BAA to address security concerns. We focus on core competencies and are able to schedule some developers’ time in an effort for a smooth and rapid deployment.
How does it work?
OnSched’s API was designed to fit the needs of big directories, aggregators. An integration with OnSched usually takes, on average, up to two weeks. Our team is ready to connect with your developers and help you with your API implementation.
Here is what you get
Fully accessible REST API > > > Time Zones, Personal Scheduling Link, Email and Text message Notifications, CRM Integration, Synchronization with iCloud, Google and Outlook Calendar Sync, Custom Fields, Lead Routing, Comprehensive documentation, and last but not least, support from your OnSched team.
CONCLUSION
Given the complexity of scheduling technologies, resources required to develop a solution, and the risks and time involved in building something out from the ground up, we recommend leveraging an already-existing, tried-tested market booking solution such as OnSched.
By outsourcing responsibility for this project to a SaaS company, you are not only saving time and money but ensuring proper product delivery.