Charging for your services

Discussion in 'Teaching Programming with B4X' started by HotShoe, Mar 24, 2016.

  1. HotShoe

    HotShoe Well-Known Member Licensed User

    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
     
    Multiverse app, JCO, ilan and 19 others like this.
  2. Cableguy

    Cableguy Expert Licensed User

    As usual, clean and to the point. Thanks Jem!
     
  3. pesquera

    pesquera Active Member Licensed User

    Hi Jem, thanks for your excellent guide! What is the rate to calulate administrative hours from those keyboard hours?
     
  4. HotShoe

    HotShoe Well-Known Member Licensed User

    In my case, I charge $40/hour for administrative work and $26/hour for keyboard time. I do this from home now so I do not have the same overhead and payroll requirements anymore. If I discount anything, it is the keyboard time since there is far more of it. The customer rarely sees any mention of hourly rates except in a change order discussion though.

    --- Jem
     
    Multiverse app and pesquera like this.
  5. pesquera

    pesquera Active Member Licensed User

    oops! I was thinking that keyboard (brain) hours were more expensive than administrative hours (travel/meetings)
     
    ilan likes this.
  6. Cableguy

    Cableguy Expert Licensed User

    That is also a good point...

    What is considered to be Keyboard/administrative?

    Keyboard - Narrowed down to simply tapping in "some" code? How about "trial and error" coding, or module creation?

    Administration - Web Search, Meetings, External (experts) consultations, etc...

    How about when some specific hardware is needed, how is it accounted for? Who gets to keep the spoken hardware? if it's the developer, should a rebate be included?
     
    pesquera likes this.
  7. HotShoe

    HotShoe Well-Known Member Licensed User

    Special hardware is generally provided by the client, if not it it is charged to the client (with their permission/knowledge) and I treat it as their property.

    Keyboard hours are defined (by me) as time working on the program. That includes trial and error, coding, and debugging. Administrative time is design time not spent IN the ide, like designing the interface, doing graphics or writing out program flow (pseudo code, and flow charts). Administrative also covers accounting functions, and general office time like phone calls, tele-meetings, research, etc. It is a catch all for things not related to actual programming, but things that you must do to complete the job.

    --- Jem
     
    pesquera and Cableguy like this.
  8. Cableguy

    Cableguy Expert Licensed User


    So at the end, you give the client his "property" back, even if purchased specially for the project at hand?
     
    pesquera likes this.
  9. HotShoe

    HotShoe Well-Known Member Licensed User

    Yes, after all, they paid for it. Sometimes they don't want it and then you have something else to get rid of yourself. :)
     
    Cableguy and pesquera like this.
  10. giga

    giga Well-Known Member Licensed User

    HotShoe, Good info, communication is key. This reminds me of web design. You have a client that in visions what they want their site to look like and tells the designer I like "this" (example.com) site but only wants a "few" changes made. A couple days later/HOURS of works and at least 5 phone calls back and forth. The designer has a good idea what the client wants. Communicate because the client has one vision and your vision may be different.
     
    HotShoe likes this.
  11. imbault

    imbault Well-Known Member Licensed User

    Hi Jem, just a question, if in the contract, there is nothing concerning source code, only the final application.
    And suddenly after job is done, your client asks you for the source code, what do you suggest?

    Thks

    Patrick
     
  12. HotShoe

    HotShoe Well-Known Member Licensed User

    It happens, but without source code being a part of the contract, you have to then come to an agreement separately about the terms and the price. You need to decide what amount is comfortable to you for turning over the source. In the distant past it was routine to add 4x the contract price to release source code, but in today's world programming is less of a black art. Many independents today charge 2x their PROFIT on the original contract, and some simply hand over the source since the project was paid in the first place. Larger companies still charge a large fee for source, and others build the price into the original contract whether it is specified or not.

    There are no rules here, just what you are comfortable with doing as the developer. Personally, I believe that if the project is completed as agreed and the client has accepted the final product, the source belongs to them anyway by law (Work for hire), so I may turn it over to them or charge a minimal fee depending upon my mood at the time. It boils down to doing what you are comfortable with and in a way that you can still feel good about. Remember, you want to do more work for them in the future, so don't burn bridges by getting (or appearing to get) greedy now.

    --- Jem
     
  13. jmuhammad

    jmuhammad New Member Licensed User

    This is really good! I read this a couple of days ago then today I couldn't recall where I read it. Started getting upset that I lost it. Several Google searches couldn't find it. I finally found it by Googling (sp?) key words I remembered from the read (app+separate+administrative+"writing code"+hour). My day is made now:)
     
  14. Harris

    Harris Well-Known Member Licensed User

    Fortunately, in my situation, I have a thriving niche market. 85 percent is federally legislated to conform and standardized.
    Yet the remaining 15 percent can be as large as the first 90 percent...??? Each has different needs.
    Every company does things differently than the past you dealt with. These are usually in the form of information gathering and reporting.

    How do we shorten this dev cycle?
    We need to build a flexible (possibly user defined) input "template(s)".
    Now I struggle with this concept since it can be quite diverse.
    It usually boils down to a label (help hover), an input field, and validation ( text, number, decimal, IP, etc,).
    Now, id this field so we may use it later (device or backend)

    The question is:

    How do we make this easy, repeatable and flexible in a reusable framework to fit most any situation?

    One to many comes to mind with situation ID, but I would love to hear how others handle this.
    Everything must be designed on the server and downloaded to the device to create input forms (scroll view or page design).

    Now the reporting (data processing) must be aware of this design. Now regardless of input, the output will know how to handle the process.
    This will, of course, require custom processing since one can never predict what to do (sum, avg, or whatever) with results.

    So as I pick your brains, how do we do this properly - since many of us are not formally trained? We shall get there progressively.

    Jem has been very insightful to date. Excellent!

    Thanks
     
  15. HotShoe

    HotShoe Well-Known Member Licensed User

    I tried templates once but they are just not flexible enough. I ended up making a variation of the template each time, and that took as long as just starting a new project the traditional way. The sheer variety in contract programming is what drew me to it in the first place. That makes it hard to have a template, but you can build a "routine library". I keep code snippets that I have used in the past on a file server and have used it a lot over the years. Adding to it and re-thinking the older routines from time to time.

    In short, I don't know of any shortcuts to creating programs except in re-using code from previous ones.

    --- Jem
     
    Harris and Cableguy like this.
  16. Harris

    Harris Well-Known Member Licensed User

    One thing I have found to be very useful is the the code generator in ABMaterial. It will generate the grid and modal sheets with just a few lines of config code.
    Prior to its' existence, you were forced to write hundreds of code lines (modal sheets in particular) for one functional set. Trying to reuse this was just as painful since the field names of the new sheet rarely matched - requiring much editing, debugging and precious time. What used to take hours is now accomplished (error free) in minutes. Tools like this really help reduce the dev cycle.

    Thanks
     
  17. Cableguy

    Cableguy Expert Licensed User

    True, but it targets one specific platform/framework
     
    Harris likes this.
Loading...
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice