
A story of how we failed in YC S17 - wafflespeanut
https://medium.com/@siilime/through-the-looking-glass-part-i-2a710a865c67
======
siilime
Part 3 has a TL;DR, and part 2 has some of the more crucial elements outlining
where the failures were. Altogether it aligns with advice typically given to
startups looking to apply to YC, but as a post-YC story, it perhaps has more
resonance.

[https://medium.com/@siilime/through-the-looking-glass-
part-i...](https://medium.com/@siilime/through-the-looking-glass-part-iii-
bafa050b7e3)

------
brianwawok
What a trainwreck. Is this actually common? Obviously only one viewpoint but i
was in cringe from day1. Buzzwords. No product. No customers. CTO not
attending meetings. What?

~~~
siilime
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
I 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
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
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
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.

