My first year as employee #1 of a YC company

by @vikrum5000 on July, 31 2012

Time flees

This month marks my one year anniversary with the Firebase team. This is the first time I’ve actually decided to write about the first year at a job. I’m going to spend a bit of time reflecting on what has made it awesome, some of the notable milestones, and what has made it different from my other experiences.

Before the beginning

Prior to moving back to the Bay Area from Washington, D.C. I was working on my own bootstrapped mobile startup, Flourishworks. After some success and ambivalence with a handful of apps I decided to shutter that endeavor. My wife was wrapping up her training and I wanted my son to be closer to his grandparents, so we made the trek to California. After talking to a few companies, I happened upon a HN post that caught my interest.

We’ve got 99 problems but traction ain’t one

Envolve, the precursor to Firebase, was going through the S11 batch of YC when I joined them. The product was growing steadily and actually bringing in revenue. After meeting the co-founders, James and Andrew, making the decision to join them wasn’t at all difficult. They had already shown that they had the capacity to build a product that was not only in demand but also one people were willing to pay for.

Through the summer I went to a couple of the dinners and got to hear Max Levchin and Ben Horowitz speak. During these outings, I met a bunch of the other companies in our batch: MobileWorks, Picplum, Cloudfuji, and Snapjoy among others. I was extremely motivated by all of the other people building amazing companies. The fervor around building meaningful companies in The Valley is contagious. When demo day came around, I got to work the crowd during breaks and pitch Envolve to investors. I had a blast during the process and consider it an invaluable experience.

Envolve at YC S11 demo day

The first week with the team, I shipped a demo of our new API: a chat overlay on HN. It was a huge hit and we spent the next couple of days just chatting with people. This was to be a great indicator of one of our core engineering values: ship it! While we might not deploy as often as other teams, our build and one-button deployment system makes it a breeze to ship. Whether it’s just a toy or code going out to production, the friction of deploying isn’t a limiting factor.

Things in motion tend to stay in motion

A mature code base tends to have plumbing built to support it; it works seamlessly and we all end up taking it for granted. Starting Firebase anew meant that we needed this legwork done up front. I took the lead in getting our continuous integration and deployment system up and running. Making sure our team didn’t have to spend time fighting their IDE or getting their code deployed means they can spend more time moving the product forward. I wired everything up so we get automated running of tests, easy deploys, as well as easy rollbacks to previous known-good versions of the code. Every time the system runs and does a deployment, it makes the entire company more effective and efficient. The tooling and time I put in will continue to have a beneficial impact on everyone checking code in and deploying it to production.

Being able to contribute an enormous amount of momentum to a company is hugely gratifying.

Don’t call it a pivot, we’ve been here for years

During one of the prep sessions in the weeks leading up to demo day, Andrew began tossing around an idea that would eventually turn into Firebase. Our existing customers had been requesting features on top of the chat product that began to make perfect sense for a product that addressed the problem at a lower level of abstraction. The natural progression from the chat product to a general purpose realtime synchronization service made the realignment of the company an orderly process. We went from having a product that was growing at a good clip to a product that developers were absolutely clamoring for.

The methodical manner in which we spec’d out the product, got feedback from developers, and created buzz around Firebase deserves a post itself. Nothing is left to happenstance—it’s all engineered. We iterated on several incarnations of the product with close input and feedback from developers. These feedback sessions involved sitting a developer down with the docs and API for the very first time and watching them build something with it. After hundreds of hours of these sessions, the API began to stabilize.

We created dozens of variations of the Firebase API prior to landing on the one that developers found to be the most expressive.

Apropos of nothing

Earlier this year, office mates of ours, Rapportive, were acquired by LinkedIn. After their acquisition, we grabbed their office as soon as it opened up. Apart from the great mojo this office has, it has a spectacular view.

View from the Firebase office

First day in the sun

In April we were one of the sponsors of AngelHack. This event was the first time Firebase was being seen outside of our circle of friends. All of our hard work would be tested at this first gate. The stress and tension leading up to this point was palpable. How well it was received by this crowd of Silicon Valley developers would set the stage for how it would do for the public launch. Otherwise, it would be back to the drawing board.

Of the dozen other APIs sponsoring the event, Facebook was the only one used more than Firebase. All of the teams using Firebase made it to the finals. Of the top ten teams making it to the final stage of judging, five of them used Firebase. Being able to facilitate developer success to the level we did at AngelHack exceeded all our expectations.

Judges at AngelHack, including Dave McClure and Naval Ravikant

The event was a huge success. We got Firebase in front of new eyes and developers were able to smoothly build on top of the API. Getting more real world traffic thrown at the system shook out even more bugs in our code that wouldn’t live to see the public launch. During the event itself we deployed new code while people were bashing on the system. The trust in the deployment system had reached the point where we were confident in its resilience and veracity.

Let me go work on this toy a week before launch

The week prior to any launch is hectic. There’s always something that needs tending and the Firebase launch was no exception. What did make things different for us was that in the days leading up to the launch, I came up with the idea to make a toy that would show off Firebase: MMO Asteroids. I took a 1000 line HTML5 single player game, added about a dozen lines of Firebase, and made it multiplayer. It was a gimmick that paid off: several thousand people came by the page and had a go at the game. We were pushing 25mbps of traffic just from this toy. It also helped us shake out a gnarly deadlock issue in our realtime code; another bug that wouldn’t live to see our public launch. It’s things like this that have made the Firebase experience so much different than any other. In the deepest crunch time prior to launch, I was given enough leeway to spec out and ship a toy for the sake of shipping a toy.

Firebase takes off

For our launch party we put together our own demo day. We had over 200 people show up, a dozen developers demo applications they’d built on Firebase, and several tables set up where people could show off their code. Given that this was the first time a team of 4 engineers put on a demo day, the event went over flawlessly. We had a tremendous amount of help from some very close friends; none of it would have been possible without them: thank you Chris, Ivan, and David! We were also able to coordinate a bunch of press to hit around the same time as the event—which made for a great segue to fundraising.

Following our launch, James and Andrew set out fundraising full time for the next month. The conventional wisdom here is that the company’s progress grinds to a halt during this phase in a company’s life. Having hired Michael, an awesome juggernaut of an engineer, this was not the case for Firebase. The both of us took charge of all of the day-to-day happenings of the company. We planned out and shipped new features with both of the co-founders of Firebase busy elsewhere. You’d be hard pressed to find other examples of this type of product progress during the seed round of fundraising.

The Firebase crew chillin with Jared Leto

No vocational dissonance

We software types are extremely fortunate being in this space. Everyone is hiring and jobs are easier to come by than housing in many locales. Throughout my career I’ve been a part of amazing teams and companies. However, after about a year has elapsed I’ve noticed a dissonance starts to accumulate. This can manifest itself in various ways: diverging product vision, teams being encumbered by the infrastructure of large organizations, or impedance mismatch within a team. At Firebase none of this is true. We have a spectacular team blazing away at an awesome product. Soon, we will have doubled our team’s size with no slowdown in sight. The next year is going to be a wild ride.

—

If you enjoyed reading this, catch me on Twitter Follow @vikrum5000