DIY vs Platform Supported
Assuming that we can easily get Voiceflow data, the next unknown is how to deploy a functional chatbot behind SMS. There are two main approaches:
- Build our own bot hosting backend and use a service to only send and receive SMS messages
- Try to find a service with capabilities to host and run bots by itself
The DIY route
This is the easiest approach in terms of clarity - we know that there are many services allowing us to interface with SMS messages, and we know what kind of chatbots we want to support, so we just write some backend that does that.
The key disadvantage is the time and resources required to do this. This increases the complexity of the project significantly. We have to think about user accounts, authentication, registrations, scalability, resilience, security, reliability, logging and many other things. Codebase and, therefore, further development and maintenance costs would jump too. This is great as a learning experience, but it also means that we simply won’t achieve a functional product in the time we have.
It’s simply not practical unless there is no alternative.
Stepping on a Platform
This brings us straight back to the land of the unknown. What services are available? Does any service offer the chatbot capabilities we seek? If none exist, can we try and repurpose the features of a given service to still achieve what we are looking for?
Nonetheless, the advantages of reusing what is available are clear. We probably get simplicity, scalability, security, and actual functionality by default. So it is worth the research.
The disadvantages are platform reliance. This is of little concern in the early-stage product that we’re building. However, the costs of the DIY route might be outweighed by the reliance if we are talking about a scaling product.
Our research is documented in this article. The summary is that while no service provides what we look for, we managed to repurpose other Twilio features to still get what we want. This is explained in this article.