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 [3], 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 would you need to write to infer the schema?

Right now we have no story for load testing. We want to build a suite to track metrics to track perf and have visibility on improvements/degradation. Even something akin to the one-laptop solution Figma had up to 2020 would be a big win for us. Can you build it?

Or how about our client side SDK. Our reactive layer on the client is a state machine, and it’s getting out of control. Maybe it’s time to introduce observables. Can you add them? We should be able to introspect into the state of the client: what happens when you make a transaction? Can we see it propagate and change throughout the SDK?

## (e) be compensated accordingly

If this was a few months ago, I would not have written this, I didn’t think the risk/reward would be worth it for you. But at this point, I really think it is. We’re just at the point where we could hit PMF with your help, and since we haven’t raised an A yet, we can offer you significant equity to make it happen.

—

If you’re the kind of person who gets excited about this stuff, who truly loves their craft, and wants to work with others who do, who moves fast, but isn’t afraid to look deep into the ‘scarier’ programming problems. we want to talk to you.

Send us an email: founders [at] instantdb.com, and include a project you worked on (if it comes with github that would be awesome!)

[1] https://instantdb.com/tutorial
[2] https://news.ycombinator.com/item?id=41322281
[3] https://x.com/stopachka/status/1841514927099437144