How to Price Your Freelance Work

I’ve been doing freelance web development for the past 10 years or so and every time I meet a new client the unavoidable question about pricing always pops up: “How much will it cost to build my app?”.

Developing a web application takes time and money and depending on its complexity both these variables can get to crazy numbers. So it’s only fair to expect anyone in that position to want to know the cost before jumping into a contract.

The answer though is, “It depends”.

Pricing Your Freelance Services

Every project is unique in the sense that it has it’s own unique requirements, assets and course corrections. So let’s talk about a few approaches to cost estimation and some tips on how to approach a new project/contract.

How Estimating Works

Estimating the amount of work required to building a web application is close to being an art form because it needs to factor in so many variables that it’s almost impossible to have it right. Even for projects that have perfect requirements there are still a ton of corner cases that will only come to light once you start building them and more importantly once you see them live.

It helps to use the “house building” analogy here to make things a bit easier to understand. So let’s try to answer the question “How much does it cost me to build my house?”.

Well… depending on the materials you choose, the people you hire, the distance to the store, the weather and probably a bunch of many more factors, the final price will change. Even if you thought about it a hundred times and wrote down every detail that crossed your mind, there’s still a big chance that new things will start to pop up once you start building.

So getting an exact amount for the work that needs to be done is close to impossible. But what you can get though is a rough estimate. That will give you a ballpark, so let’s see how that works.

What Is a Rough Estimate

A rough estimate is the approximate cost estimation of building all the specs you can think of right now plus an added buffer to cover the estimation errors of those specs.

A rough estimate still requires a lot of detailed planning up front to get the initial spec in order and then some time to estimate each and every feature of that plan, but at least it’s something you can work with when you really need a fixed amount.

So you’ve invested the time and effort to get to a fixed price estimate and now everybody’s happy. Not so fast, there’s one gotcha here, a big one. Working with a fixed amount estimation won’t work in most cases for two reasons which we’ll talk about next.

Why You Don’t Want a Fixed Price Estimate

The only thing constant about web application development, is change.

So even if you do have the perfect plan laid out about what you should build, the truth is something is always going to change. And that is a good thing, you want to be able to receive feedback as you go and adapt the application according to that feedback. That’s how great applications are built.

Now, given you’ve agreed to a fixed price, there’s not going to be much room for change because those will render your estimate useless.

All is not lost though because there’s another way.

How Do Hourly Rates Work

Paying by the hour tries to solve the problem of having a fixed cost estimate upfront by being flexible about adapting the application as you go and only charge for the work that’s being done. This means that you’ll get the benefit of change and the exact amount you need to charge.

There’s one thing missing from this equation though. You still don’t know ahead of time how much you’re going to pay for the final product. And, for this method to work you need to address two critical issues.


Trust is mandatory for the hourly method to work. It’s very probable that your client won’t be a senior developer to be able to estimate the right amount of time it would take each task to complete in order for him to feel comfortable that you’re not over charging.

Usually your client is going to be someone that’s less technical than you are and so he’s going to have to trust that you’re doing your best to solve each problem and only charge for the time you’ve spent on solving those problems.

The only thing that works on both sides is trust. You need to give trust to receive trust, no matter what side of the fence you are on. Sorry to humanize your business relationship like that, but that’s how it works in real life.


The experience factor plays a very important role in the final cost of building an application for a number of reasons.

The more experienced you are as a developer, the less time you need to build a feature.
Experience helps in anticipating future issues, by making the application future proof, you reduce the cost of extending and repairing bugs in the future.
You can avoid time and cost spent on dead ends by evaluating and avoiding the wrong paths ahead of time.

Of course this also means that the more experienced of a developer you are, the more value per hour of work you are providing to your client. Just to make things clear, let’s see a quick example.

Evaluating Freelance Developers

Say your client talks to Joe and he charges $70/h then he talks to Kevin and he charges $120/h. If experience would be irrelevant, he would probably choose Joe because he is cheaper. Now let’s factor in their experience. Let’s say that the time it takes Joe to get the project done is 5 hours while Kevin will only need 1.

So here’s the math:

  • Joe 70 * 5 = $350
  • Kevin: 120 * 1 = $120

So as you can see, the difference between a more experienced developer and a less experienced one can be significant in terms of time required to complete a feature.

The Hybrid Approach

There’s a fourth method that I’ve used lately which is a hybrid between the fixed price and hourly method. This one is trying to merge the two in the sense that it gives you a fixed number you can take to your client so he can plan his budget and it also gives you the flexibility of the hourly method where you can change the specs as you go.

It achieves this by breaking down your application specs into layers (or milestones) which serve as building blocks. Each building block provides a new layer of added business value to the ones before it. So that means that you can build the application incrementally but at the same time show it to your client.

So you would brake each project down into smaller chunks that would take no more than a day to complete. One day would be the maximum amount of time for one task and the minimum, probably around an hour. So that would give you a range of 1 to 8 hours to estimate each chunk.

The hybrid approach has the following benefits.

  • Your client always has a working application that he can show off or test or even charge for.
  • You both know how much the next milestone will cost, because it’s easier to estimate the building blocks than it is to estimate the whole application.
  • Your client can easily change the specs as you go, by adding, changing or removing those building blocks.
  • You only charge for what gets built.


