I thought getting clients was the hardest part of freelancing. I’m starting to think it’s what happens after.
When I started working on my freelancing playbook, I assumed the biggest problem developers had was getting clients.
That was the obvious problem.
But after talking to freelancers and reading through the feedback on my first post, I'm starting to see a bigger picture.
Getting the client is only one part of the system.
You still have to:
- protect yourself from scope creep
- communicate clearly
- handle pricing objections
- manage expectations
- send professional invoices
- know when to say no
- deliver on time
- follow up after the project
- turn a good project into another opportunity
One comment that really stuck with me was:
“Positioning gets you the first job. The boring operational stuff is what gets you asked back.”
That made me rethink how I'm structuring the blueprint.
Maybe the goal shouldn't simply be:
“How do I get my first client?”
It should be:
“How do I build a freelance system that works from finding the client all the way to getting the next project?”
I'm curious what other freelancers think.
What's the part AFTER landing the client that you wish someone had taught you earlier?
That's the kind of feedback I'm trying to build into the blueprint.
Tomi, I would give “agree what finished means” its own worked example. A change-order template is much easier to use when both sides can point to the original boundary.
For a fictional website project, compare “booking functionality included” with: “Embed the client’s existing booking tool on one page. Client supplies the account and availability rules. Custom booking software, payments and CRM sync are excluded unless separately agreed.”
Then make the handover equally concrete: what gets delivered, who supplies the final content, who approves it, how many review rounds are included and what support follows launch.
A useful exercise for the playbook would be to give readers one vague enquiry, ask them to highlight every assumption they would otherwise price, then write the clarification email before the proposal. That connects discovery, pricing and delivery in one exercise.
I’m building ScopeClarify around the pre-quote part of this, so that is my commercial angle. Would a worked enquiry-to-clarification exercise fit your blueprint? I can contribute an example here for you to assess.