3 ms·

I'm the author. Don't underestimate the willingness to support a friend's project. Over the few days since I was asked, I went back and forth between declining

I'm the author. Don't underestimate the willingness to support a friend's project. Over the few days since I was asked, I went back and forth between declining and accepting. I (incorrectly) assumed we'd be rejected from YC, and that was a mistake. Actually, Rust was the second choice. First was Go, which was exponentially easier to hack together a product as it was simply a matter of piecing services together. But, the first developer we on-boarded (Ravi) was a Rust developer, and we already had plans to utilize Rust in some areas later on, so we tried to see how quickly we could apply it. Note at the end of part 3 lists using Rust in an unproven area as much as we did for a PoC as one of the mistakes I made. Not sure why raise Python as an option as it was never on the table, except to say a YC coach suggested we use it. Go, Swift, and TypeScript are more than suitable for rapid development, and were the other languages we were using. In retrospective, with the lessons learned, we can apply Rust a lot quicker now, than we could of at the time. Although I still wouldn't as it simply offers too many challenges compared to using our first choice: Go.

phonon 9y ago
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 million open source kanban implementations too...
- 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.

phonon 9y ago

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 million open source kanban implementations too...

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.