Through the Looking Glass (Part I)

And into YCombinator

This was originally a much larger piece regarding our experience as a team working under the YCombinator program, but has been slimmed down. The original remains as a point of reference, but some significant aspects, and personal elements, are now no longer part of this three-piece article. Part II can be found here.

In April I received a call from an old friend, which we’ll refer to as Pete for the sake of privacy. I knew him from my time working in Manchester, United Kingdom. We’d previously worked on three separate projects together, mostly focused on hardware development, including a scalable gaming & artificial intelligence development platform, a fashion-based wearable, (launched in 2017), and a portable storage solution. Our relationship mostly consisted of him reading a wealth of material on what he felt he wanted to build, and then testing his ideas against me. I would then feedback with in-depth technical reviews and routes to delivery. What persisted was a partnership with great respect, communication, and an appreciation for great design, oriented around Japanese aesthetics, including Wabi-sabi (侘寂), and Ensō (円相).

When the phone rang we immediately jumped straight into updating each other on where we were at; what projects we were working on; what difficulties we were facing. I knew he wanted something from me, and I was more than willing to support him. Inevitably the conversation turned to my availability to take on another project. At that time I was entirely locked-down on a machine learning project I’d been hammering at for over 5 years. I was close to launching a new update and wanted to remain focused. However, when he mentioned highly-scalable distributed data, security, and cryptography — deeply integral prime elements of my own project — I felt it would be a great opportunity to test parts of my existing work against this new project. I remained undecided, especially as the project was oriented around financial tech., and specifically insurance — easy money, but of little interest to myself — so said I’d be happy to continue the conversation and lend my support where I could, as long as the project felt like a complimentary fit to my current work.

It was at this point that he admitted he’d had another choice for technical lead, that the individual was unavailable due to his own distributed ledger project, but that he would be providing the core backbone of this project as a brand-new re-usable blockchain solution. I wasn’t offended by the idea of not being his first choice; I was happy to have him bounce ideas off of me, without feeling the need to acquire a specific role, or be involved in any substantial way. I voiced my concerns regarding helping with a solution that already had a platform from a third-party though. I would need to perform due diligence on all elements of the project and this would be a significant part, as the core foundation of the stack.

The Concept

Initially the idea was centered around a form-based Web application for the insurance industry. Most of the features floating around didn’t seem to require a blockchain solution, or any form of distributed ledger technology. One core feature was a “trustless” model, where the system could verify a digital signature on contracts produced through data input by various parties, and then enforce those agreements and payment terms with banks automatically. That trustless requirement was key to the decision to look at blockchain / DLTs, and cryptographic signatures made sense to me. However, blockchain still seemed an extra, unnecessary leap at this stage in the project. I’d recently migrated a large portion of my own project from Ethereum to Hyperledger Fabric when it became apparent that Hyperledger Fabric would facilitate the smart contract features necessary, without the performance overhead of a blockchain, and I felt this new project may not be substantially different.

I spoke to his blockchain expert; “Dwayne”, as agreed, and we had a reasonably respectful conversation. I disagreed with his technology choices, (primarily in building a DLT on the Java Virtual Machine), but he was adamant that the technology could be changed later, despite investing 5-years of his time, and 300,000 lines of code, building it. I also felt his background seemed chaotic and unfocused, but so does mine, so I had no foundation to have that argument.

I said I would need to verify his technology before using it, and that I would still design the system to be loosely coupled away from any third-party platforms, including his. Dwayne wanted to retain the platform as his own intellectual property under a separate corporate entity, and this raised alarm bells, so it was important for me to protect my friend and ensure the solution used best-fit components throughout. I made this clear after my call, and we agreed a code review would take place, we’d have a copy of the code to reduce risk, and that it would be my decision in the end on whether we utilized this third-party platform or not.

Applying to YCombinator

