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.

Skills: TypeScript

Hey team! We’re’re hiring a Founding Typescript Engineer to join our team of 4 in SF.

1. You are obsessive about type ergonomics (even with how types show up in intellisense)
2. You enjoy crafting UIs that people use for hours
3. You want to build a sync engine to enable the next Figma or Notion

Then we want to talk to you!

So, why those three bullets? Let us explain:

1. You are obsessive about type ergonomics

One of the benefits about using typescript in a library is the developer experience you can offer your users. Types can do so much more than just catch typos. Types are a tool. They give you autocomplete and good feedback; shown in the right moment they can make someone's day.

Instant is typed. It took some serious type fu, but the upshot is the users get autocomplete and typesafety as a result. And right now types are a first cut. Here's some of what's ahead:

Type where clauses

Imagine you are building a goodreads alternative. You want to write a query like: Give me profiles that have "Count of Monte Cristo" in their bookshelves. This is how it would look in Instant:

{
  profiles: {
    $: { where: { "bookshelves.books.title": "Count of Monte Cristo" } },
  }
};

And with it you'd get those profiles. But bookshelves.books.title is typed too broadly: any string is allowed. This means users could have spelling mistakes, or forget which relationships exist on profiles.

Well, we already have access to the schema. We could type the where clause. This way, when a user starts writing "booksh", we could autocomplete with all the relationships that live on profiles!

This is tricky (there's a lot you can do in a query), but it would be a huge benefit to users.

Improve intellisense

Or speaking of schemas: this is what you'll see in Typescript when you hover over one:

const schema: InstantSchemaDef<EntitiesWithLinks<{
  profiles: EntityDef<{
    name: DataAttrDef<string, true>;
  }, {}, void>;
  bookshelves: EntityDef<{
    title: DataAttrDef<string, true>;
  }, {}, void>;
}, {
  ...;
}>, LinksDef<...>, RoomsDef>

Now, complex types can look notoriously daunting in intellisense. Some of the complexity is unavoidable, but there's a lot that can be done to improve it. For example, is it really necessary that the hover includes EntitiesWithLinks, EntityDef, DataAttrDef?

Some may think it's not worth fretting over intellisense output. But you know this differentiates the best libraries. Great types reap great benefits.

Performance, utility types...

And the list goes on. We want to add more tests for type outputs (one project we're considering is to write a library that tests intellisense output). We want to write benchmarks to see how types perform in larger codebases. We want to improve how you define schemas and how you write transactions. We want to add more utility types, so users can build their own libraries on top of Instant.

2. You enjoy crafting UIs that people use for hours

Today Instant ships with a CLI tool and a Dashboard.

Since Instant is a core part of our user's infra, they end up spending hours every day interacting with it. The onus is on us to make their experience as delightful as possible. UIs make a real difference here. People may not consciously notice it, but every detail adds up. There's a lot of work to do:

Migrations in the CLI

Right now, you can push your schema with the CLI, but we don't support any destructive actions. You can add a column, but you can't delete it (You can do this manually). We held off on destructive actions in the CLI, because we wanted to make the right kind of UX: something that feels natural, but doesn't let you shoot yourself in the foot. Can you help design it and implement it? Maybe it's time we add migrations, or take inspiration from terraform.

Better Sandbox

In the dashboard, we have a sandbox that lets you run queries and transactions:

You can dry-run transactions, make queries, and see how your permissions work. Users live in this tool for hours. But there's a lot missing here. For example, could you save snippets, or have a history of the changes you've made to your sandbox?

Better Explorer

Or take a look at the Explorer. It lets you visually query and change data. This often replaces custom code users would have needed to write for an admin panel. You can already make queries, create rows, link objects, and upload files:

But this is just the beginning. What else do users use an admin panel for, and how can we just give it to them? We want to make an editing experience on the level of Airtable, available to every dev before they even start building their app.

Rules, Examples...

And there's so much more. We want to improve our permissions language, and make it easier to introspect. Our examples page shows a few ways you can use Instant, but what if instead it had hundreds of examples and was searchable? The list goes on!

3. You want to build a sync engine to enable the next Figma or Notion

Inside the SDK there's a client-side database which can run queries just the like the server does. The client-side DB is what makes it possible for Instant to work offline, and to get optimistic updates out of the box. And it's full of problems that make computer science textbooks come alive:

• Better joins: the client runs a nested loop to implement joins. But as we increase how much we cache, nested loops could become a problem. Perhaps it's time to add hash joins!
• Better indexes: we use a map of maps for our indexes. This works, but comparison queries will be less efficient then they have to be. Perhaps it's time to consider writing an OrderedSet
• Better introspection: we built a state machine to manage how different events interact: websocket updates, connection changes, client / server changes. But it's quite hairy and hard to reason about. Can we make it easier to observe events and replay them? Perhaps we could look into the actor model or structured concurrency for inspiration.
• Better local storage: we treat IndexedDB as a key values store and serialize large chunks of state. Can we serialize in smaller chunks instead?
• Less re-renders: Right now queries can change more than is needed. We want every update to be finer-grained, so users have less re-renders.

If we do this right, we have the chance to build an abstraction that is both easy — you could build any app quickly with it — but also scales to the complexity of apps like Figma or Notion.

Aside: the Backend

The client SDK talks to a backend written in Clojure and Postgres. Sometimes, you may end up in Clojure. We don't expect you to be a Clojure expert, but if you are excited about hacking on the language too, we'd be thrilled to onboard you.

About us

You may be thinking to yourself...that's a lot of responsibilities. From typescript types, to client side databases, to UIs.

We hope that excites you in the same way it does us: lots of hard problems are one of the reasons we love working on Instant.

We're a team of 4. Three of us are in San Francisco (@Daniel Woelfel , @Joe Averbukh , @Stepan Parunashvili ), and one of us are in Berlin (Niki). Joe & Stopa (the founders) have known each other for over 10 years, and worked across Facebook and Airbnb together. Daniel (first engineer) and Stopa worked together at Wit.ai and Facebook, and have been friends for 10 years. Niki shipped datascript, and wrote one of the first essays about the kinds of web applications Instant wants to empower.

We love working together. We aim to work with people who we will be friends with for a lifetime. We love high-integrity, optimistic, and principle-oriented hackers who love what they do. Internally we have a hacker mentality — we build quickly, we are kind to each other, and relentlessly focused on making our users happy.

Additional Stats

• Location: We're based in San Francisco, CA!
• In-person or open to relocation only: We're a small team and we really do prefer all working together in person!
• Compensation: Sliding scale between 0.5%-2% equity and 150k - 200k base + medical/dental/vision benefits

Apply

If you've read this far and are excited, we should really talk 🙂. Tell us a bit about yourself, and a project you've worked on.

Our architecture is inspired by Figma’s LiveGraph and Asana’s LunaDB. We also built Instant to be multi-tenant and don’t need to spin up an actual database for users. This enables us to give users a database in <10ms with a click of a button. And unlike our competitors, we can offer a free tier to users where their projects are never paused and there is no limit to the number of active projects they can have.

To learn more about how Instant works under the hood, check out our essay A Graph-Based Firebase:

https://www.instantdb.com/essays/next_firebase