Open role
Founding Engineer, Infrastructure
Own the platform underneath the product. The application layer is well ahead of the foundation it sits on, and the architecture is still yours to set.
About Handoff
Handoff is the operating system for a college football program. One store holds real league data (rosters, recruits, play by play, historical outcomes) and the program's own work: who owns an evaluation, what state it is in, what evidence backs it, who approved it. On top of that sit the surfaces the staff actually live in, from a GM reading spend against on-field output to a position coach building a game plan, plus a layer of domain agents that do the operational work around an athlete.
The role
The product has one hard rule: a figure never becomes more certain than its provenance. Models compute, language models communicate, and nothing invents a number. That constraint shapes the engineering as much as the design.
You are the first infrastructure hire, and you own the platform underneath the product. The application layer is well ahead of the foundation it sits on, which is the normal shape of an early company and exactly the opportunity: the architecture is still yours to set.
This is a build role, not a maintenance role. You will make the foundational calls, in the open, and live with them.
What you will own
A Postgres store designed for league-scale volume: schema, migrations, connection management, backup and recovery. You make the decisions the next five years of the product are built on.
Authentication, sessions, and hard isolation between programs. Authority in this product is not advisory: a position coach must not be able to reach cap data, and that guarantee belongs in the platform rather than in each surface.
Valuation models, scouting pipelines and film processing are long-running and bursty. You own the job system, the scheduler, the workers, and where the line sits between the request path and heavy compute.
Boards that stay instant as they go from one program to the whole league, on data that grows every Saturday.
Programs will run a season on this. You set what reliability, observability and recovery mean here.
What we are looking for
- Strong Python and C++. You are comfortable reaching for either depending on whether the constraint is iteration speed or throughput.
- Real distributed systems experience: queues, schedulers, consistency, partial failure, backpressure. You have debugged a system where the wrong answer was worse than no answer.
- Deep Postgres. Query planning, indexing, migrations against live data.
- You have taken something from a single-machine prototype to a durable multi-tenant service before, and you can talk concretely about what broke.
- You own deployment. “It works on my machine” is not a boundary you recognise.
Bonus
- Data-intensive or simulation-heavy systems (finance, gaming, sports, robotics)
- Experience running Python compute on managed platforms (Modal, Ray, Temporal)
- You have made hard calls about what to keep in the database versus what to recompute, and can defend them
How we hire
- 01Intro conversation with the founder (45 min)
- 02Systems design session on our actual problem: the SQLite to Postgres migration, tenancy, and the compute boundary (90 min)
- 03A paid work sample, or a walkthrough of something you built and own
- 04Two reference conversations
No algorithm puzzles. We will talk about your work and our problems.