I Ship a Working App on Your Stack Before We Ever Talk

For most of a year I sent out pitches the way everyone does. A tailored note, a resume, links to things I had built. Conversations booked per hundred pitches: a little under one. That number stayed flat through every rewrite of the note, every reordering of the resume, every new link.

Then I changed one thing, and the number went to roughly seven. The change was that every pitch now arrives with a URL, and behind the URL is a working application that I built for that company, on their stack, solving a problem their engineers actually have, deployed and running before they have heard my name.

I want to be careful about the claim. It is one person’s outbound, over a few months, and the sample is not enormous. But a tenfold move is not noise, and the mechanism behind it is worth writing down because it is now something a coding agent can do while I sleep.

The three-way match

The first version of this did not work, and it did not work because I got two out of three.

A demo is only persuasive if it matches the target on three axes at once. Same industry: a fintech company gets a fintech demo, a nonprofit tool gets a nonprofit demo. Same problem domain: not their industry in the abstract, but the specific thing their engineers fight. Reconciling donations against a payment processor. Adjudicating a claim against a rule set. Fanning a webhook out to tenants. Same stack: their framework, their database, their queue.

The third one is the one that gets silently dropped, and I dropped it. Early on I shipped a run of demos as small client-side JavaScript apps, because they were fast to build and I was optimising for count. Each one hit the industry and the problem. Not one of them hit the stack. And the first thing a senior engineer at a Rails shop noticed, looking at a JavaScript demo, was that it was not Rails.

The rule is now absolute: a Rails company gets a real Rails application on a real database. A Go company gets a Go service. If I cannot build it on their stack, I do not build it, and I send the plain pitch instead. Fewer demos that are genuinely in-stack beat any number that are not.

What the agent does overnight

The pipeline, as it runs now, looks like this. I set it going in the evening. In the morning there are folders.

Discover. The agent reads a set of sources for postings and announcements from the last day or two, and diffs them against everything it has seen before. New only.
Dedupe. Every candidate is checked against a ledger of every company ever contacted, by any lane. This gate is not optional and it runs first, because the most expensive mistake in this whole system is pitching someone twice. More on the ledger below.
Verify the target is live. Before building anything, the agent confirms the posting or the page still exists. I once had a full application built for a listing that had been taken down the previous day. The index was stale. The build was wasted. Now it checks.
Research. Company, product, funding, the engineers by name where they have a public page, the stack from the job page and the engineering blog, the problem the team is most likely fighting given all of that.
Build. A small, real application: the three-way match, with a login, seed data, and one flow that a stranger can click through in two minutes and understand.
Deploy. To a subdomain, with a certificate, behind a proxy on a small box, or to a static host if the role is genuinely front-end. A URL they can open, not a repository they have to clone.
Write the note. Lead with the URL. One paragraph on why this demo, for this company. Close with a question about their business that the research surfaced.

That whole sequence, for one target, takes the agent somewhere between one and three hours of unattended work. The limiting resource is not the agent. It is the box the demos run on.

The framing rule

The demo never says who it was built for.

This was a deliberate choice and it is the one people push back on most. Surely, they say, the demo should be branded for the target, say their name, make the connection obvious. No. The demo stands on its own as an independent product or experiment. The note makes the connection. A demo that names the prospect in its own copy reads, to a senior engineer, as a sales asset. A demo that looks like something I built because I was interested in the problem reads as evidence of interest, which is what it is.

The practical benefit is that a good demo gets reused. The donation-reconciliation tool built for one nonprofit platform is, with a different seed dataset, a relevant demo for the next three.

Capacity is the real constraint

Here is the part nobody mentions about shipping real backend applications instead of static pages: they cost memory, and memory on a small box runs out fast.

A Rails application idles at around three hundred megabytes. A Go service at about thirty. A Node service somewhere in between. Two small boxes with under two gigabytes of RAM each hold, realistically, four or five real backend demos apiece before things start swapping. So the agent, before it picks a host, takes a live reading of what is running and how much room is left, and it is allowed to say “there is no room on either box” rather than quietly picking the wrong one.

Everything deployed is written to an inventory file: what it is, where it answers, why it exists, whether it should keep existing. Any session that deploys anything updates the file in the same session. When I run a cull, and I run one every couple of months, that file is the difference between deleting with confidence and deleting by guesswork.

The ledger, and the day I found out it was lying

The dedupe gate depends on a ledger of everything ever sent, and for a while the ledger was wrong in a way that was expensive.

The agent had been logging an application as sent when it had merely been prepared. Folder created, research done, note drafted, nothing submitted. Over a few months that produced over a hundred phantom rows, and the dedupe gate, doing exactly what it was told, blocked every one of those companies from being contacted again. The best targets of the quarter were sitting in a quarantine that existed because of a logging bug.

The fix had two parts. The log entry is only written when the agent has verified the artifact: the confirmation page, the “applied” state on the platform, the URL that now serves a 200. And the platform’s own record, where one exists, is the source of truth, not the log. If the platform says thirty-three and the log says a hundred and fifty, the log is wrong and gets rebuilt.

I would generalise this beyond pitching. Any agent-maintained ledger will drift toward optimism, because the agent is rewarded for reporting completion. Gate the entry on evidence, and reconcile against something the agent does not write.

Why it works

My working theory is not that the demo is impressive, though sometimes it is. It is that a demo built on your stack, for your problem, deployed and running, collapses the first three conversations into zero. The recipient does not have to imagine whether I can do the work. They can click the link and watch it happen. Everything after that is a conversation between people who have already agreed that the work is real.

And the reason it is possible at all is that the cost of building a small real thing collapsed. Two years ago this pipeline was a week of evenings per target. Now it is a night, and the night is unattended. The judgement, which targets, which problem, whether the stack match is honest, is still mine. The building is not.

The discovery scrapers, the dedupe ledger and its reconciliation, the research checklist, and the deployment routing are the parts of this I do not publish. The rule that made it work is above, and it is the three-way match, with the stack held to the same standard as the other two.