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 🧑💻
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
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.
First and foremost, we want to work with people who we will be friends with for a lifetime. We love high-integrity, optimistic, and principle-oriented people. Taking inspiration from Facebook, Airbnb, and YCombinator we deeply resonate with these three core values
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:
… 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!
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!)