3 ms·
Not at all common. Few startups typically get accepted into the program if they're in that much of a pre-development state. Unfortunately YC and Silicon Valley
by siilime 9y ago
Not at all common. Few startups typically get accepted into the program if they're in that much of a pre-development state.
Unfortunately YC and Silicon Valley is still rife with buzzwords over content. Many of the YC alumni parties are full of founders proudly professing their YC failures.
CTO (myself) couldn't attend as it was made clear that YCombinator wouldn't allow anyone who wasn't there during the interview stage to attend the YC meetings. That alone was a huge issue. As for the interview itself, I simply couldn't attend; it was impossible for me to fly out on that date, and no other interview slots were available by then.
That's not to say it doesn't happen. There were other startups in S17 that had no product, but they had customers who were already signed up. It seems every batch gets larger, but the quality of much of those batches seems to decrease.
The desire to get into YCombinator seems to push founders to make mistakes and rush ideas along that simply aren't ready.
As the author, cringing seems the correct response to what was happening.
As far as buzzwords go, it often became a running joke in the house. Every week we'd be told to add another buzzword to the pile, with each buzzword having a perceived value impact on the startup for VCs and investors. That is relatively normal among startups, and something I was fairly determined to avoid during development.
- brianwawok 9y agoI just tried to put myself in the author's shoes. I think i literally had 12 moments i would have packed up and went home. Starting with the decision to apply to YC with nothing. And i don't consider myself a quitter. (A few other questionable things like rust for a POC with no users. Why? Does someone claim to out POC Python with rust?)
- siilime 9y agoI'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 agoWhy 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 agoWe 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.