My first freelance proposal was 1,400 words long. It listed my skills, my education, the technologies I knew, and finished with a rate. I sent about forty of those and got two replies, both of them asking me to lower the price.
The proposal that eventually started working was around 150 words. It named the specific problem in their posting, described how I would approach it in three sentences, mentioned one similar thing I had built, and asked a question about their situation.
The difference was not writing quality. It was that the first version was about me and the second was about them.
The Reframe That Changes Everything
Clients are not buying your skills. They have a problem that is costing them money, time or sleep, and they are buying the removal of that problem.
"5+ years of Node.js and React experience" is a fact about me. "Your booking system is losing bookings when two people pick the same slot — I have fixed that exact race condition before" is about their Tuesday.
Everything below follows from that one shift. The technologies matter only as evidence that you can do the removing.
Where the Work Actually Came From
Being honest about proportions, because the advice online overweights the marketplaces.
Referrals — most of it, eventually. Every good client produced another within about a year. This is the whole game long term, and the only way to start it is to do the first few jobs unusually well.
Upwork, early on. Genuinely useful for the first few contracts, when you have nothing to point at. It is competitive and price-pressured, and I treated it as a way to buy testimonials rather than a career. I left once referrals covered the pipeline.
Writing publicly. Slower than everything else and the highest quality leads by a distance. Someone who has read three of your posts about a problem arrives already convinced. They do not negotiate the same way.
Being visibly useful in communities. Answering questions properly in Slack groups, on Reddit, in GitHub issues. Never pitching. Two of my better clients came from someone remembering a helpful answer months later.
Cold outreach — almost nothing. I tried it. Low response, and the responses were mostly price shoppers. Others do better at this than I did.
The Proposal Structure That Works
Short, specific, and it demonstrates rather than claims.
You mentioned the sync between your CRM and the scheduling
tool breaks "a few times a week" and someone re-enters the
data by hand.
That usually means the webhook is firing but the handler is
failing silently — no dead-letter queue, so failures vanish.
The fix is normally a day: retries with backoff, a failure
log you can actually see, and idempotency so a replay doesn't
duplicate records.
I built something similar for a care-scheduling platform —
same shape of problem, two systems, no visibility into what
failed.
One question: when it breaks, do you get any error at all,
or do you only notice when the data is wrong?
Why this works: it diagnoses before pitching, which proves competence more convincingly than a list ever could. It gives a real estimate, which is a risk and reads as confidence. And it ends with a question, so replying is easy and the conversation starts on technical ground rather than price.
Two things I stopped doing: attaching a CV, and listing my whole stack. Nobody read either.
Pricing, and the Mistake I Made for a Year
I charged hourly at first because it felt fair. It is not, and the reason is that it punishes you for being good. Getting faster at something reduces your income from it, which is a genuinely strange incentive to accept.
What I moved to:
Fixed price for defined scope. "Build the integration, with retries, monitoring and documentation — X, delivered in two weeks." The client knows the number, you keep the upside of working efficiently, and the conversation is about outcome rather than hours.
Monthly retainer for ongoing work. Predictable for both sides, and it is what turns freelancing from a series of anxious gaps into something like a business.
Hourly only for genuinely open-ended work — an unclear legacy bug, an audit — with a cap so nobody is nervous.
On rates: the biggest single increase in what I earned came from raising the number, not from working more. Cheap attracts clients who treat the work as a commodity and negotiate at every step. There is a real threshold above which clients stop haggling and start asking about your availability instead.
And always take a deposit — 30-50% upfront. Not because most clients are dishonest, but because the ones who refuse are reliably the ones who will be difficult about the final invoice.
The Clients to Turn Down
Learning to say no was worth more than any marketing. The signals, all of which I ignored at least once:
"This should be simple." Almost always said about the hardest thing in the project.
Vague scope with a fixed budget. One of those has to give and it will not be the budget.
Speaking badly about their last three developers. You are about to become the fourth.
Haggling before the work is defined. Price-first conversations stay price-first.
"There's more work if this goes well." Sometimes true. Usually a discount request in disguise.
Resistance to a written scope. The single strongest predictor of a bad engagement.
A bad client does not just cost you that project. It costs you the good client you were too busy and too demoralised to take on.
Keeping Them Is the Actual Business
Winning work is the part everyone writes about. Retention is where the money is, and it is mostly not about code.
Communicate more often than feels necessary. A two-line update every few days. Clients do not get anxious because things are going slowly; they get anxious because they cannot see what is happening.
Say when something will be late, early. Nobody minds a delay they were warned about. Everyone minds one they discover on the deadline.
Explain trade-offs in their terms. Not "we should refactor this" but "we can ship in three days with a shortcut that will cost us a week in six months, or five days done properly — your call." Clients who feel involved in decisions stay.
Leave things better than the brief required. A README that lets the next person start, sensible error messages, a note about what you would do next. It costs an hour and it is what people remember when someone asks them for a recommendation.
That last habit is where most of my referrals came from. Not the code — the handover.
