I am a start-up with a beta business process rules engine application. The application is form-based, so it asks users a number of questions and then provides an answer or escalates the form for further review. An initial client has asked if we can build a chatbot front-end UI, which I think would be a good addition to the product feature set as it could be a more intuitive option for answering the questions in the form.
My question is: as a start-up should I pursue building my own chatbot software or simply build on top of the Amazon Lex API, which has all the features I need. The latter seems like the best approach from a cost and functionality perspective. My concern, however, is that when I go to raise money, a VC may not like my building this core feature on top of an Amazon API instead of building it completely proprietary.
I am a non-technical first time founder, so apologies in advance if this is a basic question. I would love any insights.
I've built a few chatbots, both on platforms and bespoke for clients. Amazon Lex is certainly one approach, but I'd say it's probably not the best for what you're looking to do. Would really need to know more about what type of functionality you need, type of flows, and integrations. Something simple, it might be worth going with a simple platform approach. It's easy to do and gives you the framework to do more complex routes later. If you're talking about catching all the edge cases with multiple paths and basic NLP, you have the time and assets, then bespoke might be worth it.
If there is any chatbot software is already available to you then use it. These are list of reasons for developing your own chatbot software:
- You tried everything available on the market and none of the offerings have features you need.
- You want to develop proprietary chatbot software with advanced features that give you SIGNIFICANT competitive advantage (and you will need to worry about patenting).
Developing your own software is expensive and it is long term commitment which may become liability if you get it wrong. As a startup, you will likely need to try and throw away lot's of ideas, so don't lock yourself down prematurely if you can avoid it.
Lex is something super cool if you wanna to build on top of it. I dont think a VC would oppose on that still if you could generate traction basis of your service model. But need to get more clarity where you are going to apply this bot? like on the web or messenger and etc? depending on your requirements you may look at whether u wanna go ahead with a script one or one with intelligence. All the best!
Building chatbots is incredibly easy, even if you're non-technical.
I recently wrote about making Slack chatbots using Botkit and Glitch:
Botkit is an open-source bot making toolkit that makes it super easy to build a bot in a number of environments, and Glitch offers free servers to run your bot.
If you'd like help getting your bot made, let me know!
Building a NLU component from scratch is rarely justifiable if providing such services and associated deep learning algorithms is not your core competency or value proposition. Also it seems like a distraction and a waste of capital to build something that may very well be of inferior quality to the various NLU and conversation API available from all the major cloud providers and at least a couple Open Source initiatives. In my opinion, a VC may actually question the wisdom of building it yourself. I do see an issue with vendor lock in if you choose Amazon for example. It is preferable to have a design approach that creates a loose coupling between the conversational models of your application and the NLU provider. It mitigates the risk of vendor lock in, and provide the flexibility to choose from a list of supported API providers based on your end customers preferences. Hope this helps.
The bottom line VC's focus only on future revenues . I hardly recommend you use AWS service since in the future i believe you can replace it very easy ongoing by your own proprietary if necessary.
Until you have traction, use the dominant platform. You can build proprietary later if you need. VCs will question why you choose a proprietary platform for the service instead of using currently available, and likely to continue to be leading, platforms.
It's always best to keep things lean, focus on delivering value and not reinvent the wheel if you don't really have to. A VC wants money and the general rule of thumb is that complexity is the enemy of profit.
One mistake would be to choose technologies that are not scalable or limiting, not the fact that you use third party APIs.
The other extreme is that if you do things too simple, the entry barrier for your potential competitors will be low. However remember that the most critical separator will be business execution, not the complexity of the IP.
If this chatbot is a core feature why is it not in your beta MVP already? Without knowing the big picture, I believe you might be exaggerating slightly.