3 ms·

Why not just take an open source slack competitor and build off that? Like https://github.com/zulip/zulip/ https://github.com/zulip/zulip/ ? And there are a mi

• siilime 9y ago
  We had specific requirements that would have meant we would have spent a significant amount of time re-engineering parts of any open source option to make it fit to the insurance market, essentially taking longer than building our own, and this is ignoring the bigger issues. We could have integrated into an existing solution like Slack using their APIs, but unless the UI was specifically designed to fit the specific market it wouldn't be a worthwhile replacement for existing products. As for the kanban, that was an easy UI to build. As you pointed out, there are plenty of options there. We actually didn't need to use a third-party as it's really simple to build a good kanban UX from scratch. The complications with our project were not in the UI specifically; there's literally thousands of clones of those types of projects, and more each day. Our complications were in developing a very specific user experience, tailored for a specific type of customer's workflow, needlessly tightly-coupled to a monolithic distributed ledger platform with no API, that depended heavily on both private and public networks containing cryptographic signatures. Trying to conceive of a solution to a problem that didn't exist is also one of the major issues. Our customers didn't need a new messaging platform, secure storage solution, or kanban board. They needed a secure way of writing contracts and agreements, that were then financially binding. The solution was entirely wrong for the problem we were tackling.