30-second summary

You have a productized implementation guide. The bottleneck is not the product. It is the email you have not sent yet. This post gives you the subject line, the exact body copy, the one follow-up, and what to say when a client responds with "I'd rather just pay your hourly rate."

Your blueprint exists. Your clients do not know.

"I keep thinking about sending it but I don't want to seem like I'm pitching them." That is the most common thing developers say when they've finished their first $297 implementation guide. The guide is real. The work it documents is real. But it is sitting in a folder somewhere, and five clients who would gladly buy it have never been told it exists.

The gap is not the product. It is the email.

Hourly client relationships feel different from cold outreach because they are. These people already trust you. They have paid you. They know what you build. The irony is that makes the email easier to write, not harder. You are not pitching a stranger on something hypothetical. You are telling someone who has already hired you that you packaged the work into a format they can keep.

Here is what happens when you do not send it: your best clients keep paying hourly for work that takes you two hours because you have done it twelve times. Your blueprint stays in a folder. And you wonder why productization is not working.

Why "just letting you know" does not convert

Most developers who do attempt an upgrade email write something like this:

Subject: Quick update Hey [Name], Hope you're doing well. Just wanted to let you know I've put together a guide on the Stripe integration we worked on. Figured it might be useful. Happy to answer any questions if you're interested. [Name]

This email fails for four reasons.

First, "Quick update" is a subject line for a project status, not a product. It gets opened, then closed.

Second, "might be useful" is not a pitch. It is an apology for pitching. The reader has no idea whether this is a $20 thing or a $2,000 thing, which means they default to ignoring it.

Third, "Happy to answer any questions" is not a call to action. It puts the work on them and gives them nowhere to land.

Fourth, there is no price. No price means no decision. "Interested" is not a decision. "Yes, I'll buy it at $297" is a decision.

The 4 parts of an upgrade email that lands

A good upgrade email to an existing client has four components, in this order:

  1. A subject line that names the specific work. Not "new product" or "quick update." The name of the project you built together. "The Stripe setup we built for the checkout flow" is better than "New implementation guide available."
  2. Two sentences on what the guide includes. Not a feature list. Two sentences that tell the reader what problem the guide solves and what format it is in. "It walks through the same configuration we set up for you, with the exact API calls, error handling patterns, and the three edge cases we hit in your environment. It's a PDF with annotated code blocks." That is enough.
  3. One clear price. $297. Not "starting from $297" or "typically around $200-400 depending on scope." One number. Ambiguity is where buying decisions go to die.
  4. An easy out. "No pressure if the timing is off" is not weakness. It removes the friction that makes people defer. When a client knows they can say "maybe later" without it becoming awkward, they are more likely to respond at all instead of ghosting.
If you have not yet written your first $297 blueprint, the 3-Product Ladder post covers what goes into a Tier 2 guide and how to scope it from work you have already done.

The script: copy and adapt

Here are three subject line options ranked by specificity. The more specific, the better the open rate with existing clients.

Subject line When to use
"A packaged version of the [project name] setup" You worked on a named project together. Use the project name, not a description.
"The [technology] implementation we built — now a guide" The technology is more memorable than the project name. Common with Stripe, Supabase, n8n.
"Quick note on the [month] engagement" The engagement was short and there is no memorable project name. Reference the timeframe instead.

And here is the body:

Subject: A packaged version of the [project name] setup Hey [Name], I packaged the [specific implementation] we built for you into a $297 guide. It covers the same configuration, the error handling we added in week 2, and the three edge cases that tripped us up. Formatted as a PDF with annotated code so you can hand it to whoever maintains that system. You can get it here: [direct link or "reply and I'll send it over"] No pressure if the timing is off. Happy to answer questions either way. [Your name]

That is 83 words. Keep it under 100. The temptation to explain more is the thing that kills conversion rates. If they have questions, they will ask.

A few notes on specific lines:

One follow-up, then stop

Send one follow-up 5-7 business days after the first email. Not 24 hours later. Not two weeks. Five to seven business days.

The follow-up is short:

Subject: Re: A packaged version of the [project name] setup Hey [Name], Just following up on this in case it got buried. No worries if it's not the right time. [Your name]

That is it. Eleven words of body copy. No re-pitch, no added features, no "I wanted to make sure you saw this." The re-pitch tells the reader you are nervous, which makes them hesitant. The short follow-up respects their time and assumes they are busy, not disinterested.

After the follow-up, stop. If they did not reply to two emails about something you built specifically for their environment, the timing is wrong or the fit is wrong. Both are fine. Move to the next client on your list.

When they say "I'd rather just pay your hourly rate"

This happens with roughly 20-30% of clients who engage with the upgrade email. It means one of two things: they value your presence more than the documentation, or they have implementation questions the guide does not answer.

The response that works:

Totally makes sense. Let me offer a middle option: the guide plus a 90-minute implementation session, $450 flat. You get the documentation to keep and a session to walk through the parts that don't translate cleanly to your stack. If that works, I'll send a link. If hourly makes more sense for this one, happy to do that too. [Your name]

The middle option converts about half the "I'd rather pay hourly" responses. It satisfies both things they want: the documentation and your direct involvement. And it does it at a price that is better for you than two hours of hourly work with no documentation artifact at the end.

The clients who decline the middle option and want straight hourly are telling you something about how they think about their relationship with you. That is fine. Not every hourly client needs to become a blueprint buyer. The goal is to give them the option, not to convert them all.

What to do when they buy

Send the guide within 24 hours. Not after you finish polishing section 4. Within 24 hours of payment.

Include a short note: "Here is the guide. Let me know if the [specific part] section is clear or if you want me to expand that one." This keeps the relationship warm and surfaces genuine gaps in the documentation. The gaps are your next revision. The revision is why V2 of the guide costs $497.

Log the sale. The first blueprint sale to an existing client is a data point worth tracking. It tells you the email works, which client profile buys from this angle, and whether the $297 price held or needed negotiation. Three to five data points and you know enough to systematize the outreach.

Look at your client list. Pick the one who would benefit most from the guide you just wrote. Send the email today, not next week. The awkward conversation you are avoiding is not awkward. It is a service.

Next: The "Common Failures" section is the part of a blueprint buyers are actually paying for. Here's how to write it so it holds up in production.