---
status: "published"
title: "How to Price Your Time and Work as a Freelancer"
date: "2017-07-24"
description: "A practical guide to pricing freelance services — moving beyond hourly billing toward value-based pricing."
image: "https://github.com/user-attachments/assets/f421418e-8241-46bc-8f89-65a3ce574017"
imageAlt: "DEV.BG talk - How to Price Your Time and Work as a Freelancer"
author: "Vlad Sabev"
authorUrl: "https://github.com/vdsabev"
authorAvatar: "https://github.com/vdsabev.png"
tags: ["freelancing","software development","talk"]
navigationIndex: 0
---

> ℹ️ This post has been translated from a talk I gave in Bulgarian in July 2017: https://dev.bg/event/kak-da-otsenyavame-vremeto-i-truda-si-kat/

Hi, I'm Vladimir. I've been developing web applications as a freelancer for over four years now. For the past two years, I've been regularly coming to Betahaus to work on my projects.

Let me start with a quick poll — how many of you are currently freelancing? How many want to?

My goal tonight is to share my personal experience, and also to hear your thoughts if you have any, about:

- What it's like to work as a freelancer
- How you determine the price of your services
- And where our sector is heading as a whole

I also want to highlight the different ways we can define our work, even ourselves. On one hand, as efficient executors of the tasks we're given; on the other, as independent, creative professionals. As people who go with the flow, or who set the direction of the flow. As people who sell their time, or who create value for their clients.

## Why Choose Freelancing?

First of all — why would we even want to choose a freelance career? Let's look at how some companies currently work.

### The Status Quo

What does an average software project need? A designer, web and mobile developers (at least for iOS and Android, of course), server-side developers, databases, testers, and a "manager" to lead the team and communicate with clients. Not to mention supporting departments like accounting, HR, and so on.

Clients see the result once every few months after a "giant periodic code deployment," and products only hit the market at the end of a development cycle that can take years. And the vicious cycle repeats over and over with each new project.

### Waterfall Development

This is the so-called Waterfall model. Formally, the process is:

- 20–40% of the time is spent on requirements, analysis, and creating the design
- Then 30–40% on product development
- The rest on testing and fixes

Outside of software, one example of such waterfall development from the end of the last century is the company Iridium. Founded in 1991 with $5.2 billion in investments, their goal was to create a global satellite phone network that could work everywhere — from the Sahara Desert to a ship in the Pacific.

The first step was to purchase 15 rockets from Russia, the USA, and China. They then began launching their satellites into orbit. The catch was that to work reliably, they needed to launch all 72 satellites — and that took seven years. Just nine months after their first official satellite call in 1998, the company went bankrupt.

Why? Because during those seven years, other mobile technologies advanced at a staggering pace. Cell phones shrank to pocket size, their price dropped, and coverage improved significantly. Satellite phones, by contrast, remained bulky, expensive, and had poor indoor coverage. Today, years later, Iridium has been revived and even launched new satellites using SpaceX rockets, with about 850,000 subscribers. Still, it's a classic example of how a product developed for too long can become obsolete by the time it reaches the market.

### Agile Development

That's why there are other ways to create a new product — for example, developing it in small steps, releasing it to market as quickly as possible after each cycle, gathering feedback, and making changes on the fly.

The word "Agile" itself has become very commercial in software circles, with a lot of hype around it — deserved or not. My personal impression is that it's difficult to apply specific practices like Scrum, Extreme Programming, and so on correctly within a team without access to an expert who's well-versed in the principles and strictly monitors their adherence.

### Not Quite Agile...

A few years ago, when I worked at a "normal" Bulgarian software company, we used something of a hybrid between Agile and Waterfall. It involved months of writing documentation, followed by a multi-year development and testing phase. We claimed to practice Scrum because we had standup meetings every morning — but the reality was very different.

We deployed a new "version" once every few months. We received client feedback only after that big deployment, and we often had to significantly rewrite or even throw away functionality we'd worked on for weeks.

