Instant (YC S22) Is Hiring a 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 of 4 in San Francisco. If you:
- Are obsessive about type ergonomics (even with how types show up in intellisense)
- Enjoy crafting UIs that people use for hours
- Want to build a sync engine to enable the next Figma or Notion
Then we want to talk to you! So, why those three points? 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. 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 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 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 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 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
Instant’s client SDK implements a sync engine:
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, Joe, Stopa), 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 🙂. Send us an email: founders@instantdb.com with a bit about yourself, and a project you’ve worked on. If you’ve built a Typescript library, that’s a big plus, but not required.
