How to Price Your Freelance Development Work — A Framework That Actually Works

Pricing is the skill most freelance developers never properly develop. It cost me real money early on. Here's the framework I've settled on after two years and multiple countries.

The Mistake: Value-Agnostic Pricing

Early freelancers price based on hours × hourly rate. The problem: it optimizes for time spent, not value delivered.

A client with a €50,000/month logistics operation who needs a €5,000 integration that saves 20 hours/week of manual work doesn't care about your hourly rate. They care about the ROI. If you charge €2,000 because "it'll take 20 hours," you're leaving €3,000 on the table and signaling that you don't understand their business.

The Framework: Three Inputs

1. Your floor rate (cost + desired income)

Calculate honestly:

Monthly living costs (rent, food, transport)
Business costs (software, equipment, accounting, insurance)
Time off (vacation, sick days, business development — these don't bill)
Taxes (as a freelancer you pay both sides of social contributions)

A developer targeting €4,000/month net in France might need to bill €8,000-9,000 gross to clear that after taxes and costs. With 15 billable days/month (realistic with sales and admin time), that's ~€550/day minimum.

2. Market rate for your skills

Check what the market pays:

Malt, Upwork, LinkedIn salary surveys for your stack and seniority
Talk to other freelancers in your network
Look at what agencies charge clients for similar work (then you can undercut them meaningfully)

A senior full-stack developer (React/Node/Django) in France typically bills €500-800/day. In Morocco for international clients, €200-400/day is competitive. Know your market.

3. Value to the client

Ask before quoting:

What's the business impact of this project?
What does failure cost them?
How long has this problem existed without a solution?
Do they have a competing quote? (Tells you their price sensitivity)

If a €10,000 project saves them €50,000/year, pricing at €4,000 leaves value on the table. Pricing at €8,000 is still an obvious ROI.

Fixed Price vs Time-and-Materials

Fixed price works when:

Scope is clearly defined in writing
You have done similar work before and can estimate accurately
The client wants predictability and will accept scope discussions

Time-and-materials works when:

Scope is genuinely unclear (R&D, MVP exploration)
The client wants flexibility to change direction
You're working embedded in their team

I default to fixed price with a detailed scope document. It forces both sides to think clearly about requirements upfront, and it protects you when you build faster than expected.

The Scope Document

Every fixed-price project starts with a scope document before any contract is signed:

PROJECT: BatailLog — Order Management Module

IN SCOPE:
- Order creation form with validation
- Order list with filters (status, date, company)
- Order detail view with history
- Status update workflow (PENDING → PROCESSING → DELIVERED)
- Email notifications on status change (via Mailjet)
- API endpoints for mobile app consumption

OUT OF SCOPE (explicitly):
- Mobile app development
- Payment processing
- Integration with external ERP systems
- Inventory management
- Reporting/analytics
- User role management beyond what exists

ASSUMPTIONS:
- Client provides access to existing database schema
- Client handles deployment infrastructure
- UI follows existing design system
- No more than 3 rounds of revision per deliverable

TIMELINE: 6 weeks
PRICE: €X,XXX

The "OUT OF SCOPE" section is the most important. It sets the boundary before the project starts, making change requests unambiguous.

Handling Change Requests

Scope creep is inevitable. How you handle it determines your profitability.

My rule: anything not in the scope document is a change request. Not a negotiation — a clear statement:

"That's a great idea. It's outside our current scope, so I'll put together a separate estimate for it. Depending on timeline, we can either add it to this project or kick it off as a follow-on."

Never: "Sure, I'll just throw that in." That's how projects become unprofitable.

Template change request response:

Change Request #2 — [Feature Name]

Requested: [Description]
Estimate: X hours / €X,XXX
Timeline impact: +X days
Payment: Due before work begins on this item

Please confirm to proceed.

Payment Terms That Protect You

30% upfront — always, without exception. If a client refuses, that's a red flag.
30% at midpoint — defined by deliverable, not calendar date
40% on completion — not "when they're happy," but "when deliverables are delivered"

For longer projects: monthly billing with a net-7 payment term. Invoice on the 1st, due on the 8th.

Late payments happen. Add a late payment clause in your contract (e.g., 1.5% per month on outstanding balance). You'll rarely need to invoke it, but it signals you're serious.

Why Charging More Often Gets Better Clients

This is counterintuitive but empirically true in my experience:

Low-price clients often have the least clear requirements
They scope-creep most aggressively
They delay payment most frequently
They give the least creative latitude

Higher rates filter for clients who've done this before, understand what good work costs, and value the relationship enough to invest in it. The best clients I've had were not my cheapest.

Raise your rates. Lose some leads. Keep the good ones.