Contract Reviews Meet Code Reviews
Anthony Corletti, founding engineer at Crosby
Welcome to The First Commit, a series profiling founding engineers. My first guest is Anthony Corletti, a serial entrepreneur and 3x time founding engineer who made the leap to join Crosby as one of their first engineering hires back in March 2025.
Crosby is an AI-powered law firm that’s reimagining legal services with tech-enabled operations. Anthony joined when the company was just founders and an idea, and has since helped scale the engineering team from zero to 25+ people in under a year. We talked about his “Care Meter” framework for evaluating startup opportunities, why developer tooling and lawyer tooling aren’t so different, and what it really means to take on founding-level risk.
Ben: You mentioned that “Founding Engineer” wasn’t really even a thing 10 years ago. What’s changed?
Anthony: Yeah, it’s a new thing. Ten years ago, a founding engineer wasn’t really a role people talked about. But now you’re starting to see this model that a lot of firms and early-stage companies are putting together—like, what does this first team look like when you assemble your initial group? I definitely have a lot of thoughts and experience on that.
Ben: Walk me through how you ended up at Crosby. I know you weren’t exactly looking for AI legal tech.
Anthony: (laughs) I was not interested in AI legal. At all. You were actually the third person who pointed me to Crosby, and all three of you came from completely separate parts of the world. I was like, “What the hell is this?” None of you were even connected on LinkedIn, so I thought it was really strange. But after the third time, I was like, “Sure, I’ll talk to them.”
Really, it was talking to John. I was like, okay, I like this guy. Ended up meeting John and Ryan in person. At first I thought they were looking for someone younger, an earlier-career engineer profile. But when I met them, I was like, even if that’s true, I don’t really care. I really like spending time with them. I think there’s something here.
Ben: So it was the people first, not the problem?
Anthony: The people were huge. But I also evaluated their business. They pitched me: “We’re not selling software. We’re selling a service—a law firm—but it’s going to hopefully have the margins of a software company.” I was like, okay, that’s really compelling.
For me, it came down to: Do I like working with them? Do I have the right skills and experience? And does it map up with what I’m passionate about?
Ben: But you came from developer tooling and infrastructure. How did you go about that?
Anthony: Yeah, I had to sideline a lot of my passions—like getting into deeper infrastructure, reimagining different levels of abstraction developers work with for compute. That’s not what we were going to be working on at Crosby.
But what I could do was take my mental model of how a developer has really effective workflows and think about it from the lens of a lawyer. Like, what’s the lawyer’s dev environment? That was my own compromise. You can work on what you’re passionate about anytime. This was about finding the right problem.
Ben: You mentioned a framework you use for making these decisions—the “Care Meter”?
Anthony: Yeah, the Care Meter. It’s this framework I wrote about for evaluating opportunities. Basically, you stack rank three things from 1 to 10:
First: How much do I care about this business or problem? One is trash, ten is your family or loved ones.
Second: Rank your attachment to a specific solution. For me at Crosby, I could list ten things I’d be excited to pursue, so I ranked that pretty low, there wasn’t one solution I was really tied to.
Third: Rank the problem. The more time I spent watching Ryan do redlines and understanding John’s vision to grow the team, I realized - oh, we’re going to grow this company to be like the Google of law firms. We need a lot of engineers to do that, and engineers need to spend a lot of time with lawyers to understand the complexities. That’s a really compelling problem. I ranked it 9 or 10.
For me, those two things - caring deeply about the problem but not being married to a solution - pointed to yes.
Ben: There’s an interesting connection between developer tools and lawyer tools. How did you see that?
Anthony: (laughs) There was this moment when I was watching Ryan redline some stuff, and I could see he was sad. I was like, “Dude, what’s up?” He’s like, “Man, this guy’s just leaving nits all over this document.” And I was like, “Nits? What’s a nit?” He said, “Just nitpicking everything.”
And I immediately thought: engineers have to deal with that in a pull request. He’s like, “What’s a pull request?” So I explained it’s where you merge code and review changes.
I saw there were a lot of similarities in how lawyers and engineers think. If you want to build a tool for an ML engineer or a lawyer, go sit with them for two hours and you’re going to learn so much about their workflow.
Ben: This is your third time being a founding engineer. What surprised you about the early days at Crosby?
Anthony: First, it was understanding who I’m making the software for. At the time, it was Ryan and Kush, our head of ops. I had to understand what they think about when they’re working; how to build a system that incentivizes urgency for a reimagined law firm.
A lot of it was changing expectations of how things should work and designing for the operator. Just getting something up, iterating, and iterating. One of the things I like to think about is: ship something now so you can think about how to ship it better later.
But also, and this is something John really emphasized, we’re going to be interviewing a lot of people, and we need to create a space where people feel they can do their best work. That’s tough when things are on fire and you’re building super fast. But you want someone to feel like when they’re here, they’re getting to know everybody, there’s good team camaraderie. Having that interview process be smooth and effective is super challenging.
Ben: How would you recommend people think about the founding engineer role?
Anthony: I think you should do it if you bond really well with the founders—like, “I feel like I could work with these people for a few years.”
You have to be willing to change a lot of your preconceived notions about how things should work. You need to iterate fast, hold on tightly to something, but also let it go if it’s not working.
I also think people who love to constantly level up their systems—people who ruthlessly prioritize speed. Like, if it took me two weeks to build a CI/CD system, how could I do it in two hours? That’s the profile of founding engineers. They’re always trying to make something better, faster.
And from the founders’ perspective, they’re looking for people with the right kind of slope. Does this person show they’re excited to build the company, wear multiple hats, jump across different things, maybe do stuff they never even wanted to? Right now I’m doing random IT stuff. Eventually we’ll get someone for it, but you just have to be ready to do a whole bunch of stuff. It’s not just about executing—it’s also about having fun and doing things that wow people.
Ben: Can you give me an example?
Anthony: (laughs) Okay, so there’s this candidate we’re trying to close. They’ve said no to all these other companies. John tells me they love this restaurant called [redacted]—it’s a place right across the street. He’s like, “I wonder if we can get them [redacted] swag.”
So today I figured out how to get a [redacted] sweatshirt. Hopefully it closes the candidate. But that’s the kind of energy—the founders have it, and as a founding engineer, you want to keep that flowing through the whole organization. It creates a really solid foundation.
Ben: One pattern I hear a lot is: “I want to be a founding engineer because I want to be a founder.” What do you think about that?
Anthony: I don’t think you should anchor on that. If you really want to be a founder, just go do it and try it. I don’t think being a founding engineer is one-to-one with being a founder, because you have so many different expectations to manage as a founder—external investors, people looking at the company from very different angles.
So I’d tell people: write down why you think you want to be a founder, and think about all the parties you’d have to work with.
Ben: There’s this narrative that founding engineers take “founder-level risk” without founder-level equity. How do you think about that?
Anthony: I very much disagree with “founder-level risk.” I’m not doing investor relations. I don’t have to do all the sourcing—John deals with this incredible top-of-funnel for engineering talent. That’s a lot of work. As a founder, you’re very tightly coupled to the company. As a founding engineer, if a great opportunity comes along, you’re not tied as hard to it.
That said, you really have to bond well with the founders, and you have to feel that excitement. That excitement has to be something you’re willing to carry through. And really great founding engineers are also really good at communicating their needs. Like, maybe in two years I feel I need to start something. Do you feel comfortable communicating that? Great founding engineers are great communicators.
Ben: Last question—what’s it been like working with John and Ryan through this hyper growth?
Anthony: They’re really great examples as founders who are staying connected to the team. We still meet every week, they still make themselves available even though they have a ton going on. I think as long as we can keep that up going into bigger phases of growth, that’s going to be a really great recipe for success.
For Anthony, the founding engineer role isn’t just about shipping code, it’s about building culture, creating systems that scale, and having the courage to join when there’s nothing but conviction and a problem worth solving.