Instant (YC S22) Is Hiring a Founding Engineer to Help Build a Modern Firebase

We’re looking for a hacker to join our team of 3 on-site in San Francisco. You would be one of the founding engineers; why join us, when you can start a company yourself or work at an OpenAI? Here’s our case:

Instant is (a) a really hard problem (b) that users want (c) worked on by an excellent team (d) where you can have immense impact and (e) be compensated accordingly.

Let me explain:

## (a) a really hard problem

For the last two years, we’ve been hacking on Instant, the modern Firebase. Instant is a database you can use directly from the browser; you write queries, and they stay in sync, work offline, and come with optimistic updates out of the box. You get auth, and a system for running permissions too. You also have support for presence, and SDKs for React, vanilla JS, and React Native.

For years we were in a cave building and talking to a core group of users; Instant turned out to be one of the hardest products we’ve ever worked on. We built a multi-tenant architecture, so we could offer a free tier that never freezes (you can even spin up a database without signing up, check out the tutorial [1]. We had to write a query engine on the backend, and a sync layer on top of that. To do it, we scoured articles on Figma’s LiveGraph, Asana’s Luna, and Andy Pavlo’s courses.

We open sourced last month, and had one of the largest Show HN’s for a YC company [2]. And soon after that, we announced a 3.4M seed round, backed by James Tamplin (the founder of Firebase), Paul Graham, Greg Brockman, Jeff Dean, Amjad Masad, Karri Saarinen, and 50+ technical angels.

## (b) that users want

Since launch, we have been flooded with user requests. Some of the largest infra and AI companies have reached out to us for integrations. We have people asking for enterprise deals, and had to turn some down due to bandwidth.

You probably resonate yourself — you know how much of a schlep software development can be: spin up databases, write endpoints, funnel data to store, and finally paint screens. You do all of that, and the app is just ok. If you want to make it great, time to add reactivity, optimistic updates, and offline mode.

It doesn’t have to be this hard. There’s a missing abstraction, and it looks like a database you can use in the browser. Companies like Figma, Asana, Linear, and Notion have all built this internally. It’s obvious to us that most apps will be built this way in the future, and we built Instant to power them.

## (c) worked on by an excellent team

For the longest time, we’ve been a very small team: right now it’s just 3 of us: Joe Averbukh, Daniel Woelfel, and me. We’ve known each-other for 10 years, and have worked across companies together. We think small teams of very talented people are special; It’s more fun, you get more autonomy, and you form relationships for life.

This is how it feels at Instant. Each of us own projects that would have deserved large infrastructure orgs at other companies. Each of us takes our craft and our word seriously; it’s a breath of fresh air to work together, knowing that when you ask for help, you have someone who you deeply respect by your side.

## (d) where you can have immense impact

Our current architecture got us to a new stage, but to really excel at this next stage, there’s a lot more to do.

We recently had to turn down 2 customers because they would have added 2 magnitudes more traffic. Our infrastructure can’t handle that yet, but perhaps with your help, they will. Maybe you could dive deep into our sync engine: what kind of algorithms can we write to improve invalidation? How can we jig postgres to make queries even faster? How can we send less data to the client?

We have a storage service in beta. We want to make it the best one on the market. We want files to live in your database too, so they can be reactive, and work with permissions out of the box. You shouldn’t have to deal with presigned URLs. You shouldn’t need triggers to sync different datastores. You should just be able to upload files from the client.

We have a multi-tenant database you can start with, but what about existing companies? They already use Postgres. Well, what if we created a Postgres adapter for Instant? We could take Instant queries and translated them to postgres SQL. What kind of [postgres introspection queries](https://www.figma.com/blog/keeping-figma-fast/