The project started in the summer of 2010. The last I heard from former colleagues, the clients abandoned it in early 2016. Throughout all that time, the project was in development, always "unfinished" according to the constantly expanding client criteria, and was never used by real users.

### The Good News

Fortunately, the possibilities for developing software products have improved significantly in recent years. Mobile devices are becoming cheaper, more powerful, and more widespread, and an ever-growing volume of data is exchanged between them. The browsers on these devices are extremely capable and increasingly follow common standards.

With progressive web apps, for example, we can "install" a regular web page from the browser on our mobile device, just as we'd install an app from the App Store or Google Play. In certain cases, this allows us to adapt a web application to different mobile platforms with relatively little additional resources and effort. This means a single developer (possibly with a designer) could create certain types of projects in much less time than the previously described ten-person team.

For example, we created a progressive web app for Betahaus residents. Sometimes the toilet paper simply runs out and we need help — so I made sure it worked well on mobile devices. When we submit a request for a supply item through our mobile device, the server sends a notification to the Betahaus team's Slack channel, but no more than once every 15 minutes to prevent spam.

Another feature of progressive web apps is that we can deploy new versions at any time, without waiting for approval from Apple or Google. After all, they're just web pages, and the internet is a very open platform.

### Ship Often

Actually, perhaps the most important part of the process is shipping the product. As Joel Spolsky says: "Shipping is a feature. A really important feature. Your product must have it."

If we do it more often, we avoid the situation where we accumulate new functionality for months, deploy it all at once, and then find out clients actually wanted something completely different.

To have the confidence to show the results of our work several times a day, high code quality is essential. For me, this means:

- Tools and processes that catch and correct style errors and code issues
- A suite of tests that run automatically on every file change
- Code review before changes are deployed

You might have read in the Agile Manifesto's principles that we should deliver software at most every two weeks. Let's consult one of the participants in creating that manifesto — Robert Martin, better known as Uncle Bob.

When asked, "Don't today's technologies allow us to deploy new software versions several times a day?", he replied:

> "At that time, in 2001, we couldn't imagine a shorter period than two weeks. We thought it was the lower limit, and nobody challenged it, and that was clearly shortsighted."

He added: "Think of the manifesto as a call to action for that specific moment, not as Scripture to follow."

So I quite comfortably deploy new code versions several times a day. And clients get really excited when they see their feedback reflected within the same day or even within minutes.

### So... Why Choose Freelancing?

If you've ended up in one of those organizations where you've lost the feeling of flexibility and productivity, you might appreciate being part of a smaller team or even working entirely on your own. When we have all these tools to simplify much of our work, why not use them?

Some companies try to adapt to a more flexible way of working. But most take years to adopt and then implement new ideas, if they ever do. So for those who value their time and want to move faster than the status quo, one solution is to work as a freelancer.

Personally, I initially had no intention of getting into freelancing. In 2012, I had already worked for over two years at the Bulgarian software company I mentioned earlier. Unexpectedly, they entrusted me with a new project for American clients because I was the only one familiar with the technology they were looking for. The project was an online event management platform, and I was leading a small team of 3-4 people.

## How to Face the Challenges

A few months into the project, even though the clients were satisfied, I myself was on the verge of professional and emotional burnout. I felt exhausted from working at the company and had an acute need for change. I wanted to set the direction of the flow myself.

That's when I came across Tim Ferriss's book *The 4-Hour Workweek*. I didn't have ambitions to work that few hours — I just wanted to be more independent and free with my time.

### Fear Setting

One chapter of the book that particularly impressed me described an exercise called Fear Setting. In short, you start with an action you want to take but feel some hesitation about.

To explore the obstacles before us:

1. **What could happen if...?** — For example, "What could happen if I quit my job and go abroad?" List the absolute worst-case scenarios you can imagine.
2. **How can I prevent them?**
3. **How can I fix the consequences** if they happen despite everything?
4. **What could be the benefits** of trying, or even partially succeeding?
5. **What could be the consequences of inaction** over the next 6 months, 1 year, 3 years?
6. Finally, **assess the probability and impact** of all these undesirable events.

