Vikrum Nijjar joined as the first engineer at Firebase, and did whatever it took to help the company succeed: scaling out infrastructure, shipping mobile SDKs, hosting 1-1 office hours with developers and even standing in as SRE for 24×7 hour shifts… for over a year.

In this interview, Vikrum tells us what he found most valuable about his YC experience, how to build successful developer tools, and why Gold Fig is going to put an end to embarrassing and costly configuration changes, once and for all.

If you’re looking for your next job, visit YC’s Work at a Startup to find engineering roles at over 500 funded YC startups.

---

Ryan: Firebase (S11) is such an integral part of so much internet infrastructure — every developer seems to have done something with it. What was it like being so early on there?

There’s so much I got to build, it was incredible. In the early days, I started by working on improving our engineering rigor and automating our deployment process. We were thinking about scale from the start — we already had customers, and knew it would be big. At one point, we needed to pick good technology for the infrastructure, and I had lots of experience working with JVMs, so we picked Scala. We also knew Scala would help us attract good candidates, which it did. From there, I got to build the networking layer too, and wrote the first iOS and Android SDKs. At a startup, you get to contribute to just about everything.

Ryan: And what was it like working on such a small team?

James and Andrew [the co-founders of Firebase] really treated me like a peer. At no point did I feel like Firebase was not mine. In the early days, I would just ship things without asking anyone and they were fine with that. One of the most memorable things was when I added office hours to the app. Any Friday, developers were invited to come to the Firebase office and ask me anything.

Then about two weeks in, James comes to me and says, “Who are all these people coming into our office?” I told him what I did, and he just said, “Keep it up.” I mean, our customers were developers, and we want them to be super successful. And this was like having office hours in college. It was also a great way to engender trust with our users, and to get feedback on what’s working and what’s not working. And you know, do things that don’t scale.

Ryan: What’s it like building a tool for developers?

Developer tools have these 2nd and 3rd order effects. It’s really endearing. There are — I kid you not — people who have found out I worked at Firebase and have told me, “Firebase changed my life.” I once met a guy who used to be a waiter at Applebees, went to a hackathon and learned Javascript and Firebase, and then won the hackathon. He ended up sticking with it, getting into tech and now he’s a PM. He never thought he’d be out of the food service industry, and — just to think that Firebase was part of his story — is really amazing. At one point, we had a tweet posted on our wall, “Please marry me, Firebase!”

The support from @Firebase is incredible. I loved them before, but right now I’d almost marry them. Highly, highly recommended. #StartupAUS

— Murray Hurps (@Murray)

January 17, 2015

Ryan: Ridiculous. What do you think helped Firebase turn into such a big phenomenon?

It’s going to sound cheesy, but really, it’s about the people who worked there. We all wanted to do whatever we could do to help the company succeed, and that meant helping developers succeed. As we grew, we tried to make sure we found people who believed the same thing. Everyone says that hiring the right early employees is extremely important, and it was no different for us.

Our highest order bit was to hire kind people. Obviously we wanted people with the right skills and ability to communicate, but James and Andrew went out of their way to make sure they didn’t hire jerks. We also made sure we hired people who enjoyed coming to work, and whom we enjoyed working with. That’s really important to look for, because each person you add to the team changes the dynamic — for example, if you hire somebody more introverted, it changes the team’s communication style.

We were kind of lucky because we got to stay small for the entirety of Firebase. I joined in 2011, and when we got acquired by Google three years later, we were still only 22 people. And only one person ever left during that time, and it was for non-work related reasons.

Ryan: So how early were you?

When I started, it was just me and the founders and they were going through the S11 batch. The company was actually working on chat APIs, and then realized that their real-time infrastructure was more useful than the chat tools themselves. We pivoted to Firebase a few months after demo day.

I originally found their job post on Twitter. One of the founders put a description on HackerNews and then tweeted it. I cold emailed them, something like “I saw your post, I’m winding down my startup, and I want to join a good team.” At the time they had customers and revenue — two things I didn’t have with my own startup.

Anyway, they asked to meet, so we got coffee at the Creamery, and it was pretty casual. We did an onsite about a week later, and then a small take-home exercise. Not as taxing as what we had at Google, and I got to get to know them better in the process. I’m a strong proponent of interviews being bi-directional — candidates should take the time to really get to know the startup, founders, and team. And I vividly remember James letting me list out all the things I expected culturally. That meant a lot to me. And it turned out he was really listening; even on the toughest days, we still took time to take lunch together, walk around SoMa, and enjoyed every step along the journey.

Ryan: And have you been in touch with them?

Definitely. When I applied to YC for my startup Gold Fig, I reached out to Andrew and James and told them about it. They were both incredulous — “No way you’re getting in.” But they still spent time with me, and gave me strong recommendations. That was key, because I had only done a bunch of mocks and hadn’t written that much code at that point. Getting their input on what I was working on and my YC application was huge.

Ryan: And given you were so early on Firebase and have startup experience, why did you choose go through YC?

Yeah, we thought about that a lot. We have the network, and we feel pretty comfortable building a product. And there were some key things that we thought we really wanted. First, because Gold Fig is a developer tool, we thought that it’d be useful to tap into the YC community to get early users — just like Segment and Stripe did. And second, we wanted to use HN for recruiting engineers, because both me and my co-founder found Firebase that way.

But the actual benefit we got during YC was something completely different. I mean, we knew we needed velocity, a forcing function to keep shipping, launching, and re-launching. But once got in, we really had to step up our game. Here are all these incredible founders working on amazing ideas, and YC partners pushing you each week. Extremely high-concentrated messaging, like Kevin Hale telling us to focus on the one thing that’s important to our company right now. And Gustav telling us, “You should launch this thing and you should be embarrassed.” It’s not just a figure of speech. If you’re not embarrassed, you don’t care enough. You need to caveat that with what you’re building, but know that you can deliver a ton of value and it can still be janky.

So yeah, you can read blog posts online or watch the videos [about YC], but hearing feedback in person, and for 3 straight months, is game-changing. It pushed us to code more and launch more than we ever have. And we really didn’t know what was possible in us until we had people pushing us, people who wanted us to be as great as they thought we could be.

Ryan: And where are you guys now?

Well… we did it! [Laughs.] I mean, we got through YC, and we just finished fundraising. But we’re just getting started. We haven’t hired anyone yet, and we’re trying to be thoughtful: company values, run rate, in-person or remote, all that stuff. We’re able to stay lean now, and maybe hire 3-5 people in the next year.

And we’re doing what we did at Firebase: talking to developers, understanding what they need, and building. Just building. It’s great, because we’re back to solving a core problem for developers: working in a sea of different SaaS projects and online software systems, and trying to manage configuration, version changes and compatibility. Gold Fig’s ability to show them all in one place, undo changes, set up environments for new hires on staging vs. production, it’s all based on what we’re hearing from our users.

I mean, at some point we were concerned that what we were building was too niche: only for people who had been burned by bad configs. We thought maybe it might be just DevOps managers or the security teams. Turns out, just about every developer has been in that situation. And it sucks. So now we have everyday developers to VPs of engineering reaching out to us to find out what we’re up to, and how we can help them.