Full-Stack Engineer
You’d build features end to end inside businesses that already run on them: the data, the API, the screens, and the checks that decide whether your change can go live. It’s a small team, so you’ll own a lot, and hear about it fast.
A typical week: read the part of the system you’re about to change, decide what the data should really look like, then build the whole thing: database, API, screen and tests. Nothing gets thrown over a wall to another team, and nothing goes live because someone was in a hurry.
- Build features end to end in TypeScript and React, on a Node or Python back end with Postgres underneath.
- Design the data properly: one reliable record for each business concept, with rules enforced by the database, not remembered by the app.
- Write the tests that make security-critical code something that must pass, not something that should.
- Work inside a client’s standups and deadlines, and hand the work over so their own team can carry it on.
- Leave the runbook and the decision notes behind. If it only lives in your head, it isn’t finished.
- Strong TypeScript and React, and a back end you’re truly fluent in: Node or Python.
- Real SQL. Not just an ORM you’ve never looked underneath.
- You’ve shipped something people depend on, and stayed to fix what broke.
- Plain writing. Explaining a trade-off to a non-technical owner is part of the job.
- Comfort with an automatic check blocking your own change when it should.
Not required: a degree in the field, strong opinions about frameworks, or a portfolio of side projects. What you shipped, and what it cost to run, matters more.
- What reviews find in what you shipped. It should fall over time.
- Anything that broke twice should become an automatic check, built by you.
- The real result: the first week you’re off the project and nothing breaks.
- Show us: Use the form below to send one thing you’ve built and are proud of. We read everything that comes in, and if there is a fit we’ll come back within a week.
- Work through something together: An hour or two with the people you’d work beside, on a real problem from our work.
- Decide: A conversation with the two people you’d work beside, then a clear yes or no, with the reason.