What you would do
- Features from the schema to the screen — a Postgres migration, the row-level security on top of it, the service layer, and the React that renders it.
- The editor: a ReactFlow canvas, a table view, a document view and a presenter mode that all read and write the same procedure and have to stay in sync.
- The AI features: drafting a procedure from a description or an uploaded document, answering questions about one, and being clear in the UI about what the model actually did.
- Performance and correctness in a multi-tenant app, where a leak between organizations is the worst bug we could ship.
What we look for
- Several years writing production TypeScript and React, including the messy parts: state that outlives a component, data that arrives out of order, complicated forms.
- Real Postgres experience. You can read a query plan, and you know why an access rule belongs in the database rather than in a handler.
- You write things down: a design note before you build, and comments that explain why rather than restating the code.
- Comfort owning a feature all the way out, including when it is live and something is wrong.
Nice to have
- Next.js App Router and React Server Components in production.
- Supabase, or another stack where auth, storage and the database come together.
- Having built with LLMs somewhere real: streaming, structured output, and knowing when a model is the wrong tool.
Optional. Not having these would not rule anyone out.
The first ninety days
By ninety days you would have shipped a feature touching the database, the API and the editor, and be the person the team asks about that part of the system.
How we hire
- 1A thirty-minute conversation about the role and what you are looking for.
- 2A longer conversation about work you have done.
- 3A short exercise or working session, scoped and agreed in advance.
- 4References, and a decision either way.
Applications recently closed
Questions about this role or how we hire? Email support@essoflo.com.