As a web developer I have worked with various different clients from all different backgrounds. One tip that I always hear from professors and other developers is that I should never undersell myself. When you undersell yourself it is very easy to find yourself overbooking clients so that you can find a way to pay all of your bills. The thing that always creeps back into my mind when I am deciding on a rate for a client is “If I don’t go down to XX amount of dollars per hour, they are just going to find someone else to do it.”
The cons of underselling
When you undersell yourself you aren’t just losing out on money, you are also losing out on knowledge, experience, and time. Here are some negative things that underselling myself have led to:
- Less money earned, more hours worked
- Buggy code
- Overlapping projects
- Less time for learning new skills
When I undersell myself I typically write a proposal where the development process is so efficient I could cry; there is no room for error in my estimate. The problem with this? About 95% of the time the scope of the project changes and/or a technical detail that should have worked didn’t work. So a feature that I had originally estimated at 5 hours could after debugging take about 7 or 8. That doesn’t sound like much more, but in the grand scheme of things working on a project estimated at 40 hours, it might take an additional 15 hours to complete the project if everything that can go wrong does go wrong.
What to do
So the underlying issue with the above scenario is that the developer (me) proposed the site to the client using the cheapest and cost effective solutions. The end result could be a simple to setup CMS, but hard to customize in the future. A short term plus and a long term negative. So as a developer I am beginning to move towards quality over speed. I still try and get a project done on time, but I don’t place as much on the low cost as I do on the high quality. I use the best technologies and coding practices to make sure the site is efficient and allocates the customers resources well.
I recently had a project to program a site using a new technology that I had never used before. The project was to be spread out over a couple months as the client did not have the money up front to pay in full. So I broke the project up into four phases where a phase was not complete until the client had paid for the work done during the phase. The original estimate for phase 1 was done by me to show I could the work quickly, I figured this was the most important thing for the client.
What ended up happening was that I did finish the work on time, but the client sent back revisions and bug fixes that I had not come across while testing. I ended up finishing at 140% of my original estimate on time.
For the second phase I took this prior experience into consideration and I held my ground on time decisions. If I felt a feature would take 3 hours to implement, I gave myself padding and said it would take 5 hours. What this did was set me up to do the work in the 3 hours I had planned, but to not stress out if I was approaching the mark and found myself debugging. It also allowed me to spend a bit more time debugging and re-working code so that it was efficient and bug free.
After phase two I found that I was at 80% of my estimate and the client only had minor textual and position changes that brought the time estimate up to about 85%.
What I learned
So coming out of phase one I was pretty stressed out and had a negative outlook on the project as a whole. Coming out of phase two I had a positive outlook and was pleased with myself for getting it done right. I am convinced that had I used the same process of estimation in the second phase as I did in the first phase, it would have taken longer to complete than it did. Take pride in your work, if you would feel ashamed or uncomfortable letting someone else look at your code, chances are you should give yourself more time so that the code is as efficient as possible.