• Making workflows reliable. Scheduling, retries, checkpointing, and recovery when a run fails halfway through. Retrying a workflow should never mean posting the same invoice twice.
• Making deployment straightforward. CI/CD, customer environments, secrets, and access controls. Engineers should be able to ship confidently and know how to recover when a deployment goes wrong.
• Keeping the data layer working as we grow. Schema design, query performance, and knowing when Postgres is enough or when a workload needs something else.
• Understanding what happened. Logs and traces that let us follow a run across agents and external systems, investigate a failure, or answer a customer’s question months later.
• Handling unreliable integrations. Systems like NetSuite, Oracle, and Salesforce come with rate limits, partial failures, and their own ideas about availability. Our infrastructure needs to account for that.
• Operating what we build. Sharing on-call, responding to incidents, and following through on fixes that prevent the same problem from happening again.

There’s plenty to build. Part of the job is deciding what needs a shared solution, what can stay simple, and what isn’t worth building yet.

Who we’re looking for

We want to work with people who love technology and care about what it makes possible for others. For this role, that includes caring about the engineer using your deployment tools as much as the customer relying on the system.

You’ve operated software that other people depended on. You know what it’s like to investigate a production failure with incomplete information, make a careful fix, and come back later to address the underlying problem.

You don’t need to have used every tool we use. We care about your understanding of databases, distributed systems, and production operations—and your judgment about how much complexity a problem actually needs.

• You’ve owned something in production that other people depended on, and you were the one dealing with it when it broke.
• You keep up with technology because you can’t help it. You try new tools, form opinions from using them, and rethink how you work when you find something better.
• You’ve changed someone’s mind about a technical decision with evidence, and you’ve had your own mind changed the same way.

We’re here to help our customers succeed. That takes care, ownership, and an honest sense of priorities. We want someone who can get deep into a technical problem and still ask whether it’s the right problem to solve.

Who you’d work with

We keep our hiring bar high, even when that means leaving a role open for months. Our engineering team is small and moves quickly, led by Thomas Le Jeune , formerly eng leader at Dropbox. The other engineers have each built their own startups focused on post-training and reinforcement learning environments, with backgrounds at Stanford, Amazon, and Waterloo.

Our co-founder and CEO, Vas Moza , was an engineer at Meta before starting Varick. Daniel , our Head of FDE, previously served as COO at Citadel Securities. You’d work with all of them directly and help shape how we build as the company grows.

Why Varick?

• You’re joining while the foundations are still being built. We already work with billion-dollar companies, and there are important decisions ahead about how our systems should work. You’d help make those decisions and build what follows.
• Your work will carry across customer deployments. A better way to deploy, recover a failed workflow, or investigate a problem can help every engineer shipping agents here.
• You’ll see how your decisions hold up in practice. You’ll work directly with the engineers using your infrastructure and hear when something helps, when it gets in the way, and what needs to change.
• Meaningful equity in an early team. You’d help build the product and own a share of the company behind it. We’ll walk you through the grant and its terms so you understand what we’re offering.

How we work

We work in San Francisco, in person, five days a week. We expect all to show up with high energy, share learnings, and whiteboard problems together. From there we commit and move on to the next problem.

We work hard, and we want that effort to be sustainable. There are times when we need to put in extra hours, including weekends. We take those commitments seriously, and we take people’s time outside work seriously too.

Applying

Email with whatever best shows us how you think and build: a repo, something you shipped, or a paragraph about a system you’ve owned. We’d love to hear about a difficult infrastructure problem you worked through and the decisions you made along the way.

We read every application.