There is no hard and fast rule on how to charge for programming services. I can only offer the methods that I have used in the past. Some may work for you, and some may not, but you have to have some idea of where to start.
All Projects
Remember when you are first starting out with a new client, there is little if any trust yet. Likely all the client has is a recommendation from someone else, if that. It's up to you to make them feel good about the money they are about to spend with you. As with any customer service business, communication is key to your success. You have to talk to the client. You have to give them updates as to how things are going, ask questions of them, show them interface designs, etc. Keep them involved in the process instead of just signing an agreement and calling them when you think the project is ready to deploy.
This approach makes things go much smoother because you know what the client wants just from their input during the process. You don't need to guess about anything, just ask questions. That's the way we get information, and it's what the client expects. Your project will run much smoother and your client will feel much better about the whole process if you keep them involved.
Charging by the hour
This model has the advantage of being flexible and is easy to change as the job requirements change. I define an "hour" of time as a "keyboard hour". That is time that I spend actually working on a project. I use a timeclock app to clock in and out of various jobs as I work on them. That way I can keep track of hours and provide accounting to the client.
I charge by "keyboard hours" and administrative hours and I separate them in the billing. Keyboard hours are coding time and administrative hours are research, travel, meetings, etc. Basically everything not based on writing code.
The downside to hourly rates is that they are flexible and can easily be changed. Clients have no idea how much time you are really spending on their project regardless of what a timeclock app report says. This model does not promote trust between you and your client(s) because there really is no accounting that can be proven. In other words, you could quote whatever total time you want and make the hours add up to that figure.
Another programmer may be a faster typist or may have already done an app similar to this project. There are many reasons that hourly rates vary wildly for a project bid. It all comes down to experience and trust. For the client, it may be all about price and the reason you got the job was because your rate was lower (because you are starting out so you bid jobs at a lower rate). That's a good idea, but you MUST be able to deliver the job on time, and you MUST be willing to live with your quote, no matter how long it takes to complete.
Bidding the project
This is my preferred method. Bid the finished project without listing number of hours or anything like that. To do this, you MUST be able to visualize the time it takes to do each section of the project. Don't rush your bid. Spend time going over the project proposal and work out all of the sections you have to complete. Dividing the project into sections gives you a means of tracking your progress. You still use projected hours, but those hours are only for your benefit for tracking progress.
This is where experience comes in, so it is important to have a lot of apps under your belt before trying this approach. It is easy to burn yourself by quoting too little, and that is fine if it is on purpose, but normally it is just running into problems that you haven't dealt with before.
Summing up
It doesn't matter how you decide to charge for your work, but you have to stick with your quote regardless how badly it hurts. The only one that can change the quote is the client by adding something new or making changes to the original proposal. those things you get to charge extra for over and above the quote. You do that with a change order.
A change order describes a change that a client wants to make to the original order. It can be adding some functionality, changing the layout or design features, or anything else that is going to take you the programmer, extra time that was not included in the original bid price.
A change order can be done by the client, but normally they are done by you. It is a detailed description of the additional work to be done after the client has described the change(s) to you. It includes all changes and additions to the software. This is where you will quote how many additional hours you will charge to complete this change order and a total price for the change(s). This is typed up and delivered to the client. The client will review it and make any further changes or additions to the change order and send it back. All of this can be done via email. Once the client is comfortable that you understand the changes required, you print 2 copies (one for your records, and one for his), and sign both. Then you deliver both to the client and have him sign both, and each keeps a copy for their records.
NEVER agree to changes over the phone. It MUST be agreed to in writing so everyone always knows what was said, and exactly what was to be done.
A project may have no change orders or hundreds. It depends on the client, and what questions you ask during the negotiations of the original proposal. The more questions you ask and the more discussion about the flow of the app during the meetings before you make your quote, the better everyone will understand the project.
Getting practice
The more apps you have written, the better feel you will have for how long something will take you to complete. This is why I suggest that you ask friends and family for ideas. Find an app in the Play Store and write a similar app. Write as many different types as you can stand just so that you are comfortable in doing new things. Every project will include things you have not done before, but the more software you have already written, the better you can predict how long it will take to complete each section.
I always break programs up into sections before bidding on them. I do it on paper, just because I like the process of writing it down and drawing a flow chart. I summaraize each section and what it has to do, and then I deal with each section as a mini program inside the main project. I find that this makes it much easier to deal with large projects without getting overwhelmed.
Whatever happens, keep these rules in mind when it comes to contract programming:
You have to live with your quote.
You have to deliver on time or before.
You have to keep the client involved in the project.
NEVER, EVER, lie to the client. If you don't know something, say "I don't know, but I can find out". Lying to the client is lying to yourself.
Be prepared to walk away from an RFQ (Request for quote). If what they want is out of your abilities or if it is simply not interesting, then refuse the quote and walk away. I promise that client will call you again in the future.
NEVER make a bid on the same day that you review the project. You don't have enough information yet. Take a day or 2 to think about the proposal. go over the problems you are likely to run into and the parts that you are not completely comfortable with yet. Just because you don't know how to implement something doesn't mean you should not bid, just find those answers before you bid.
Offer your own solutions to problems and make suggestions as the project progresses. Don't be afraid of the client, he'll appreciate your views.
In closing
Notice that I have not told you how much to charge for your time. That's because I don't know. It depends on where you live, how much experience you have, how many projects you have already done. You have to build a resume of the paid projects that you complete and clients are going to want to see that resume. Include everything you can in it, including desktop software that you have done. Everything that helps to show your experience level and ability to solve problems is helpful.
You have to arrive at a price per hour for your time that you are comfortable with starting out. That may be $15/hour or it might be $50/hour. That depends on your past work and experience. Remember you have to be able to sell yourself to the client, and that means proving your background. If you don't have a lot of experience behind you, tell the client. Be honest about things. I promise that the truth will come out during a project if you inflate your software experience or how great you are behind a keyboard.
I collect 50% of the project price up front if at all possible. Sometimes clients, especially large companies will have a payment schedule that they use based upon benchmarks that are met during the project. You have to play their game if you want those large companies to call you.
Some companies have their own software contract that they insist that you use. I NEVER use someone elses contract. Why would I? They are paying for MY experience and MY talent to solve THEIR problems. MY contract will be fair to ME and the client, and only I can assess the best way to get to the final product. Otherwise, they'd do the project themselves. I'll negotiate on what the contract must include, but be very careful about wording and have your attorney look at EVERYTHING before you submit the final quote.
Be aware that many software contracts call for the client to own the final product and source code outright when completed. This is common and it does not mean that you can never use any of that source code ever again. It will mean that you can't create a competing product for some time defined in the contract, but it does not mean that all that code can't be re-used.
Please don't hesitate to ask questions during negotiations AND during the coding of a project. Asking questions is a sign of intelligence, not of weakness.
Feel free to ask questions below, and thanks for your time.
--- Jem
All Projects
Remember when you are first starting out with a new client, there is little if any trust yet. Likely all the client has is a recommendation from someone else, if that. It's up to you to make them feel good about the money they are about to spend with you. As with any customer service business, communication is key to your success. You have to talk to the client. You have to give them updates as to how things are going, ask questions of them, show them interface designs, etc. Keep them involved in the process instead of just signing an agreement and calling them when you think the project is ready to deploy.
This approach makes things go much smoother because you know what the client wants just from their input during the process. You don't need to guess about anything, just ask questions. That's the way we get information, and it's what the client expects. Your project will run much smoother and your client will feel much better about the whole process if you keep them involved.
Charging by the hour
This model has the advantage of being flexible and is easy to change as the job requirements change. I define an "hour" of time as a "keyboard hour". That is time that I spend actually working on a project. I use a timeclock app to clock in and out of various jobs as I work on them. That way I can keep track of hours and provide accounting to the client.
I charge by "keyboard hours" and administrative hours and I separate them in the billing. Keyboard hours are coding time and administrative hours are research, travel, meetings, etc. Basically everything not based on writing code.
The downside to hourly rates is that they are flexible and can easily be changed. Clients have no idea how much time you are really spending on their project regardless of what a timeclock app report says. This model does not promote trust between you and your client(s) because there really is no accounting that can be proven. In other words, you could quote whatever total time you want and make the hours add up to that figure.
Another programmer may be a faster typist or may have already done an app similar to this project. There are many reasons that hourly rates vary wildly for a project bid. It all comes down to experience and trust. For the client, it may be all about price and the reason you got the job was because your rate was lower (because you are starting out so you bid jobs at a lower rate). That's a good idea, but you MUST be able to deliver the job on time, and you MUST be willing to live with your quote, no matter how long it takes to complete.
Bidding the project
This is my preferred method. Bid the finished project without listing number of hours or anything like that. To do this, you MUST be able to visualize the time it takes to do each section of the project. Don't rush your bid. Spend time going over the project proposal and work out all of the sections you have to complete. Dividing the project into sections gives you a means of tracking your progress. You still use projected hours, but those hours are only for your benefit for tracking progress.
This is where experience comes in, so it is important to have a lot of apps under your belt before trying this approach. It is easy to burn yourself by quoting too little, and that is fine if it is on purpose, but normally it is just running into problems that you haven't dealt with before.
Summing up
It doesn't matter how you decide to charge for your work, but you have to stick with your quote regardless how badly it hurts. The only one that can change the quote is the client by adding something new or making changes to the original proposal. those things you get to charge extra for over and above the quote. You do that with a change order.
A change order describes a change that a client wants to make to the original order. It can be adding some functionality, changing the layout or design features, or anything else that is going to take you the programmer, extra time that was not included in the original bid price.
A change order can be done by the client, but normally they are done by you. It is a detailed description of the additional work to be done after the client has described the change(s) to you. It includes all changes and additions to the software. This is where you will quote how many additional hours you will charge to complete this change order and a total price for the change(s). This is typed up and delivered to the client. The client will review it and make any further changes or additions to the change order and send it back. All of this can be done via email. Once the client is comfortable that you understand the changes required, you print 2 copies (one for your records, and one for his), and sign both. Then you deliver both to the client and have him sign both, and each keeps a copy for their records.
NEVER agree to changes over the phone. It MUST be agreed to in writing so everyone always knows what was said, and exactly what was to be done.
A project may have no change orders or hundreds. It depends on the client, and what questions you ask during the negotiations of the original proposal. The more questions you ask and the more discussion about the flow of the app during the meetings before you make your quote, the better everyone will understand the project.
Getting practice
The more apps you have written, the better feel you will have for how long something will take you to complete. This is why I suggest that you ask friends and family for ideas. Find an app in the Play Store and write a similar app. Write as many different types as you can stand just so that you are comfortable in doing new things. Every project will include things you have not done before, but the more software you have already written, the better you can predict how long it will take to complete each section.
I always break programs up into sections before bidding on them. I do it on paper, just because I like the process of writing it down and drawing a flow chart. I summaraize each section and what it has to do, and then I deal with each section as a mini program inside the main project. I find that this makes it much easier to deal with large projects without getting overwhelmed.
Whatever happens, keep these rules in mind when it comes to contract programming:
You have to live with your quote.
You have to deliver on time or before.
You have to keep the client involved in the project.
NEVER, EVER, lie to the client. If you don't know something, say "I don't know, but I can find out". Lying to the client is lying to yourself.
Be prepared to walk away from an RFQ (Request for quote). If what they want is out of your abilities or if it is simply not interesting, then refuse the quote and walk away. I promise that client will call you again in the future.
NEVER make a bid on the same day that you review the project. You don't have enough information yet. Take a day or 2 to think about the proposal. go over the problems you are likely to run into and the parts that you are not completely comfortable with yet. Just because you don't know how to implement something doesn't mean you should not bid, just find those answers before you bid.
Offer your own solutions to problems and make suggestions as the project progresses. Don't be afraid of the client, he'll appreciate your views.
In closing
Notice that I have not told you how much to charge for your time. That's because I don't know. It depends on where you live, how much experience you have, how many projects you have already done. You have to build a resume of the paid projects that you complete and clients are going to want to see that resume. Include everything you can in it, including desktop software that you have done. Everything that helps to show your experience level and ability to solve problems is helpful.
You have to arrive at a price per hour for your time that you are comfortable with starting out. That may be $15/hour or it might be $50/hour. That depends on your past work and experience. Remember you have to be able to sell yourself to the client, and that means proving your background. If you don't have a lot of experience behind you, tell the client. Be honest about things. I promise that the truth will come out during a project if you inflate your software experience or how great you are behind a keyboard.
I collect 50% of the project price up front if at all possible. Sometimes clients, especially large companies will have a payment schedule that they use based upon benchmarks that are met during the project. You have to play their game if you want those large companies to call you.
Some companies have their own software contract that they insist that you use. I NEVER use someone elses contract. Why would I? They are paying for MY experience and MY talent to solve THEIR problems. MY contract will be fair to ME and the client, and only I can assess the best way to get to the final product. Otherwise, they'd do the project themselves. I'll negotiate on what the contract must include, but be very careful about wording and have your attorney look at EVERYTHING before you submit the final quote.
Be aware that many software contracts call for the client to own the final product and source code outright when completed. This is common and it does not mean that you can never use any of that source code ever again. It will mean that you can't create a competing product for some time defined in the contract, but it does not mean that all that code can't be re-used.
Please don't hesitate to ask questions during negotiations AND during the coding of a project. Asking questions is a sign of intelligence, not of weakness.
Feel free to ask questions below, and thanks for your time.
--- Jem
