What You’ll Learn

  • How I scope freelance projects to avoid surprises
  • My pricing approach and when I use fixed vs hourly
  • How I structure the build phase to ship fast
  • What a clean client handoff looks like
  • The process habits that keep projects from going sideways

I have delivered enough freelance projects to know that the technical work is rarely the hard part. The hard part is everything around it: scoping accurately, communicating clearly, setting expectations, and delivering something the client can actually use after I leave.

This is the workflow I have converged on. It is not the only way to do freelance work, but it is the process that consistently gets me from first message to final deploy without drama.

Phase 1: Discovery

Every project starts with a conversation. The goal is not to impress the client with technical knowledge. The goal is to understand what they actually need.

My standard discovery questions:

  • What problem are you trying to solve?
  • What does the current workflow look like?
  • Who will use this, and how often?
  • What systems does this need to connect to?
  • Do you have an existing codebase, or is this greenfield?
  • What is the timeline?
  • What does “done” look like?

The last question is the most important. If the client cannot describe what “done” looks like, the project scope will drift. I help them define it before agreeing to anything.

I take notes during this call and send a written summary within 24 hours. That summary becomes the basis for the proposal.

Phase 2: Proposal and Pricing

My proposals are short. One page, three sections:

What I will build

A clear list of deliverables. Not features, deliverables. “A Next.js dashboard with three views: overview, detail, and settings” is a deliverable. “An intuitive and powerful analytics platform” is not.

What is not included

This matters more than people think. If the client expects mobile responsive design, real-time sync, or admin user management and I have not scoped it, that is a problem waiting to happen. I list exclusions explicitly.

Timeline and price

For projects under two weeks, I use fixed pricing. The client knows the total cost upfront, and I know the scope is contained enough that I can estimate accurately.

For longer or less defined projects, I use weekly billing. The client pays per week of work, and we review scope and progress weekly. This protects both sides when requirements evolve.

I never price by the hour for fixed-scope work. Hourly pricing punishes efficiency. If I can deliver a feature in two hours instead of eight because I have done it before, the client should not pay less for that experience.

Phase 3: Build

Once the proposal is accepted, I start building. My default process:

Day 1: Skeleton

Set up the repo, deploy pipeline, and one complete vertical slice. By the end of day one, the client should be able to see something live — even if it is just a styled landing page with one working feature.

This does two things: it proves the infrastructure works, and it gives the client confidence that the project is moving.

Daily updates

I send a short daily update. Three lines:

  • What I shipped today
  • What I am working on tomorrow
  • Any blockers or questions

This takes me two minutes and saves hours of “just checking in” messages. Clients who feel informed do not micromanage.

Weekly demos

For projects longer than a week, I do a short demo at the end of each week. Screen share, walk through what is working, ask for feedback. This catches misalignment early before it becomes expensive.

Git discipline

Every feature gets its own commit with a clear message. The main branch is always deployable. I use preview deployments so the client can test changes before they go live.

Phase 4: Testing and Polish

Before I call a project done, I run through a checklist:

  • Does the core workflow work end to end?
  • Do error states show useful messages?
  • Does it work on the browsers and devices the client cares about?
  • Are environment variables documented?
  • Is the deploy pipeline green?
  • Can someone who is not me understand how to make changes?

That last point is critical for handoff. If the project requires me to maintain it, it is not really done. The client should be able to hand it to another developer and have them understand the codebase within an hour.

Phase 5: Handoff

My standard handoff package:

Code

A clean repo with a README that covers:

  • How to set up the dev environment
  • How to run locally
  • How to deploy
  • Where environment variables are configured
  • Architecture overview in two to three paragraphs

Access

I transfer ownership of all accounts and services. The client should own the Vercel project, the database, the domain, and any third-party API keys. I remove my own access after confirming they can deploy independently.

Walkthrough

A 15 to 30 minute call where I walk through the codebase, explain the key decisions, and answer questions. I record this call and send them the recording.

Support window

I include a one-week support window after handoff. If something breaks or they have questions about deployment, I fix it at no extra charge. This builds trust and usually results in referrals.

Process Habits That Prevent Problems

Write scope down

Verbal agreements about scope do not count. If it is not in the proposal, it is not in the project. When the client asks for something new mid-project, I respond with: “I can add that. Here is what it would cost and how it affects the timeline.”

Deploy on day one

If the deploy pipeline is not working on day one, it will be a problem at the end. I set up CI/CD before I write business logic.

Communicate proactively

The worst thing a freelancer can do is go silent. Even if I have nothing to show, I send an update. “Still working on the API integration, running into a rate limit issue, expect to have it resolved tomorrow” is infinitely better than silence.

Say no to scope creep politely

Scope creep is not malicious. Clients get excited when they see progress and want to add things. That is a good sign. But I still need to manage it. “That is a great idea. Let us finish the current scope first, and then I can quote that as a follow-up” keeps the project on track without making the client feel shut down.

Finish strong

The last ten percent of a project is where most freelancers lose credibility. The exciting work is done, and what is left is polish, documentation, and handoff. I treat the last phase with the same energy as the first because it is what the client remembers most.

Final Thought

Good freelance work is not about being the best coder. It is about being reliable, clear, and easy to work with. The technical skills get you in the door. The process skills keep you there.

If you need a developer who ships clean work on time, take a look at my portfolio: voidcraft-site.vercel.app.