Pete ended these initial conversations by saying he was applying to the Summer 2017 YCombinator accelerator program and would need me to agree to be the co-founder and Chief Technology Officer (CTO) in order to go any further. He felt he wouldn’t be successful if he couldn’t attach my name to the application. I would need to half my existing salary at the studio during my tenure, and be entirely focused on his project. I took a few days to decide, and reluctantly agreed out of respect and an eagerness to help, stipulating we would focus on getting a product ready to demonstrate by the end of the program, perhaps getting a functional prototype within 6-weeks. We’d aim to have 4 to 6 developers on the project within the first few weeks, and had a substantial budget to achieve this.

I felt the experienced folk at YCombinator would see a lack of any sort of product at this stage, and would reject the application anyway, possibly giving us the opportunity to try again for a more reasonable Winter 2018 program. I have a wealth of experience working with startups and accelerator programs, and I rarely see any ideas that are still at the point of incubation making it into an accelerator, least of all YCombinator, and I advised Pete that a few months of development would put his project in a much healthier state to enter the program.

A few days later I received an SMS to request if I could fly out on May 1st to present at YCombinator in Mountain View. I had already made plans, so I reluctantly declined and tried to arrange an alternative date for the meeting. In the few hours between receiving the proposed schedule and responding all slots had been taken, so I asked if Pete could go without me.

The presentation at YCombinator happened without me and I expected little to come of it. Immediately afterwards I received a text message instructing me to pack my bags as we’d been accepted into the program for the Summer 2017 batch, starting at the beginning of June. I was both disappointed and excited; the idea of seeing how YCombinator operates from the inside was fascinating, but I had priorities I wanted to focus on in Helsinki for my own project, and felt this idea was far too immature to take to the program. I decided not to let Pete down, and pushed my other project to one-side, informed my existing clients & partners, as I pulled everything needed together to build a team, and design and build a new product.

Touching Down in Mountain View

The hiring process began immediately with advertisements going up on social media, StackOverflow, LinkedIn, and eventually followed by Girls in Tech, (we received no applications through Girls in Tech disappointingly). I chose to use Go, Rust, and Swift to develop the core of the product, focused on infrastructure, data IO, and application logic respectively. I was using all three at my studio in Helsinki and felt they covered everything to a good standard. Most of the interesting new DLT technology I’d researched were using similar technologies, and I felt it would give us a strong platform going forward. My concerns over their newness were resolved with the fact we would have 3-months to deliver the project, and the communities of all three are rapidly growing in strength in the cryptocurrency and DLT market, as well as with cloud computing providers. I could also re-use much of my own technology from my studio to augment our position and move more quickly.

Before we moved I had already conducted several interviews in Helsinki, remotely with candidates around the world. The Rust community were fantastic in supporting me, once they understood Rust would be core to the success of our product. They pushed out my social media posts regarding needing good developers, and some of the Mozilla team connected me to a young Rust developer in India, called Ravi. We spoke, he completed an assignment I’d given to all candidates, and we spoke again. Although he lacked experience outside of working on Firefox as a community member, his aptitude and excitement for the challenge made it an easy decision. I called Pete and suggested a salary offer, leaving it to the two of them to make arrangements.

Our original tweet, supported by the Rust community

We needed someone focused on non-distracted design work so the rest of the technical work could be developed rapidly. My partner at the studio, a graphic, Web, and mobile designer (Gabi) was available, so I suggested we utilize her as a freelance resource for as long as we needed design. The decision was left up to me, so we both packed our bags and flew to Mountain View where Dwayne and Pete were already moved in and settled. The house — an USD 6,800 per month bungalow —had an annexed rear extension. Gabi and I moved into that part for isolation, and we set to work on identifying what we needed to build.

I’d already started transitioning some core elements of my own project to support this smart insurance solution; I moved some of the pieces into place, and begin collecting the services we would need to build a simple web-based app. It didn’t take long before Ravi, our new hire from India, joined us in Mountain View. A week had passed since I had arrived, but it had been packed with the boring administration and setup work.

I’d created a base set of code repositories for the future project artifacts, designed a preliminary development roadmap, applied an agile workflow for the entire project, and we’d had plenty of planning meetings / discussions about how the product would need to progress going forward. We were ready to start coding.

This is part 1 of a 3-part piece. Part 2 can be found here.