InstantDB Founding Engineer

Hey there! InstantDB (YC S22) is looking to hire our founding engineering team! We think we’re a rocket-ship that’s going to power applications of the future 🚀

We’ve put together a page explaining what is Instant, who we are, who we’re looking for, and what we can accomplish together 💪

By the end of this page we hope you’re motivated to apply or send over this page to your favorite hackers 🧑‍💻

What is Instant?

In two sentences: We’re building the next Firebase. We want to make it easy for developers to build best-in-class applications like Figma, Notion, and Linear.

What does that actually mean?

Imagine you’re a hacker who loves building apps. You’ve read all the PG essays, came up with 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 three-tier architecture with client, server, and 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 UI’s 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!

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.

To see Instant in action, check out this video below:

To learn more about our architecture, check out our essay A Graph-Based Firebase

Who is Instant?

We’re Joe and Stopa, engineers, best friends, and co-founders. We first met in San Francisco in 2014 and worked together as senior and staff engineers at Facebook and Airbnb.

When we worked at Facebook, most designers used Sketch. At that time no one thought there could be something better. Figma came out and changed the game. Similarly, in the 2010s, Evernote was one of the best note taking apps. In 2024 most people use Notion instead.

In 2022 we went through YCombinator to build Instant and raised from top investors like Paul Graham, Greg Brockman, and James Tamplin, the original CEO of Firebase.

After being heads down for 2 years, we open-sourced and had amassive reception on Hacker News. We are one of the top Show HN launches of all time.

Who are we looking for?

First and foremost, we want to work with people who we will be friends with for a life time. We love high-integrity, optimistic, and principle-oriented people. Taking inspiration from Facebook, Airbnb, and YCombinator we deeply resonate with these three core values

• Move fast
• Be a host
• Make something people want

This is the hacker mentality we strive for — building quickly, being kind to each other, and honing in on delivering value.

On the technical-side, here are two example projects we plan to take on soon and would love help on.

Load testing strategy for our sync engine. We want to build a suite to 1) stress test different scenarios and 2) establish 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 for situations like:

• Many clients connect and subscribe to large amounts of data (thundering herd)
• Local experience for client making writes when there is a lot of subscribed data
• Local experience for clients when another client for the same app is blasting transactions (e.g. streaming updates for a stock app)
• Local experience for clients when another client for different app is blasting transactions (noisy neighbor)
• Local/Server experience when many clients from many apps make many transactions

… and many more

Rebuild our client-side reactive-layer. It’s currently a state machine that is hard to introspect and follow simple chains of changes like “what happens when a transaction is made?” or answer “what is the size of the pending transaction queue?” We want to re-build this in a way that makes it easy to 1) test chains of changes and 2) have dev tooling for introspecting client-side state.

There’s a lot of opportunity to contribute to Instant’s architecture. If either of these sound like something you’d enjoy working on we’d love to talk!

Additional Stats

• Location: We’re based in San Francisco, CA!
• In-person only: Not open to remote at this time — we want to hack together!
• Compensation: Sliding scale between 0.5%-2.5% equity and 150k - 210k base + medical/dental/vision benefits
• Tech Stack: Typescript + React on the frontend, Clojure on the backend, Aurora Postgres

Want to apply?

Woohoo! Please send us an email at founders@instantdb.com and include a side-project you've worked on (if it comes with a GitHub, that's a huge plus!)