DEV Community

Hemanshu Upadhyay
Hemanshu Upadhyay

Posted on • Originally published at x.com

I have built the same pipeline five times. The fifth took 68 minutes.

On 11 June I wrote a program to find contract manufacturers for a supplements brand launching in India. The folder was created at 11:35 in the morning. There was a finished, scored report sitting in it at 13:55. Two hours and twenty minutes, most of which was me arguing with the scoring weights.

Three days later I wanted marketing agencies instead of factories, so I copied the shape and repointed it. 13:47 to 15:56.

On 23 June I wanted packaging and branding studios. That folder did not exist at 10:48 and there was a scored report in it at 11:56. Sixty-eight minutes.

Then one for remote jobs priced in dollars, nineteen commits between 14:19 and 15:15 on a Sunday. Then, on 14 August, one that finds companies who might buy from my own studio.

Underneath, they are the same program. Read a brief. Search. Open the actual pages rather than trusting the search snippet. Score each candidate against the brief. Write out the reasoning for every score. Flag the rows that look thin.

I get asked, in a slightly suspicious tone, why I automate so much of my own work. The assumption inside the question is that this is about speed, and that speed is a shallow thing to want.

Speed is real, and it is the least interesting part.

The machine keeps a file. I don't.

Last week I ran a verification pass over the fifth pipeline, the one that finds my own prospects. It went back through what it had already qualified and opened each company properly.

It disagreed with itself. Of the 58 companies it got through, it disqualified 21. Thirty-six percent.

I published that number, and a few people read it as an argument against building the thing in the first place.

Compare it to the handmade version. Earlier in August I wrote six outreach messages by hand. One company at a time, real research, a specific observation about each business, hours of work across a week. Every one of the six was delivered and read. Zero replied.

Now tell me my error rate on those six.

There isn't one. There is no file. There is no column where a past version of me wrote down what he believed about each company and why, so there is nothing to check the outcome against. All I have is a memory of feeling careful, and feeling careful is not evidence of anything.

That is the whole bias in one line. I would rather run a process that is measurably wrong 36% of the time than one that is unmeasurably wrong by an amount nobody will ever know.

A measured error is a Tuesday afternoon of work. The scoring model was reading "no marketing person listed on the team page" as "no marketing person exists," which is a different claim, and once it is written in a file you can see it and fix it. An unmeasured error is not a bug. It becomes a personality. It sits there for years being called judgement.

Human work does not produce receipts unless you force it to, and almost nobody forces it to. Automating a task is the cheapest way I have found to make my own reasoning legible enough to be proven wrong.

What 68 minutes does to which ideas you try

The second half of the bias is more boring and probably matters more.

The first pipeline cost two hours and twenty minutes. The third cost 68. That collapse changes which ideas are allowed to exist.

When a small system costs a week of evenings, you only build the ones you are already confident about, which means you only ever build things you already believed. When it costs an hour, you build the stupid one. In June I built a thing at one in the morning that takes a photo of a dress and finds similar ones across Indian stores, because my girlfriend asked and it was thirty-four minutes of work. It is running. It is genuinely useful. It would never have survived a business case.

Roughly a third of the ones I built on a whim turned out better than the ones I picked carefully, and I do not think that is luck. Careful selection filters for ideas that are easy to justify in advance, and the value in this stuff is rarely where the justification is.

Where the bias is wrong

I want to be honest about the failure, because the version of this argument without it is marketing.

I sent from the wrong stage. I looked at discovery output that had not been enriched or verified, decided the rows looked right, and sent ten emails. Two hard bounced on a sending domain that was nine days old. You do not get to undo that. The system was not wrong there. I was impatient with a system that was still working, which is a specific failure mode automation creates rather than solves.

And a second thing, which is the real boundary. Two of fourteen prospects died at a layer no pipeline can see: one founder wearing an OpenToWork banner, one correct decision maker with five connections and no posts, ever. Neither is discoverable from company data. No amount of pipeline reaches it.

So the rule I hold now: automate the collection, never the conclusion.

Every one of these five stops before the send. The step that has caught more real problems per minute than anything upstream is me opening one human being's profile and reading it for thirty seconds. That step gets more expensive as everything around it gets cheaper, and it should, because it was always the actual job.

The unglamorous version

I am not biased toward automation because it is impressive. Most of what I have built is a few hundred lines that reads pages and writes a CSV with a reasons column.

I am biased because it turns my opinions into artifacts. An opinion in your head cannot be audited, cannot be handed to someone else, and cannot be wrong out loud. The same opinion written as a scoring function can be all three by lunchtime.

Thirty-six percent wrong and improving beats an unknown number and a good feeling. That is it. That is the whole argument.

Top comments (0)