Finding your first 10 customers, with Andy Lee from DeepTrace
Andy Lee on how a team of ex-Tesla and SpaceX engineers with zero sales background landed Opendoor as an early customer, why hand-written personas beat LLM-generated outbound, and the internal tool they built with Claude Code to scrape X for engineers complaining about on-call pain.
Andy is the cofounder of DeepTrace, an AI reliability platform that helps engineering teams investigate incidents and fix problems in production. His team came in with zero sales background — all engineers, several from Tesla and SpaceX — and had to figure out go-to-market from scratch.
We get into how they landed their first customers through raw outbound volume, why hand-crafted persona-based messages beat AI-generated ones, the engineering-style tools they built to find the right people to talk to, and how they run a sales call before the product is even fully built.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
You were an engineer at Tesla and SpaceX with no sales background. How did you land your very first customers?
Especially early on, what buyers are actually buying from an early-stage startup isn't just the product, it's the whole package of you and the product. One of our first customers was actually Opendoor, now a Fortune 1000 company doing billions in revenue a year. That happened because I sent thousands of LinkedIn messages just asking for mentorship, and one of those, the CTO of Opendoor, decided this kid seemed scrappy and hungry enough to grab a coffee and hear his story. That relationship turned into one of our first customers. Technical founders really underrate how much they're selling themselves and the team behind the product, not just the product itself. And for dev tools specifically, being able to talk to an actual engineer instead of inside sales, who usually don't really understand what your life as a developer is like, is a real advantage — founders can go a mile deep on details the way a practiced opener-and-closer salesperson often can't.
How did you go from that first dream customer to the next ten?
Our actual first customer was a stablecoin company called Rain, based in New York, and after that it was really just raw volume of outbound. As engineers, you're used to being measured by the quality of your output, so thinking in terms of a sales pipeline is a pretty unnatural mental shift, and I think most technical founders heavily underrate how much volume they actually need — bump it up a couple orders of magnitude from what feels comfortable. During YC, for two whole months, everyone on our team of four maxed out their LinkedIn connection requests and Sales Navigator InMails every week — around 250 per person, so 1,000 a week just on LinkedIn, plus a large volume of cold email on top of that. You can genuinely brute-force your first ten customers this way and get the early momentum you need to figure out what comes next.
What actually made those messages work, beyond just the volume?
Rather than pitching on the first message, we found it worked much better to send messages that were genuinely curious — actually asking the other person for their expert advice, putting them in a position where they feel like they have something to offer you. That starts the relationship in a way that isn't purely transactional, and both sides get to know each other rather than one just pitching the other. That's literally how Opendoor happened — I was genuinely asking for mentorship from CTOs of huge companies because we weren't familiar with enterprise buying cycles or dev tool needs at that scale. On calls, connecting over a shared war story really mattered too — every engineer who's worked a job for a few years knows the visceral pain of getting paged at 3am, and being a YC startup close to the frontier of new dev tools gave us something genuine to talk about that wasn't just selling.
Were you hand-personalizing every single message, or using AI to generate them?
We had personas rather than one-off personalization — the message you'd send a VP of engineering at a Fortune 500 looked pretty different from what you'd send our champion at Mintlify. But we didn't use large language models to write them; we hand-wrote a set of templates. Before we started reaching out at all, the whole team sat down and wrote a five-to-ten-page doc on the different personas that would resonate with our product, why they'd resonate, and in what way, then hand-crafted LinkedIn messages for each one. I think creative, valuable outbound writing is one of the last things language models will do well, because it requires taste and isn't very verifiable. There's still a lot of value in standing out as a real person in your outbound — people are fluent enough with what LLM-generated text sounds like now that they can tell, and a lot of founders assume their messages aren't even being read when actually even CEOs and CTOs of huge companies read most of what lands in their inbox. It's really about the writing being human and speaking to that specific person.
What response rates should people actually expect, and how do you find the right people to target?
It's very context-dependent — a compliance tool selling to early-stage startups might see a much higher response rate than something selling million-dollar enterprise contracts. For us, out of every 100 LinkedIn messages, we'd get roughly 40 accepted connections, and of those, half to 75% would respond in some way — not all converting, but that's roughly the ballpark I'd aim for on LinkedIn specifically, where there's less noise than email. If you're only getting a couple of hits a week, the first thing to root-cause is whether you're even talking to the right people — most AI dev tools products are delivering real value, so I'd focus less on doubting the product and more on iterating on the target. A surprising thing we found: younger people, regardless of seniority or company stage, were just much better able to grok the value of DeepTrace, probably because they're more AI-native and have more experience with similar tools. You want someone senior enough to actually push a deal through, but who also feels the pain at a visceral level — often that's closer to a VP of engineering, an engineering manager, or even an IC than the CTO. We also look at whether someone reads as a bit of a rebel who dislikes process, since a ten-step procurement process with five stakeholders is basically death for an early-stage startup — and one signal for that is whether they've worked at a startup before, regardless of their current role.
You've applied an unusually engineering-heavy mindset to sales — tell me about some of the tools you built.
We're all engineers, and with tools like Claude Code, if you have a sales idea you want to test, it's just a couple of prompts away. We got access to the X API and built an internal tool that scrapes specific X feeds looking for people complaining about incident response, downtime, or an upcoming on-call shift — that's actually how we first connected with Mintlify, who were going through a painful migration and whose engineers were understandably anxious about it. We've also been experimenting with paid ads, which we were naturally skeptical of as engineers, inspired by how well a company like Numeral has done with it. Since paid ads is really a numbers game that comes down to testing a lot of copy, we turned our ad copy into SVGs, basically code, so we could use Claude Code to spin up dozens of variations a week and see what performs. It's not amazing yet at editing the visual design of the SVG itself, so we built a Claude skill that steers it toward just varying the copy, formatting, and color scheme, which turns out to matter a lot in performance marketing. Early days, but promising results, and I don't think this stays a niche way of doing performance marketing for long.
How do you run an actual first sales call, especially before the product is fully built out?
Especially in the zero-to-one phase, you really need to sell them on yourself before anything else. For roughly our first five to ten customers, I'd start most calls just introducing myself — where I grew up, why I started the company, a bit about the team — and connecting with the other person on a non-transactional, interpersonal basis before getting into discovery questions. On the product side, we sold well ahead of where the product actually was. I've heard Palantir has figured this out really well, building demos that just wow the buyer even if they're partly mocked up. But if you're a YC company under a million in ARR, I'm not sure that matters as much as the relationship — you're essentially selling a team that's going to do work for you. We'd show whatever demo we had, with fairly obvious feature gaps, and sell toward what it could become. Our product at the very start was basically just a Slack bot, but we didn't open the call selling a Slack bot — we opened selling an automated way of running production, and once the right person buys into that vision, it becomes about whether they trust this team to get them there over the next three to five months. That said, you still need to show a real kernel of value up front — it can't be smoke and mirrors.
How do you think about pricing and trials in the early days?
At the very beginning it was a genuinely tricky conversation, because we hadn't fully figured out our own pricing yet. I think software, and dev tools especially, is almost inevitably moving toward usage-based pricing. There's no single right way to do it, but it has to be clear and transparent, especially for developers, who want that more than buyers in a lot of other verticals. For us that's a flat SaaS fee for a certain amount of usage plus overages on top. We do run trials, and because of how early-stage we are and the real risk buyers take on trying out a startup, we typically charge a nominal amount upfront, maybe 5 to 10% of the true contract value, prorated for a two- or four-week trial. For a product that needs real onboarding or change management, having a little skin in the game changes the buyer's behavior and makes them more invested — we've seen that convert pilots more successfully than a fully free trial.
What does DeepTrace actually do, and what stops someone from just pasting their logs into Claude Code instead of buying a tool?
DeepTrace is a reliability platform — reactive tools that help you root-cause and fix incidents, and proactive tools that monitor your system, catch issues you're not getting alerted on, and bring them to you in Slack and our web interface. My cofounder was on call for a banking product, getting paged nearly every night for a month straight; I'd seen the same problem from the big-tech side at Tesla, on the Autopilot and Optimus teams, where it was strange that out of thousands of engineers, only one or two people in the whole company could actually debug certain systems when they broke. On the Claude Code question: all of our customers already actively use it and had been trying workflows like copy-pasting a Sentry issue in. What we add is, first, real integrations across every place your data actually lives — Sentry, logs in ClickHouse or Datadog or Grafana, runbooks in Notion, metrics elsewhere, data in Vercel — all in one place. Second, and I think this is the bigger one, getting the right context to the right place at the right time: even the best on-call engineer you know would be pretty useless dropped into a new company on day one, because of everything they're missing. We run agents in the background that do deep research on your system, scan every deploy and understand what changed and what to expect, and read Slack messages, including someone saying an alert was a false alarm, then investigate why and record the baseline — building a rich, living memory of how your system evolves and how people actually debug it. Third, there's a category of data even the best coding agents aren't great at yet, like time-series and anomaly detection, which even humans struggle with — we lean on more traditional machine learning and statistical methods there, and chunk that data up in a way an LLM can actually use. That's where a lot of our value sits versus someone hacking something together with Claude Code alone.