Fixed vs Hourly Billing
Discussions center on strategies for pricing software development projects, debating fixed-price contracts versus hourly billing, scope creep management, and client negotiation tactics.
Activity Over Time
Top Contributors
Keywords
Sample Comments
Do NOT bill by the hour. Bill the project as a fixed cost to get your foot in the door, but with a clause to switch to hourly for changes requested that stray from the original requirements, with a two hour minimum per change.The pain of being billed hourly will discourage clients from requesting too many trivial changes.
We have a different approach. If the customer wants a fixed scope and price, we make an estimate (considering both our internal cost, and the value of the work for the customer) then double the price.They usually do not accept and want it cheaper. Then we offer the project at the estimate and to split any difference. So if we use 1 hour less at 200$/h, they get it 100$ cheaper. However, if the project ends up taking 1 hour more it will only be 100$ more for the customer.I really would
I usually do fixed cost projects unless projects are so ill defined to require by the hour billing. Your advice is my advice but unfortunately customers are not so out of touch with reality. If they expect the project to be done in 2 weeks they'll start negotiating from 2,000 and If I can do it in two weeks they won't expect more than one month.
The customer wants you to commit. When you say "let's do a week at a time", the customer does a mental calculation of what one week of your time is worth if the project doesn't complete, arrives at the number $0, and responds accordingly.That doesn't mean you work a fixed-price gig. It does mean that you give serious thought to a conservative estimate of the whole gig and then confidently offer that as your price for the engagement.
I usually spend an hour or two for free with the client, unless I feel they are not serious about it. If I assess studing the project will take more time, I give them a flat rate for it. It's my job to assess how long it will take, then use my daily rate to give the total.I always include an escape clause in the contract in case they forgot to mention something very important that change drastically the price.I also never quote the entire project, only the first deliverables. Then rol
What I meant exactly is, give an estimate and an hour quote. Let the client know that if you complete the project in less time, you will charge less and vice versa. I've found that in all projects specs change and things take less or more time than estimated. Nothing sucks more than working free because you underestimated a task. Also if you have a fixed price, you will invariantly be motivated to take the quick and dirty solutions everytime. This will not lead to success for the project.
I provide an initial estimate. Very high level but enough to give them the idea.If they want details I tell them I need to bill for the time and file it under project planning. Amazingly they are happy to pay for it and we are happy to do the paperwork they require.If they say no they wonβt pay then you make a judgment call on how important that client is to you. What I have found is if they nickel and dime you then your not providing value in their eyes. Move on to a higher value client.
2 Things:I always charge 25% up front (in case they cancel halfway through, or just take forever to get started).Once the project is done, maintenance is always hourly with a 1 hour minimum. Even if it only takes 5-10 minutes, the bill will be for an hour. As long as you are upfront about this, it will give them incentive to batch the changes into groups, and also make it so you're not taking 5 minutes out of every day to do some minor change.There are the hidden costs that clients don'
Charging fixed price per whole project might not be a good idea. Software projects usually never finish completely in a certain predefined deadline so it makes it very hard for you to plan and price your services.There will always be issues that will delay the project that you couldn't have predicted and priced in at the start, requirements will often change during the project, there can be new feature requests which will further push the deadline.Much better to instead sign a contrac
Per project is dangerous. Consulting clients will change their minds frequently and you'll want to give them the latitude to do so, which means you simply can't estimate the time needed to complete a project without adding X00% on top to compensate. No one wants to have the "this is out of scope, I'm happy to do it but we need to talk about an amendment..." conversation.Per hour is not adequate for this type of work; you're delivering a product or service that wi