I have a S-Corp on the side and do work on software development. My main job (a contracting project) is ending in a few months and I started reaching out to new clients. I found a client through a colleague I had worked in the past and had an initial call with them. Up until now I've only done hourly work (odd jobs here and there and not really a steady stream of income from my side gigs). The client reached out to me asking me the pricing structure. Here's their question:
1. Single modular project pricing
2. Hourly pricing
3. Weekly / monthly retainer
It appears that they need a formal response (and most likely a contract between the two parties in the future?). I am relatively new to this and am looking for input. My questions:
1. I've heard from others that fixed price projects should be avoided at all cost. This happens due to scope creep and vague requirements. Should I tell them I only do hourly?
2. I have no idea what a retainer is. Can someone help me with weekly/monthly retainer model?
3. They've also asked for response time/hours of availability for each one of these models. I usually do my side gigs at nights/weekends. I might be able to do some work during the day but I'd rather not commit to it as high priority things may come up at my day contract. Is it a good idea to tell them that I work only nights/weekends? Does that come across as "professional"?
4. I understand that there's a big range for software developers. Should I bid a low hourly rate to get my foot in the door (I usually work at $100/hour with my other side gigs).
Uncertainty is predominant when pricing services because projects are never described with 100% acuracy or clarity and projects bring with them unexpected, unmeasured scope of work. To price services by project with greater precision is important to measure the work done in multiple projects, understand the variables and create pricing standards based on them.
The best way to price services when such information is not available is to break down the project into 4, 5 or 6 phases (think agile), then clarify as much as possible for phase 1, analize time and estimate a cost, then measure every step of the process to build better data that will help you on latter projects.
Consider work and project description to be less or more clear based on the type of customer; customer who are first timers need to be explained many things within the process and typically have not idea what it takes, you can charge them more or prefer to work with them per hour because they will take a lot of your time; Customers with experience typically will be more clear and understand what it takes, you should charge them less, working with them is more efficient, besides they can bring you more work and referrals.
Calculate how many hours it would take to do phase 1, multiply times your fee per hour, add a 10% error margin and charge the final number; then break down phase one into deliverables (measurable progress steps) and break down payments based on those steps. I suggest 30 to 50% (retainer) to begin then divide the remaining percentage into the total amount of steps established for phase 1. Repeat for each phase.
If you are a beginer level service provider you should charge cheap and bill your customer even for the time you spend learning how to do the work
If you are an intermediate, you are expected to know the basic and do not change for any time spent leaning basic stuff, you should however charge for the time spent learning expert level activities
Lastly if you are charging as an expert, you are supposed to not only know what you are doing but also do it in a expeditious manner.
There are two sides of the arrangement client perspective and contractor perspective. I used to do consulting work myself and also I hire contractors to do work for me. Here are few thoughts:
- as a client I need to plan my budget, so I want some certainty. But on the other hand I know that software development is unpredictable and estimates are never accurate.
- as a contractor I want to make sure that when scope of the project changes (and it always does if your approach is agile) I don't need to renegotiate the contract for every small change and I don't want to do work without pay.
So, here are few solutions that I worked out:
- Always go with hourly rate but agree on a total budget and have provisioning for a mechanism for approval of extra work without renegotiating the contract. For example, hourly rate 100/hr with budget of 200 hours. Going above the budget require client approval.
- Always have scope of work attached to the contract and keep a paper trail of all scope changes (i.e. make sure that scope change is communicated by email and not over the phone).
- For larger projects, consider setting milestones and ability to re-adjust them as project is progressing.
- Consider running discovery phase in the beginning of the project to provide a better estimate for the whole.
My previous client quite often reach back to me asking to do more work for them and I usually have a long term support contract in place and I can simply give them an estimate, sign SoW and do the work without much hassle.
If you use agile methodology (it works better if you have a team but general principles apply nevertheless) you can align milestones with your sprints and leave couple of sprints at the end of the project that are tentative. You may or may not bill client for them depending on your progress and your client can account for them in the budget (It will also do miracles to your reputation if you can deliver your project without using those extra sprints ;-).
I would avoid any fixed price jobs, they never go well for neither side unless it is really small job and you can blow up your price.
Retainer is also an option but if you are in Canada it may backfire as tax authorities may interpret it as hidden employment and tax you unfavorably. I'm in Canada, so I naturally avoid retainers.
The bottom line is that it is that scope always changes and you should have an arrangement that gives you and your client the flexibility to adjust it without too much fuss and keep the budget under control.
Hope this helps.
Hourly rate with a minimum number of hours per project. (ex. $100 per hour, minimum 30 hours to be retained as a client.) Yes, beware of scope creep - there is a fine line between wearing lots of hats/being helpful and doing the job for which you are being evaluated and measured by... make sure the scope of responsibility is outlined clearly either way, including value adds.
You don't have to offer all pricing models. As others have said, being able to price by the project has a lot to do with your ability to accurately estimate, and also more importantly to write an exceptionally detailed scope of the project and not deviate from the scope.
A retainer is an amount of money they spend to buy blocks of your time. The assumption is that you are working on multiple assignments, and they want to buy a certain number of hours a week/month, but it will require you being a little flexible with the schedule. The longer the term (month vs. week) the more likely the client is to try and stack work suddenly when they realize they need to burn some hours with you. Typically it includes a minimum number of hours for which they pay up-front, and then a delivery time for work assigned within the budgeted hours, and not often any carry-over to the next week if they don't use their hours. It's like hiring a part-time employee. Up to you whether you allow them to buy any additional hours if they use up their allotment under the retainer.
Your straight hourly rate is usually higher than the retainer rate because there is no guarantee of the number of hours they will give you. The retainer usually gives them a bulk discount, and to get that discount they may also have to agree to a total number of weeks on retainer. Otherwise your hourly rate is very similar to the retainer agreement, but less predictable on your side as to when you'll get requests or how much you can plan for when you'll be busy.
No, don't underbid yourself. Consider discounts for them pre-buying (retainer) blocks of your time, but start with a higher hourly rate because that's where the risk is held on your side.
Also remember that the rate for software development when you deliver them a finished product without source code is much lower than when you deliver the source code as part of the work. Typically by a factor of 3x. Figure out which they're expecting.
One of the disadvantages of hourly for the client besides the higher rate, is that they don't have priority. If you're full before they request work, you're full and they have to wait.
Fixed price work doesn't need to be avoided, but it usually takes a lot of practice and discipline to control customers who want this approach. It leans heavily on your contracted obligations being crystal clear so there are no questions about what happens if...and it's a way for the customer to reduce the risk that the developer is slow and eating up time that a different developer could do faster had they chosen a different provider. If you really know what time it will take you, or you already have snippets of code you can use to get things done more quickly, projects of the same kind can turn into an easy project-based business. But it's not so common that developers are talented in the business-prep parts of doing one-price projects.