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: JavaScript, TypeScript, PostgreSQL

Instant is a real-time database you can use on the frontend. We give you the best of both Firebase and Supabase, a sync-engine with support for relations. This is the kind of tech that companies like Figma, Notion, and Linear build internally to power their products (Try out the demo)

We’re looking for a founding Typescript engineer to join our team in San Francisco. We’re looking for someone who:

1. Are obsessive about type ergonomics (Even with how types show up in intellisense)
2. Wants to build front-end tech (read: a sync engine!) to enable devs to build delightful applications
3. Enjoys crafting UIs that people use for hours

Our current stack looks like so:

• We offer client SDKs, a CLI tool, and web GUI to interact w/ Instant. All written in Typescript
• We have a server written in Clojure for managing websocket connections, parsing queries, running permissions, and broadcasting novelty.
• All of which sits on top AWS Aurora Postgres

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. We don’t just want to build a great database. We want people to enjoy using it.

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 all the 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. That’s kind of sad; users could have typos, 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 lot you can do in a query), but it would be a huge benefit to users.

Improve intellisense Or speaking of schemas. Users can define schemas, and we’ll use it to generate types for them. When you hover over a schema, this is what you’ll see:

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

Now, typescript generics 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.

Aside from improving the type experience, there is a lot of opportunity for improving the current surface area of Instant.

Better 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.

Permission REPL We currently have Right now we have a GUI sandbox that lets you run queries and transactions. This can be very useful for debugging but there’s a lot missing here. One of the biggest pain points users have is crafting and testing permissions. It would be great if we had a better experience for rapidly testing permission rules against data.

Sound interesting? If so here’s a few more details :)

• 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

Our vision is to be the infrastructure for all apps of the future. If this jives with you we should really talk 🙂.

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