Ten emails a week, and half of them reply

Naman Bansal took Manicule to $30K MRR during YC on ten to fifteen cold emails a week: a narrow ICP, three signals that have to be true at once, and a four-line email that opens with work already done

Naman Bansal of Manicule posted the exact process he used to go from zero to $30K MRR in two months during YC. It is unusually specific for a thread of this kind: not "personalize your emails" but the three conditions a company has to meet before he will write to it at all. Worth writing down properly, because the shape transfers even though his particular signals will not.

His numbers, as he states them: ten to fifteen emails a week, replies on more than half, and roughly eight in ten first meetings turning into a pilot. Take the percentages as his rather than as a benchmark. The mechanism underneath them is the part you can copy.

1. An ICP narrow enough to sound like a mistake

Manicule does devrel and AEO for devtool companies. Bansal points out that they could sell AEO to any B2B SaaS company and deliberately do not, because specificity is what separates you now that anyone can build anything.

There is a more mechanical reason to be narrow, and it runs through everything else in his process. You can only guess at timing if you know what a good month looks like for your buyer, and you can only write an offer in their vocabulary if there is one vocabulary. Widen the ICP and you lose the ability to recognise a signal when you see one. Every step below is downstream of this one.

2. Stop selling to people who are not shopping

The line worth stealing: "I'd rather convince a hot lead to go with me than convince someone random why they have that problem and why we are the solution for it. It's double the work."

Most cold outbound quietly takes on both jobs. You are teaching a stranger that a problem exists, then arguing you are the fix, in the same two hundred words, to someone who did not ask. Drop the first job and the email gets shorter and the odds get better. That means your targeting has to do something harder than describing a company: it has to find evidence they are already unhappy about the thing you fix.

3. Timing: three signals, all at once

This is the core of it. Bansal does not target devtool companies. He targets devtool companies where all three of these are true:

• Funded within the last three months. Budget that exists and is dated, rather than budget you hope for.
• Bad docs. The problem is present, and he can see it from outside without asking anyone.
• Hiring a devrel, educator or similar. They have already diagnosed the problem themselves and put money against it.

The conjunction is doing all the work. Each of these alone is weak. Funding on its own is the most farmed trigger in B2B outbound and everyone with a Crunchbase seat is already emailing that list. Bad docs on their own tell you nothing about whether anyone will pay to fix them. A devrel job post on its own might mean the problem is about to be solved by the hire. Stack them and you have described a company with money, a visible problem, and a public admission that the problem matters.

Notice what the third signal buys him: he never has to sell the problem. A company advertising for a developer educator has already made that argument internally, won it, and got budget approved. He is not introducing an idea. He is offering a faster route to a decision they have already taken, which is a much shorter conversation.

Notice also that the intersection is small. That is the point, and it is why the volume is ten a week rather than five hundred. He is not sending few emails because sending more would be wrong in principle; he is sending few because that is how many companies pass the filter in a given week. A signal that leaves thousands of companies standing was not a filter, it was a description.

4. Chemistry: do the work before you ask

Bansal splits the problem into timing and chemistry, and calls chemistry the question of whether your email and offer are any good. His version has two halves.

First, an audit. He runs a personalized review of the target's docs before writing, and Manicule built a tool to automate that part. Second, the human read: he goes through the buyer's Twitter and LinkedIn looking for one specific thing he can use, sometimes business-y, like an opinion they have argued for in public, and sometimes not, like being a tennis fan.

Then the email, which is four lines:

hey xyz,

i was going through your docs and found 3 errors:
- error #1
- error #2
- error #3

we do docs for ABC, can send an audit if you're interested

There is no craft in the writing and that is deliberate. The credibility comes from three named errors that could only appear in an email to one company. Nothing in it is a claim about Manicule; the only assertion is "we do docs for ABC", and by then he has already demonstrated the thing rather than described it. The ask is small and reversible: an audit, not a meeting.

This is why the problem with cold email is almost never the writing. Given three real errors, most people can write those four lines. The expensive part happened before the first keystroke.

5. The volume follows from the filter

Run the arithmetic on his numbers and it stops sounding like a small-time operation. Twelve emails, six or seven replies, some number of meetings, and eight in ten of those becoming pilots. At devrel retainer prices that is a month that matters, produced by a day or two of research a week.

The 80% meeting-to-pilot rate is the tell. Qualification usually happens on the call, which is why most first meetings go nowhere: you are finding out on the call that they have no budget, or no problem, or no mandate. He has checked all three before sending, so the call is about scope rather than fit. He gets a short funnel because he put the filter at the top of it.

Building your own version of the stack

Do not copy his three signals unless you also sell docs to devtool companies. Copy the three questions they answer, and find your own evidence for each.

• What proves they have money right now? A round, a hiring spree, a new office, a paid tool visible in their stack, a contract award.
• What proves the problem is present, from outside? This is the hard one, because it needs a public artifact you can inspect: docs, a changelog that stopped a year ago, a support forum with the same question asked eleven times, a pricing page that contradicts itself, an empty status page.
• What proves they already know? A job posting, a public roadmap item, a founder asking for tool recommendations, a conference talk about the thing.

If your product fixes something genuinely invisible from the outside, the middle question is where you will get stuck, and the honest answer is to find a proxy artifact rather than to skip it. Without something you can point at, you are back to asserting that they have a problem, which is the job Bansal spent his whole process avoiding.

His closing note is the least glamorous and probably the truest: you just need to be gritty and keep doing it, even when it is boring. The boring part is not the writing. It is the hours of reading that turn a list of companies into three that are worth an email this week, and it is the step people quit first, precisely because it does not scale.

That is the part OctoLoops was built to carry. Give it your product and it works out who your ICP actually is, then keeps watching for the moment a company in it becomes worth contacting: the round, the job post, the launch, the obligation they have no tooling for. Every account arrives with the event that qualified it and a link to the source, so you can disagree in five seconds, plus a draft you send from your own inbox. Whether you write ten a week or a hundred is entirely your call. Finding the ten that deserve it is the work we do while you build.