InstantDB: Founding Typescript Engineer

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

About us

We're looking to build the next Firebase. We want to make it easier for developers to build delightful applications.

We were part of the summer 2022 batch in YC and raised a $3.4M seed round from a slew of great angels like former Firebase CEO James Tamplin, Paul Graham, Greg Brockman, and Jeff Dean

Internally we have a hacker mentality — we build quickly, we are kind to each other, and relentlessly focused on making our users happy. We also love sharing our ideas with the broader community, with a slew of our essays making the top of HN [1] [2] [3]

If you like videos, you can watch Stopa, our CTO, talk about Instant at Clojure Conj

About the role

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: DataAttrDef<string, true>;
    }, {}, void>;
    bookshelves: EntityDef<{
      title: DataAttrDef<string, 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 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

Apply

Our vision is to be the infrastructure for all apps of the future. If this jives with you we should really talk 🙂. Send us an email: founders@instantdb.com with a bit about yourself, and a project you've worked on.