It seems like you are using an ad blocker. To enhance your experience and support our website, please consider:

  1. Signing in to disable ads on our site.
  2. Sign up if you don't have an account yet.
  3. Or, disable your ad blocker by doing this:
    • Click on the ad blocker icon in your browser's toolbar.
    • Select "Pause on this site" or a similar option for lancecourse.com.

Why you can't do a favor when charging for a website development or design?

One confusing and a major problem in web development is the estimation of the project cost and its time frame. Although everyone uses various options in many ways, an exact estimation of a project cost remains a hard duty to individuals and companies. In the actual case, either the client is over-charged or the developer/company is less paid.

In most cases, the client is charged bases on the importance of their project. An eCommerce website done for an individual might be cheaper that the same website built for a company. Which is still unfair.

Most of us have gone through these steps when we start freelancing or a startup in web development/designing or in software development, a confusing and undefined process.

It is not surprising, then, that the ability to estimate project resources, including the time resource, is still relatively undeveloped. -The dynamics of software project scheduling by Tarek K. Abdel-hamid and Stuart E. Madnick

Recently a client contacted me for a project. He sent me a pitch on the idea and wanted to know how much I would charge. It's a friend of long dates. So I told him I would be charging him some $xxxx.

Then he replied that the price was too much for him and aside from that we're friends, he would like me to reconsider my price and do him some favor.

I perfectly understood his request and we all do that often. But, one thing left me surprised: do a favor.

There is nothing wrong in doing a favor to a friend/client of course, but I kept on thinking of how I can adjust some tasks and expenses in order to help him as he wishes. Then I asked myself a question:

what does -do a favor- actually mean in my job?

Since there is a whole lot of challenges to go through to achieve that work:

  • This is a project which could take me up to a month or more
  • I would need to pay for its hosting and domain name
  • I will be using the internet all the time
  • Electricity is my fuel
  • A lot of phone calls(note, international calls)
  • A good dosage of coffee and coke
  • Some Kg of rice and stew
  • I would probably have to travel to them once or twice
  • Some new nerve connections to establish or even break them
  • etc.

The strangest part is that, usually, either we like it or not, we end up helping the clients define and plan their own project because establishing a connection between their product/service and a technical service like ours is almost impossible for a non-technical person.

These challenges can go countless and multiform depending on the project, its context and the people to work on it. With all this, I realized that I have done a lot of favors so far. And this now can help me re-think of how to estimate the cost of projects.

Note those needs above have nothing to do with the code itself. It's more of personal and contextual. That's probably what make project cost estimation a serious headache. You can't have fixed figures or a strategy to get them perfectly. From one project to another the situation can also be different altogether.

I have always found it hard when I am asked how much to charge for a project. Even if a client comes with a list of specifications, still the context and skills needed to execute them can always impact how we define our prices.
At the end, a project P you do for a client C can have a different price and time frame with a client C'.

After all, the budget or cost of a project is not only meant to feed developers or designers. It's first importance is to be used on executing tasks related to the project. Reducing or not getting an adequate estimation which is required to cover all the needs in a normal execution of the project could affect the outcome in a dramatic way. Either the developer would have to add his own resources to the budget or sacrifice his pay. Which means, working without encouragement. And we all know this will never lead to a good result.

So, basically, doing a favor for any serious project wouldn't be possible. Because it would negatively impact the project and the team around it. Asking a developer/team to do a favor actually means he/she shouldn't deploy all resources and skills on the project or he/she should use his/her own resources to support some expenses on your project. What of the time taken on it?

When we make an overall look at a project, there are usually five main axes to consider:

  1. Tools and facilities required helping you do the work
  2. Your skills and experience in the field
  3. The type and requirement of the project
  4. The client
  5. Time

The first aspect can be estimated, with some hard work. But, the second one seems related to each person or each set of people.
This aspect usually causes a lot of difficulties. Because our skills and experience are relatively different, and there is no mathematical way to estimate that. What someone can do in a day another person would require a week to accomplish that same task. Some of us are pragmatic while others aren't. The pressure on you can affect how you use your skills too.

The third one is probably the main axes of all others. it defines how other aspects should be considered and done.

The client is the one to say how things are going to be. His requirement defines entirely the work you have to do. Clients can also vary. For example, an individual may have a low need in security measures while a company might make it compulsory. Your client's desire can change entirely how you charge.

The last one is the sum and factor of the first two. The time you spend on each one of the first two will determine the time spent. A delay or a failure to satisfy any of the first two quickly will come back to you as a load of time.

The problem of resource estimating of computer program system development is fundamentally qualitative rather than quantitative. We don't understand what has to be estimated well enough to make accurate estimates. Quantitative analyses of resources will augment our qualitative understanding of program system development, but such analyses will never substitute for this understanding -The dynamics of software project scheduling by Tarek K. Abdel-hamid and Stuart E. Madnick

Since this process is more of quality than quantity, whatever the outcome estimation, it will always depend on the developer or the firm, people involved and their respective experiences.

To estimate a project, you can focus on those five points above. You can divide each into sub-options and have a clearer pricing scheme. For example depending on the type of a website(basic, advanced, or custom) you can define a price based on your experience level. You can make use of this Atilus article if you want more details on pricing or this D3 cost estimator.


Cover image credit to templatemonster.com