It seemed simple enough, so I decided to try it. I created a Google Sheet with my analysis.

Here's what my assessment looked like:

**If I quit my job and went abroad:**
- Depleting all my savings — 50% × 4 = 2.0
- Not finding a job in Sofia — 10% × 6 = 0.6
- ... — 40% × 4 = 1.6
- ... — 10% × 3 = 0.3
- ... — 10% × 7 = 0.7
- **Total score: 5.2**

**If I stayed at my job:**
- Stress — 80% × 5 = 4.0
- Project failure — 10% × 4 = 0.4
- Worsening health — 20% × 8 = 1.6
- Professional stagnation — 40% × 5 = 2.0
- **Total score: 8.0**

What I saw was that if I quit, there was a small chance of unpleasant consequences. None were both highly probable and highly impactful. Hypothetical, unlikely, or minor obstacles. Total score: 5.2.

On the other hand, if I stayed at my job, there was a high probability that the strongly unpleasant consequences I was already feeling would continue and seriously affect my health. Total score: 8.

You might notice we're not evaluating the benefits of the action here — we assume that if we feel the desire to try something new, we sense it would be better than our current situation.

### The Decision?

After this exercise, it was much easier to make a decision. I handed in my one-month notice and bought a one-way plane ticket to Sweden. I didn't know why there, or what exactly I would do, but I wanted to try something different.

In the end, I traveled for over two months abroad, and in my free time, I continued working on the same project with the American clients, without any discussion of payment. They were happy with my work and wanted me to continue — this time with financial compensation. So a few months later, I registered my own company and issued my first invoice.

## How to Price Your Time and Work

To issue that invoice, I had to agree on a price for my services. Negotiating my compensation was entirely new to me, so I chose what seemed most reasonable for a freelancer — by the hour. A few years later, on another project, I worked on a monthly salary. In between, I completed several small fixed-price projects.

I want to share my impressions of all three approaches, looking at:

- The types of projects I worked on
- My working hours
- My motivation to seek new ideas and develop my skills

### By the Hour

Many freelancers work by the hour. In my case:

- **Project type:** Open-ended, startup company
- **Working hours:** Flexible, from home
- **Tendency:** Getting lost in details
- **Compensation:** Limited number of hours

The project had an indefinite duration — I expected more than 6 months and less than 6 years, but it wasn't clear exactly how long. The clients had no existing users, only a business idea.

My working hours varied enormously from month to month — between 4 and 200 hours. Due to the time difference with California, I often worked late at night or very early in the morning, mostly from home. I frequently caught myself wondering whether I was working or not, and whether I had started the timer tracking my hours.

Subconsciously, despite my best intentions, I felt inclined to spend more time on tasks than necessary, to get lost in unnecessary details, and to tweak pixels for ages, accumulating more billable hours.

Objectively, the number of hours we all have is limited. When working by the hour, there's an artificial ceiling on your income. If you discover a new technology or approach that lets you do the same work twice as fast, you'd get paid half as much for it. There was no incentive to optimize my work — quite the opposite.

### On Salary

For the next project I took on, I wanted to work on a monthly salary:

- **Project type:** Open-ended, startup company
- **Working hours:** Fixed, in an office
- **Tendency:** Getting distracted
- **Compensation:** Fixed

The project was again long-term with an indefinite duration. The company was a startup, but this time with an established business model — the goal was to bring it online.

After my previous experience with fragmented working hours, I wanted to work 7-8 hours at a stretch, preferably in an office space surrounded by other people. That's when I came to Betahaus.

However, I found myself interested in doing the minimum sufficient amount of work. I'd read my favorite sites during work hours, extend my lunch break, come in later or leave earlier. In short, I'd find ways to get distracted as long as the client was satisfied. There's an argument that this is perfectly normal, part of modern daily life, and even necessary for creativity. But I have doubts about whether this is the best way to develop my professional skills.

And the compensation was fixed every month — again, no incentive to find ways to work more efficiently.

### Per Project

In addition to long-term projects, over the past four years I've also worked on several projects for non-profit organizations and two small commercial projects:

- **Project type:** Fixed-term, established company
- **Working hours:** Flexible but with deadlines
- **Tendency:** Working faster
- **Compensation:** Theoretically unlimited

They had a defined timeline and clearer end goals. The companies had an established business model — the projects served to improve a specific part of their process.

I could work whenever and as much as I wanted. Having a rough deadline and periodic meetings with the client helped me work more diligently. I still tracked my hours, but only to know how long each task had taken for future reference.

I felt motivated to complete the project faster and more efficiently. For some people, this might backfire and lead to a drop in quality. For me, the effect was that I made measured compromises to finish tasks within a reasonable timeframe. The results were balanced — I neither delved into excessive detail (which I often do) nor rushed through things.

Regarding pricing — for the non-profit work, it was pro bono. For the small commercial projects, the hourly rate was relatively low since they were for a Bulgarian company. But I definitely felt that my focus was on achieving the project's goals, not on waiting for time to pass.

### Breaking the Time Barrier

This is exactly the approach I want to talk about. I came across a book called *Breaking the Time Barrier*. It's a short story that, in about an hour of reading, explains a simple idea: price your services based on the value they bring to the client.

Imagine you own a business and know a feature could bring in an additional 1000 BGN per month. You need a capable developer to build it:

| Developer | Price | Timeline |
|-----------|-------|----------|
| Developer A | 3000 BGN fixed | 1 month |
| Developer B | 20 BGN/hour | 1 month |
| Developer C | 15 BGN/hour | 1.5 months |

Let's say all three are equally capable.

Developer A's offer can be seen as an investment rather than an expense — one that pays for itself in 3 months. Plus, Developer A has an incentive to finish faster, which means your business starts generating additional revenue even before the 1-month mark.

With Developer B, you might pay less than 3000 BGN, but there's a risk of paying more. Developer B has an inherent interest in working slower to bill more hours. You might be surprised by the final invoice.

With Developer C, the risk of delay or budget overrun seems even greater. And the lower rate might give an impression of lower quality.

### Clarifying the Goals

What if your client doesn't know exactly what revenue their idea could generate, or how it could be measured? For example, they want a new website design because they think the "old one is ugly." In that case, we can ask clarifying questions:

- To establish the starting point — why do they think the site is ugly and needs our services?
- What are their long-term business goals?
- How will we measure the effect of our work? For instance, if before 50% of visitors liked the design and after our changes 80% do — that's measurable improvement.
- How valuable is a new customer to the business? How much do they spend on average over the years?
- How valuable is it to retain an existing customer?
- How many customers do they expect to attract or retain?

Most established companies know their clients well and can answer these questions. I believe this is a much more objective way to price services than thinking about our own rent, car payments, or grocery costs. Clients don't care about that.

### More Than Just Executors

In the process of clarifying goals, we transform into something more than just task executors. Using a construction metaphor — executors lay bricks. We can work at another level, offering architect services, giving ideas, and thinking in different directions. This is important because:

**The client is always right about the problem they have, but not always about the solution.**

Our job is to find the best solution for the problem. Maybe our services would cost more than the client anticipated, but they'd also get more than if someone simply executed their wishes by the hour.

And sometimes the solution turns out simpler than they thought. I was recently asked for advice on building a real estate website. My first idea was what I knew best and what's most traditional — a web app, database, server. But after asking a few questions, I realized it could be much simpler: instead of a database, use Google Sheets and load the properties directly into the browser with a small JavaScript library. Most realtors probably already know how to use Excel, or in this case, Google Sheets.

So sometimes, starting with well-directed questions, we can find a better solution than the usual one.

### Investment, Not Expense

As I experienced first-hand, with hourly or salaried work, there's no incentive to work faster — quite the opposite. If we give a fixed price for the entire project instead of an hourly or monthly rate, the client can predict from the start how much the defined result will cost.

