· consulting · proposals · claude-code · solo-consultants · skills
Stop writing the same proposal six times a year
Most solo consultants rewrite the same proposal six times a year and let the quality drift on every pass. Here's the failure mode, and the fix.
You write six proposals a year. Maybe eight. They all start as a copy of the last one. By April, the version on your laptop is three jobs removed from the one that actually won, and you can’t quite remember what you took out and why. The day rate quoted is from last spring. The discovery questions are generic enough to fit any prospect. The risk section, if it survived at all, has been quietly trimmed because the last reader said it sounded “negative”.
This is the slow-burn cost of proposal copy-paste, and it does not show up in any metric you track. It shows up in win rate, eventually. It shows up earlier in the time you spend on each one: every proposal takes longer than it should because you are half-rebuilding the structure each time you sit down.
This post is about the failure mode in detail, and the fix that works: a templated proposal-writer skill that gets a defensible, prospect-specific proposal out of your head in under thirty minutes. Not because the skill writes the proposal for you. Because it stops you re-deciding the structure on every pass.
The six-proposals-a-year failure mode
Run the tape on a typical solo consulting year. You write a proposal in January for a fractional engagement. It wins. You duplicate the file in March for a different prospect. You change the names, swap the scope, tweak the price. The thing you don’t change, because you don’t have time, is the structure. The discovery framing that fit the January client is now generic. The risk you named in January (specific, named, mitigated) gets watered down because this prospect is in a different sector and you don’t know their landscape well enough yet to name a real one. So the risk section becomes “delivery will require close collaboration”, which is not a risk; it’s filler.
By the third pass, you’ve copied the file from the second one, not the first. The qualifications paragraph still reads fine, but it’s been shortened twice and now no longer matches what’s actually on your CV this quarter. The pricing section quotes a day rate that you’d revise upward today if you stopped to think about it.
By proposal six, you are working from a document whose lineage you don’t fully remember. Some of the words are yours; some of them are an artefact of a prospect from eighteen months ago. The proposal is still readable. It is no longer sharp.
That drift is the real cost. It costs you on win rate, but it also costs you reusability. The next time you sit down to write one, you can’t trust the latest version as a starting point, so you rebuild from scratch and lose two hours.
Why discovery questions are the first thing to rot
The fastest-decaying section of any reused proposal is the bit that mirrors the prospect’s own language back at them. A good proposal opens with the prospect’s stated problem, in their words, before it gets anywhere near the seller’s credentials. That section can only be written after a discovery call that produced specific phrasing.
What happens with copy-paste is the previous prospect’s phrasing stays in. You delete the company name. You delete the most obviously specific lines. What’s left is sanitised, generic, and reads as if it could have been written before the discovery call happened. The prospect notices this in a way they cannot quite articulate. The proposal feels less like a response and more like a template.
The fix is not to write better generic openings. The fix is to refuse to start drafting until you have specific phrasing in front of you. That refusal is hard to enforce on yourself when you’re tired on a Sunday evening with a Tuesday deadline. It is much easier to enforce on a skill that won’t draft until you’ve answered seven questions properly.
What we changed
The proposal-writer skill in the Solo Consultant Ops pack does one thing: it interviews you about a prospect, refuses to proceed on vague answers, and produces a tight 3–5 page proposal in markdown when every input slot is filled with a specific answer.
Seven inputs, asked in one grouped round-trip, not five separate prompts:
- Prospect name and company
- The problem in their words (quoted from the discovery call where possible)
- Engagement type (fractional role, fixed-scope project, retainer, audit)
- Duration and effort
- Budget signal (a number, a range, or a comparable they referenced)
- Decision-makers and timeline
- The one or two facts that uniquely qualify you for this specific engagement
If you write “they need help with strategy” in slot 2, the skill rejects it and asks what they actually said was broken. If slot 5 is “they have budget”, it pushes back. The interview is the work. The drafting is the easy bit once the interview is honest.
The output structure is opinionated. Problem stated before credentials. One single number rather than a range. One named risk with a mitigation, not three vague ones. A dated next-step CTA. Three to five pages rendered, not twelve. These structural choices were tuned over two years of writing proposals manually and seeing which patterns shortened the time-to-signed-SoW and which lengthened it.
What it doesn’t do
The skill scaffolds; it doesn’t replace your judgement. It will not invent a qualification you didn’t supply. It will not invent a deliverable. It will not pad the methodology section to make the proposal look weightier. If you give it weak inputs, you’ll get a weak proposal back, faster than before; that is not the same as a strong proposal.
It also will not save you from sending a proposal you should not have sent. Some discovery calls produce enough specific signal to draft a proposal. Plenty don’t. The skill makes the first kind faster. It does nothing about the second, except that the input interview surfaces the gaps earlier, before you’ve spent ninety minutes drafting against thin air.
The other thing worth saying out loud: a proposal is not a contract. The proposal sets up the engagement and the price; the SoW is what protects you when the work starts to drift. Solo consultants under-protect themselves in their SoWs more often than they under-write their proposals. We touch the same problem from a different angle in how a fractional COO uses Claude Code on Sunday afternoons, which walks the actual cadence of a multi-client week, including where the SoW step lands.
What thirty minutes looks like
Discovery call ends Tuesday morning. You take five minutes to write down the prospect’s literal phrasing while it’s fresh: the problem, the budget tell, the comparable they referenced, the timeline pressure, the alternative they’re weighing. That note is the source material.
Tuesday evening you open Claude Code, run the skill, and answer the interview from your notes. Twelve to fifteen minutes if your notes are good; longer if they aren’t, which is information in itself. The skill drafts. You read every word. You edit two paragraphs that don’t sound like you, swap a claim for a stronger one, and send it within thirty minutes of opening the file.
The first proposal of the year takes longer because you’re calibrating the skill’s tone to yours. By proposal three, the cadence is automatic. By proposal six, you have not rewritten the same scaffold six times. You have written six different proposals, each tuned to its prospect, each starting from a structure that did not drift across the year.
For a wider view of which Claude Code skills are worth writing for solo consulting work and which aren’t, see the real list. The proposal one is the highest-value of the four; the others compound.
What this looks like with Solo Consultant Ops
proposal-writer ships in the Solo Consultant Ops pack alongside sow-templater, follow-up-sequencer, and invoice-chaser. Lifetime licence at £99, no subscription, fourteen-day refund. The pack pays for itself the first proposal you don’t have to write from scratch on a Sunday.