The role
Recruiter in the Loop (RITL) is hiring its Founding Engineer to own development as the company grows. RITL is a working AI recruiting platform. It is in production and serving a real customer today. The product captures the context that normally gets lost in hiring, such as intake calls, screening conversations, and recruiter judgment, and structures it for AI at every step. The reasoning layer that turns that context into sourcing and matching decisions is the product.
This is not greenfield and it is not maintenance. The codebase exists and has been through a formal audit. The work now is to make it secure, harden it for multiple paying firms, resolve what the audit surfaced, and keep building new features, products, and integrations as RITL scales.
The Founding Engineer is the person writing production code, with wide latitude to make implementation decisions and shape how the system is built. RITL is looking for someone who wants that independence and treats the codebase as something to own and build creatively, not a backlog to work through.
How this role works
The Founding Engineer operates as a team of engineers by leveraging AI coding tools fluently, orchestrating Claude Code, Cursor, or whatever fits the job. You may not be doing this in your current day to day, and that is fine. What matters is that you are genuinely excited about it, already tinkering with these tools, clear on where they help and where they hurt, and able to show it. The right person can point to something real, a project, a workflow, or a repo, that proves they already work this way.
This sits on top of solid engineering fundamentals and the judgment to know when the AI is wrong. The leverage comes from someone who already knows what good looks like and uses AI to move faster. A separate behavior-layer engineer owns prompt engineering and methodology, so the focus here is on building and connecting the mechanics of the system rather than crafting prompts.
Clear communication of the work is part of the job. Pull request descriptions that explain what changed and why, a commit history that reads as a coherent narrative, and architectural decisions captured so the next person understands them. RITL will want to see real work product that shows how you document and explain what you build.
The data and the system
RITL is a data-heavy product, and much of its behavior happens inside LLM calls: what went in, what came back, what the model decided, what it cost, how long it took, and whether the result matched what the system expected. Engineers who have worked in data-heavy environments understand why that visibility is not optional. Without it, debugging is guesswork and improvement is impossible.
Having shipped a full observability stack for an AI pipeline is not required, since few engineers have. What RITL needs is someone who knows how to build it and understands why it has to exist from the start rather than be bolted on after something breaks. The system uses OpenRouter for LLM routing and is moving toward Langfuse for tracing. The bar is to treat observability as a first-class feature and build a surface where even a non-engineer can look at a screen and understand what happened across a chain of LLM calls.
Technical profile
-
Multi-tenant SaaS fundamentals
This is a real anchor. You have shipped production multi-tenant B2B software and know the trade-offs between shared-schema with row-level isolation, schema-per-tenant, and database-per-tenant, and you have lived through the gotchas. Getting RITL cleanly from working for one firm to secure and reliable for many is the immediate work.
-
API integration, done resiliently
RITL is a heavily API-driven product across sourcing providers, enrichment services, LLM routing, and ATS connections. This is core to the role, not a side task. You build integrations that survive the real world: rate limits, retries and backoff, pagination, partial failures, provider schema changes, and graceful degradation when a third party goes down or changes behavior. You treat cost and reliability as part of the integration, not an afterthought.
-
LLM API integration as a first-class operation
Streaming, tool use, retries, and cost (Anthropic, OpenAI, OpenRouter, or similar). This is the same resilience discipline applied to the calls that carry most of RITL's behavior.
-
Postgres, deeply
Schema design, indexes, row-level security, query performance, and migrations. The system runs on Supabase, but the real skill is Postgres itself. Row-level security experience specifically is a near-term need. An engineer who only knows ORM abstractions and never writes raw SQL is not the fit.
-
TypeScript proficiency, or strong working knowledge with the ability to ramp fast
A strong Python or Go developer with TypeScript exposure can ramp.
-
Next.js, Vercel, and background jobs
Next.js (App Router a plus), Vercel deployment, and familiarity with background job orchestration patterns.
You might be a strong fit if you have
- Been an early engineer, one of the first handful, at a seed to Series A startup, ideally AI-native or B2B SaaS, and felt the exact transition RITL is in: one customer working, now make it many, securely.
- Come out of a high-end studio or consultancy where you shipped real production apps, documented because clients demanded it, and integrated APIs constantly, and you are now looking for something to own rather than hand off.
- Built and shipped your own SaaS, as a technical founder or serious solo builder, and want to pour that founding-engineer instinct into a product with real customers and momentum.
Engagement
This is a founding role, not a contract sprint. The goal is someone who stays through productization, into paying-customer growth, and beyond.