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”.
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.