And here's the key point — if the client knows their business well, they can think of our services as an investment, not an expense.

### Incentive for Innovation

Finally, if we base our service pricing on the value we bring to the client, we avoid a simple paradox: if it takes 100 hours to develop a project for client A, and then we modify the same project for client B in just 10 hours, we don't get paid 10 times less for the same work just because we worked 10 times fewer hours.

This gives us an incentive to be innovative, to seek new ideas and approaches. We could even develop a ready-made product or suite of products and services — Software as a Service — that we offer to a wide range of clients.

### We Are More Than the Hours We Work

In conclusion, as professionals, we are not the number of hours we work. We are the sum of all the skills and creativity we've accumulated over the years — in school, university, at work, through hobbies and personal projects. I believe our work deserves to be valued as something more than the hours spent in front of a computer, and our clients deserve something more than just executors.

We might start with hourly or salaried work while gaining experience, but we have the potential to outgrow that model. The book *Breaking the Time Barrier* has answers to many questions you might have, and probably some you haven't thought of. I recommend everyone read it — it's worth the hour you'll spend.

Some people have been approaching their projects this way for years. Personally, I'm working on integrating some of the ideas from the book. Right now, for example, I'm investing a lot of time in developing reusable tools that let me create certain types of web applications from scratch within a few days.

## The Bottom Line — Where Do We Go From Here?

So we've put in a lot of effort, had some luck, and achieved everything we wanted. We started freelancing, where we're productive and quickly integrate the latest technologies and ideas. We faced challenges and found the courage to set our own direction. We even figured out the best way to price our time and work while staying motivated and innovative.

But what comes next? How much more efficient can we become? What will our work process look like in 5 or 10 years?

According to a *New York Times* article, 51% of jobs in the USA have the potential to be automated in the foreseeable future.

"But I'm in IT," some of you might say. "Highly qualified specialist, how could this affect me?" Let's start with developers.

**pix2code** is a project that generates code from a UI designer's mockup. For now, it doesn't aim to fully replace front-end developers, but rather to reduce the time between creating a design and implementing a prototype. But who knows — maybe someday we won't need as many developers as we do now?

**The Grid** generates design based on data you provide. The system is trained with numerous examples created by professional designers. Based on these "good examples," the system automatically generates appropriate design layouts, and when you add new information, the design adapts to present it in the most suitable way.

**Generative design** takes this further — instead of designing a product ourselves, we set certain constraints and goals, and the computer creates different variations to choose from: minimum drone weight, minimum cost, minimum material usage, maximum flight stability, ability to modify and recycle the product. The generated designs look incredibly organic — even the most wild human imagination couldn't conceive such forms.

Can you imagine the incredible potential of platforms like GitHub automatically suggesting code optimizations and bug fixes, or Dribbble and Behance offering design improvements?

This automation process won't happen overnight, everywhere. Especially in IT and other "modern" freelance professions like design, digital marketing, and finance, we feel that "there will always be work" for us. Or that even if much is automated, new professions will emerge that we can't yet imagine.

But did people a hundred years ago think the same about horses? That "those automobiles are slow, dirty, noisy, and break down often" — and that horses' jobs weren't at risk? That "even if cars somehow take off, we'll find new work for horses that we can't yet imagine"? Today we know what actually happened. There are still working horses, but nothing like before.

The claim that "better technologies will lead to new types of work for horses" sounds pretty silly in retrospect. But if we replace "horses" with "people" in that sentence... suddenly it seems reasonable.

Our understanding of work has changed over the years — from agricultural labor and crafts to factory work to corporate offices. A few years from now, who knows — with increasing productivity, freelancing might become even more mainstream. But even as freelancers, what would we do if 50% of our current activities were automated? Which 50% would remain? What would be the true value of our work then? Could we still bill by the hour or by the month, or would we need to adapt in some other way?

I'd love to hear your comments, impressions, and experiences.