This one is mine, on this site, the day before it went live on its own domain. I'm posting it because the whole premise here is that the failures are worth more than the wins, and it would be strange to ask that of everyone else and never do it myself.
I'm not a developer. I built this site by directing an AI assistant, and by the time it went live everything 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 a second.
My first instinct was that something in the code was slow, and that instinct was completely wrong. The code was fine. What had happened is that the two halves of the site had ended up on different continents. The database — where all the posts and accounts live — sits in Ireland, because that's where I put it. The servers running the site had been placed in Washington by default, because that's what the hosting platform does when you don't say otherwise. Nobody chose that. It was just the default, and I didn't know there was a choice to make.
So every single page was crossing the Atlantic and back, several times over, because a page asks the database several separate questions before it can be drawn. The fix was a three-line configuration file naming Dublin instead. Same code, same database, nothing rewritten. Pages went from 1.76 seconds to about a quarter of a second.
The reason I think this is worth posting: no amount of asking an AI to 'make this page faster' would have found it, because nothing in the code was slow. And nothing ever showed up as an error. It looked like it was working, and it was working — just badly, in a way that only shows up if you actually measure.
My uncle manages sales performance at a pharmaceutical company. He regularly needs to see how each of his reps is doing against budget, then present that in person, often while traveling — using data that comes out of the company's existing sales system as an export file.
I'm not a developer. My background is marketing and communications. When he asked for something to help with this, the obvious answers were generic BI software or hiring someone to build a tool. Instead I used Claude Code, an AI coding assistant, and directed it in plain language to build a small custom web app myself.
The requirements weren't things I guessed at — they came out of an actual conversation with my uncle. The data is sensitive pharma sales figures, so the app had to run entirely locally in the browser: no server, no upload, works offline. The input is whatever Excel or CSV file he already exports, dragged into the app — not a live connection to the system, on purpose, so nothing sensitive ever leaves his laptop. The output had to be both a dashboard he could explore and a one-click PDF export formatted as slides, because he needed something to put up in a room, not just a screen to scroll through alone.
Below is roughly how I approached it with Claude Code, the actual instruction I'd give if I were starting over, and an honest read on where this stands right now — including the part that isn't tested yet.
I do freelance web design and small-agency work on the side — video, social, copy, strategy — and after enough of these pitches I landed on a simple thesis: the easiest lead to convert isn't a business with a site that might want a redesign. It's a business with no site at all, or one that's broken, or one that's clearly been abandoned. Which means the whole pitch lives or dies on how specifically you name the gap.
I built a small tool to find these businesses: it pulls local businesses by category and town from OpenStreetMap's free public map data, then actively checks whether each one has a real working website instead of trusting whatever OpenStreetMap has on file. That catches both directions of error — a business OpenStreetMap doesn't know has a site, and a domain that's registered but dead. It scores each business 0-100 on how convertible the gap looks, labels it HOT/WARM/COLD, and generates a short dossier plus a draft email for each one.
But the piece of this worth sharing on its own, whether or not you ever build the scanning part, is the writing step. Once you have three plain facts about a business — its category, its town, and what the check actually found about its website — the job is turning that into a first paragraph that reads like you looked at that specific business, not a template with the name swapped in. That's what the prompt below does. The prompt doesn't care where those three facts came from — you can type them in by hand.
The steps below are how I use it, and the prompt itself is the reusable part.
I'm early in my career, in marketing and communications, and every interview circles 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. What isn't sitting there ready is an answer built out of my actual history, delivered in a voice that sounds rehearsed a few times over rather than read off a script.
So before a round of interviews I sat down once and wrote a single long document about myself: my education, each past role described as what actually happened rather than as a pile of adjectives, the specific skills and tools I use, a section on how I want to sound in an interview (professional, natural, concrete — explicitly not stiff or over-rehearsed), and a section naming where I'm genuinely weaker. I wrote that section as plainly and specifically as I could. A vague weakness gets a vague answer back — the more real the constraint, the more the AI actually has to work with instead of writing generic confidence around me.
Then, before each interview, I paste that document into Claude or ChatGPT along with the actual job posting and give one explicit instruction: play a demanding recruiter for this specific role, ask realistic questions including the hard and skeptical ones, and when critiquing my answers, push back on anything generic or anything the document doesn't actually support. I ask it to be hard to please, not encouraging.
What comes out is tailored answers to the standard set, anchored in real facts instead of a generic template, plus a live simulation I can run out loud before I'm ever in front of an actual recruiter. The steps I follow and the exact instruction I paste in are below, along with the three places this still isn't enough on its own.
In a few weeks I start as a BDR doing outbound for a B2B software company that sells to businesses running multiple physical locations — think a chain of gyms, clinics, restaurants, or retail stores. I've spent the run-up building the process I'll use on day one and testing it on the outreach I already do for my own freelance work. My starting point is a list of company names. Nobody hands me anything else. I can't scrape LinkedIn — that's against the rules I'll be working under. So everything I know about a prospect before I write to them has to come from what that company has already made public.
The hard part isn't writing an email. It's writing an opening line that proves I actually looked at the company. Not the kind of line that could be pasted into any cold email to anyone — "I noticed you're doing great work in your space" — anyone who's gotten cold emails before spots that instantly as filler.
What changed my process is narrowing what I ask Claude to do. I don't ask it to write me an email. I ask it to find one specific, checkable fact about how a company operates across its locations — something that's only true because they're running several sites, not one — and build two sentences around that fact. Then before anything goes out, I check that fact myself. That last step is not optional. It's the entire difference between a personalized email and a personalized-sounding guess.
Below are the steps I actually follow, the exact instruction block I paste into Claude (with a made-up example company so the technique is visible without exposing a real prospect), and where this breaks down in practice.
I have a habit that predates this site, and it's actually the reason the site exists. When I read a business or nonfiction book, I don't want it to fade into "yeah, good book, can't remember much." I turn it into a skill for Claude — a small file of instructions the assistant loads automatically when the topic comes up, so I can go back and consult the book's actual decision-making process the way you'd call an expert, instead of trying to remember what they once told you.
This is not the same as asking AI to condense a book into bullet points. A summary tells you what the book says, and it's nearly useless six months later because you don't remember which bullet applies to the situation in front of you. What I extract instead is what decision procedure the book teaches — the steps someone actually following that method would take facing a real situation, plus the judgment calls and trade-offs the book flags along the way. The test is whether you could hand it to a new hire who never read the book and have them apply it.
When I went looking for other people doing this kind of thing with their own workflows — not "here's a cool prompt" but "here's exactly what I did and here's where it fell apart" — I found nothing worth reading. General AI forums bury this kind of post under news and memes. Prompt catalogs don't tell you what didn't work. And the communities built around this are paid, sitting behind a subscription wall. So I built this one.
Below is the actual five-step process, and the file I feed to Claude at the step where the real extraction happens.