Instant
The Modern Firebase
Hiring a Founding Engineer to Help Build the Modern Firebase
About the role
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). 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. 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 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 a message, and include a project you’ve worked on.
About Instant
In two sentences: Instant is a modern Firebase. We make you productive by giving your frontend a real-time database.
What does that actually mean?
Imagine you’re a hacker who loves building apps. You have an exciting idea, and are ready to make something people want. You want to build an MVP fast, that doesn’t completely suck. So how do you do it?
Most of the time we make a three-tier architecture with client, server, and a database. On the server side we write endpoints to glue our frontend with our database. We might use an ORM to make it easier to work with our db, and add a cache to serve requests faster. On the client we need to reify json from the server and paint a screen. We add stores to manage state, and write mutations to handle updates. This is just for basic functionality.
If we want our UIs to feel fast, we write optimistic updates so we don’t need to wait for the server. If we want live updates without refreshing we either poll or add websockets. And if we want to support offline mode, we need to integrate IndexedDB and pending transaction queues.
That’s a lot of work!
To make things worse, whenever we add a new feature, we go through the same song and dance over and over again: add models to our DB, write endpoints on our server, create stores in our frontend, write mutations, optimistic updates, etc.
Could it be better? We think so! Instant compresses the schleps:
If you had a database on the client, you wouldn’t need to manage stores, selectors, endpoints, caches, etc. You could just write queries to fetch the data you want. If these queries were reactive, you wouldn’t have to write extra logic to re-fetch whenever new data appears. Similarly you could just make transactions to apply mutations. These transactions could apply changes optimistically and be persisted locally. Putting this all together, you can build delightful applications without the normal schleps.
So we built Instant. Instant gives you a database you can use in the client, so you can focus on what’s important: building a great UX for your users, and doing it quickly.
