The site worked. Pages loaded, accounts worked, nothing errored. It just felt heavy — so I timed it. 1.76 seconds for a page that should take a quarter of that.
My first instinct was that something in the code was slow. That instinct was completely wrong.
The two halves of the site had ended up on different continents. The database, where the posts and accounts live, sits in Ireland, because that is where I put it. The servers running the site had been placed in Washington — by default, because that is what the hosting platform does when you do not say otherwise. Nobody chose that. I did not know there was a choice to make.
So every page was crossing the Atlantic and back, several times over, because drawing one page means asking the database several separate questions.
The fix was a three-line configuration file naming Dublin. Same code, same database, nothing rewritten. 1.76 seconds became about a quarter of a second.
This is the part worth keeping: no amount of asking an AI to "make this page faster" would have found it, because nothing in the code was slow. Nothing ever appeared as an error. It looked like it was working — and it was, just badly, in a way that only shows up if you measure it.
My uncle manages sales reps at a pharmaceutical company. He needs to see how each one is doing against budget, and then present that in a room, often while travelling.
I am not a developer — my background is marketing. The obvious answers were generic BI software, or paying somebody to build a tool. Instead I directed Claude Code in plain language and built a small web app myself.
The requirements came out of an actual conversation with him, not from me guessing. The figures are sensitive, so the app runs entirely in the browser: no server, no upload, works offline. He drags in the Excel export he already produces — deliberately not a live connection to the system, so nothing sensitive leaves his laptop.
And the output is not only a dashboard. One click turns it into a PDF laid out as slides, because he needed something to put up in front of people, not a screen to scroll through alone.
The easiest lead is not a business with a site that might want a redesign. It is a business with no site at all — or one that is broken, or one that has clearly been abandoned. Which means the whole pitch lives or dies on how specifically you name the gap.
The reusable part is the writing step, and it works whether or not you ever automate the finding.
You need three plain facts: the category, the town, and what actually happened when you checked for a website. From those, the job is to write a first paragraph that reads like you looked at that one business — not a template with the name swapped in.
You can type those three facts in by hand. I built a scanner that pulls them from OpenStreetMap and then checks each site for real instead of trusting what is on file — that catches both a business with an unlisted site and a domain that is registered but dead — but the prompt does not care where the facts came from.
Every interview comes back to the same four questions. Tell me about yourself. Why this role. What are your weaknesses. Where do you see yourself in five years.
A generic answer to those is always sitting right there, ready to say — and it always sounds exactly like what it is.
So I wrote one document about myself, once. My education, each past role described as what actually happened rather than a pile of adjectives, the tools I really use, how I want to sound in the room, and a section naming where I am genuinely weaker.
That last section is the one that does the work. A vague weakness gets a vague answer back. The more real the constraint, the more the assistant has to work with, instead of writing generic confidence around me.
Before each interview I paste that document in along with the actual job posting, and give one instruction: play a demanding recruiter for this specific role, ask the sceptical questions too, and push back on anything generic or anything the document does not support. Hard to please, not encouraging.
An opening line that could be pasted into any cold email to anyone is worse than no opening line at all. "I noticed you're doing great work in your space" — anyone who has ever received a cold email spots that in half a second.
What fixed it was narrowing what I ask for. I do not ask Claude to write an email. I ask it to find one specific, checkable fact about how a company operates across its locations — something that is only true because they run several sites and not one — and to build two sentences around that fact.
Then I verify the fact myself before anything goes out. That step is not optional. It is the entire difference between a personalised email and a personalised-sounding guess.
The constraint that shaped all of this: I start from a list of company names and nothing else. No scraping LinkedIn — that is off limits where I work. Everything has to come from what the company already made public.
A summary tells you what a book says. Six months later it is useless, because you cannot remember which bullet applies to the situation actually in front of you.
So I stopped making summaries. I extract the decision procedure instead — the steps someone following that method would really take, plus the judgment calls the book flags along the way — and save it as a skill file the assistant loads whenever the topic comes up. Then I consult it the way you would call someone who knows, instead of trying to remember what they once told you.
The test I use is simple. Could you hand this to a new hire who never read the book, and would they be able to apply it? If not, I extracted the wrong thing and I go back.