Choosing a pricing method that allows you to focus your attention on coding and also provide your client with both flexibility and peace of mind is the holy grail of pricing your freelance services. So make sure you spend the time upfront to get it right.

I hope you’ve learned a thing or two about pricing your next freelance project. I would love to hear your thoughts on the subject or any other methods you’ve used and worked great for both you and your client so please let me know in the comments, via Twitter or email.

Original URL:

Original article

Quill – A cross browser rich text editor with an API

Webdriver Test Status

Quill is a modern rich text editor built for compatibility and extensibility. It was created by Jason Chen and Byron Milligan and open sourced by

To get started, check out the Quill Github Page or jump straight into the demo.


Instantiate a new Quill object with a css selector for the div that should become the editor.

<div id="toolbar">
  <button class="ql-bold">Bold</button>
  <button class="ql-italic">Italic</button>

<div id="editor">
  <div>Hello World!</div>

<script src=""></script>

  var editor = new Quill('#editor');
  editor.addModule('toolbar', { container: '#toolbar' });

Downloading Quill

There are a number of ways to download the latest or versioned copy of Quill.


<link rel="stylesheet" href="//" />
<script src="//"></script>

Local Development

Quill’s source is in Coffeescript and utilizes Browserify to organize its files.


npm install -g grunt-cli
npm install


grunt dist - compile and browserify
grunt server - starts a local server that will build and serve assets on the fly


With the local server (grunt server) running you can try out some minimal examples on:

Quill releases also contain these examples as built static files you can try without needing to run the local development server.


grunt test:unit - runs javascript test suite with Chrome
grunt test:e2e - runs end to end tests with Webdriver + Chrome
grunt test:coverage - run tests measuring coverage with Chrome

Tests are run by Karma and Protractor using Jasmine. Check out and config/grunt/ for more testing options.



Get help or stay up to date.

Bug Reports

Search through Github Issues to see if the bug has already been reported. If so, please comment with any additional information about the bug.

For new issues, create a new issue and tag with the appropriate browser tag. Include as much detail as possible such as:

  • Detailed description of faulty behavior
  • Affected platforms
  • Steps for reproduction
  • Failing test case

The more details you provide, the more likely we or someone else will be able to find and fix the bug.

Feature Requests

We welcome feature requests. Please make sure they are within scope of Quill’s goals and submit them in Github Issues tagged with the ‘feature’ tag. The more complete and compelling the request, the more likely it will be implemented. Garnering community support will help as well!

Pull Requests

  1. Please check to make sure your plans fall within Quill’s scope (likely through Github Issues).
  2. Fork Quill
  3. Branch off of the ‘develop’ branch.
  4. Implement your changes.
  5. Submit a Pull Request.

Pull requests will not be accepted without adhering to the following:

  1. Conform to existing coding styles.
  2. New functionality are accompanied by tests.
  3. Serve a single atomic purpose (add one feature or fix one bug)
  4. Introduce only changes that further the PR’s singular purpose (ex. do not tweak an unrelated config along with adding your feature).

Important: By issuing a Pull Request you agree to allow the project owners to license your work under the terms of the License.


BSD 3-clause

Original URL:

Original article

Xbox One vs. PlayStation 4: Two Years Later

It’s been nearly two years since the launch of the Xbox One and PlayStation 4. With dozens of software updates and a price drop, choosing between the two is much harder than it was in 2013. So, we decided it was high time to compare them now that they’ve hit their stride.

Read more…

Original URL:

Original article

EverythingMe closes down despite raising $37.5m

Five years after it was founded, and after raising $37.5 million, startup EverythingMe, which developed a launcher for Android devices, announced it was closing down and laying off dozens of employees. CEO Rami Kasterstein, CTO Joey Simhon, and Ami Ben David founded the company in 2010 under the name DoAT Media. Kasterstein and Ben David are former employees of Aladdin Knowledge Systems.

EverythingMe had a respectable list of investors, including Spanish giant Telefonica, Singapore telecommunications company Singtel, Firefox browser maker Mozilla, Li Ka-shing’s Horizon Ventures, BRM Capital (controlled by the Barkat brothers), DFJ Tamir Fishman Ventures Ltd. (TASE: TFVC), and others.

The signs of problems in the company began early this year, when reports indicated that the company was laying off 20 employees, some of them from its content department. The company is now laying off its remaining 36 employees. The unofficial reason why the company is closing down is its inability to consolidate a business model for the development of an Android launcher in a rather competitive market.

The three company founders initially went in a different direction, before deciding to developing a launcher that would accommodate a completely different interface on the Android device. The original idea was a search of applications and the Internet, the results of which are displayed as icons of the relevant content, such as Wikipedia, IMDB, YouTube, etc., instead of an ordinary list of links. The company launched its product in the Disrupt competition of the TechCrunch popular technology blog, but since then replaced its name and the model it offered.

No response from the company was available.

Published by Globes [online], Israel business news – – on October 25, 2015

© Copyright of Globes Publisher Itonut (1983) Ltd. 2015

Original URL:

Original article

Proudly powered by WordPress | Theme: Baskerville 2 by Anders Noren.

Up ↑

%d bloggers like this: