What payment structure do you use for small projects?

Question

What payment schedule do you use for small projects (e.g. < $10,000)?

This is the structure I use:

• 20% deposit before any work starts
• 70% payment when project gets to 90% completion (I know this based on the project schedule)
• 10% final payment on acceptance document sign-off

So, for example, on a $1,000 project:

• Payment 1: $200 (deposit)
• Payment 2: $560 (70% of the remaining project value, which is $800 after deposit)
• Payment 3: $240 (final payment)

I have seen a few other structures at companies I've worked at. At one company, they decided on a 50% deposit, and 50% on project completion. Another company used a 20% deposit, 75% milestone payment, and remaining 5% on project completion.

What Payment structure do you use, and why?

Answer 1

I typically do 25 deposit, 50 on milestone, and 25 upon completion. If the client isn't comfortable with that, I sometimes offer 33/33/33. I haven't really had a problem with either payment structure. As long as there's incremental payments, both the client and the developer are protected fairly well. Never write a line of code until you get a decent sized deposit. (>=20%) Plenty of people starting out complete a project to a T of the spec, only to have a fickle buyer decide he doesn't want it anymore. A deposit protects you from this.

The real problem for me, as of late, has been consultations. The amount of time I've been putting into dealing with potential clients has been, on average, equal to the amount of time I've actually been writing billed code. I think it's come to the point where I might have to charge for consultations. Maybe something along the lines of billing time for anything more than 30 minutes of chat. Anyone have any experience with this?

Answer 2

Normally, my billing rate is as follows:

Consultation/Planning/Design: 35%
Construction - Design to Prototype: 35%
Prototype - Completion: 30%

Maintenance is done on a 'per hour' basis. If a Bug crops up less than 3 months after the product is delivered, I'll fix it 'for free'; post 3 months I charge by the hour.

I use this billing structure for smaller projects because a) It gives the customer peice of mind that they can still hold out nearly 1/3rd of payment until the end, b) It gives me enough to get started and and still make a pretty penny even if they drop out after the prototype c) If they decide to use the prototype, I get paid the other 30% and effectively have the next three months to finish the project (see? I budgeted for it).

Yes, it preys on their "Oooh, let's use the prototype" mentality; and allows me to see the product in use to tweak it. After that, since it's 'by the hour', it is an incentive for them to either consider it 'feature complete', or to re-sign a contract for more work.

Answer 3

interesting, im seeing a lot of 1/3 x 3. i can see the benefit of this.

33% deposit is quite large (i.e. more then the 20% i normally do), which is good because it gets you more cash flow sooner. but its not so big that it would appear ridiculous to a client.

also, i can see that a client would appreciate a 1/3 final payment because they arent being hit with a massive chunk of the project cost at any one point (i do a 70% value hit, but i know some do a 20% deposit, then 80% on completion <- that 80% is just asking for billing delays from a client).

Gortok - i had a question about your structure. are you saying that at your 'Prototype - Completion' stage, you take the remaining 1/3 portion of the project cost before youve completed the clients work?

RE: post-launch bug fixing (or software warranty), i normally do a 6 month bug fixing period. i have noticed that most bugs will show up within the first month or two, so saying 6 months isnt much different to saying 3 (kind of like gmail with 1 GB vs 2 GB - most users will never go over 1 GB, but 2 GB sounds more generous). i also know of one developer who does unlimited bug fixes.

as far as maintenance rates, im trying out a system i developed called 'maintenance blocks' (http://pm4web.blogspot.com/2008/09/maintenance-blocks-dealing-with-client.html). i still need more time to see how it pans out though.

EDIT: i forgot to say, the 33% final payment does have a flaw. i have seen a few projects now get held up for months through no fault of my own because of the client dragging their feet. a classic example of this is with public websites where the client takes ages to provide their content, or with shopping sites where the client takes months to provide you with an Excel list of their products for you to import for them. in this situation, i dont see why i as a developer should suffer when i have completed all my work, but because the client hasnt done what they need to, they dont consider the project complete. hence the 10% final payment which isnt a big deal to have 'held to ransom'

Answer 4

My overall billing pattern depends on natural milestones, that would serve as a point to bill the customer. But I don't have these that frequently in small projects,

I'm usually asking for 80 % on completion (might be in multiple chunks) and 20 % two months after that if the customer is satisfied. If they are not satisfied the are obliged to half a page of reasoning which will not be "judged" - e.g. either they pay the missing amount or they deliver a (any) reason why they are not satisfied in order to provide opportunities to do it better next time.

The reason for this is, that - with any contract - I'm asking the customer to trust me that I can do what they ask me to. This way I assert with my own money my own committment to not only be able to do it in some way, but to do it to their satisfaction.

If you find that their reasoning is bogus and they are gaming you, you're free to not take any more contracts from them. If you find the reason is valid, you prove that you care for delivering perfect service and you're not loosing that much money. This can also provide reasoning for higher rates: They could be charged the low rates that your competitors charge, if the work is done badly. Otherwise you assert that they get their value.

Answer 5

I don't ask for a deposit from long standing customers. I view the purpose of the deposit as part of formation a contract so anything will do - 10-20% seems like a good number.

For new projects, discussions over coffee/lunch are free. Beyond that it's chargeable. I break the project into phases. Phase one is the scoping and initial specification and I do this on an hourly rate. Subsequent phases are either hourly or fixed fee depending on what the customer wants. I make it clear to the customer that they can stop at the end of any phase if they want and try to structure it so the customer feels in control of the development process.

For any project longer than a month, I bill either the hours or estimated % complete on a monthly basis. This is good for your cashflow and also gives the customer some flexibility to delay your project if they have have work on something else, without you nagging them.

Don't generally do an explicit sign-off payment, but put a tight time-frame on sign-off so completion and sign-off are essentially rolled together.

Whatever the arrangement, I try to ensure that something of value is delivered to the customer with each bill so that the sense progress is tangible.

Beyond that I, structure it on a case-by-case basis to make sure everyone is comfortable with the arrangement.

Answer 6

RE: deposits

John McC, what youve said is great, but your deposit thing is a sticking point for me.

i do understand what you are saying - you have built trust with a client over time, so a deposit isnt as important.

i agree with this, but what i do is still require a deposit from a long standing clients, but i begin work before the deposit arrives.

this demonstrates to the client that the deposit is just a formality, that there is good will in that youve started their work already and trust them to do the right thing.

Answer 7

This is going to depend an awful lot on how you work. At Without, we do everything by-the-hour, and don't do fixed-price contracts. We invoice weekly, and expect payment to be made promptly.

The best thing about this kind of work is that it scales to larger, longer and bigger-budget projects without having to worry about progress payments or deposits. It also allows us to work on-demand, getting something bare-bones working quickly, then adding features and general improvements as money becomes available from the client.

For fixed-price contracts, you're going to get variations of three-payments: a deposit, a progress payment (or several, depending on the scope of the project), and a final payment on delivery. The amounts will vary, depending on how much risk each party is willing to take. Some companies will be willing to pony up 50% or more up front, while most will be somewhere between 15% and 25%. The numbers will vary, but the general structure won't.

Answer 8

half in advance, balance on completion - this is for very short-term projects, on the order of a few days to a couple of weeks; any longer than that, and its weekly invoicing with net zero payment

reasoning: if i give your project top attention, i expect to be paid promptly on delivery, or reliably for the duration

Answer 9

We believe the best Payment structure is a milestone based structure. Whether the project is large or small, it makes a lot of sense to define it in terms of quantifiable milestones. These milestones will differ for the kind of the project undertaken and the technology being used.

A typical approach to define the milestones is to do it on the basis of the SDLC, ie break the project into stages like

1. Requirements gathering and analysis
2. UI Design
3. Technical Design
4. Development
5. Testing
6. Deployment/Delivery

Each stage may have well defined entry and exit criteria to ensure objectivity. Saying that the exit criteria to get out of testing phase is 2 non critical bugs remaining open is much more meaningful than saying project is 70% complete

The payment structure can be linked to these stages, with a cut off date for each stage to eliminate the possibility of either party delaying the project. For example, if the completion of development is scheduled for a certain date, a cut off date for a week later might be set. This will ensure that the provider is paid by the cutoff date even if the milestone has not been mutually signed off. This acts as an incentive to the client to ensure timely dissemination of data to the provider.

Similarly for new technologies where there is a chance of getting stuck because of lack of documentation or support, there can be a time bound or effort biund milestone structure.

Answer 10

This always depends on the client/customer for me. If its someone I haven't worked with in the past I bill 50% before project start, 25% half way through and 25% on completion. That way you always have a carrot on the stick until the project is out the door and the customer is invested in seeing that the project is completed.

However customers I've worked with often in the past can wait till the end of the project because of our past relationship and business experience.

Always make sure you are covering your interest and not attempting to be charitable to get a client to sign on.

I know we are programmers but be practical when it comes to business. It doesn't require an infinite number of rules set in stone on how you operate. I find the more flexible you are with existing customers the more repeat business you will receive.

Answer 11

It depends on the project. Often, a project will be completely useless unless it is fully finished. In this case it makes no sense, from the buyer's perspective, to pay 33% up-front and 33% for a milestone, since if the developer then decides to drop out you're left with something with zero value. You might be able to rescue the code he's already written and give it to somebody else, but it's likely more efficient for the next contractor to just start over (depending, once again, on the project). Maybe you can give 10-20% as a consultation, since the design might be re-usable.

For projects where milestones are actually usable, I'd say try to figure out how much that % of the project would be worth compared to the total project, and set up payment accordingly.

Overall, I agree with Syntax: "I find the more flexible you are with existing customers the more repeat business you will receive."

Answer 12

The company I work for use various % and milestones to set pay points as discussed in earlier replies. Changes to our normal payment times (30 days after invoice) are frequently requested, if they ask for anything else then be sure they stick to it. In general I find the middle payment points move as the scope changes. You must define rules for the final payment as many clients get side tracked once your product is delivered. Unfortunately we've had to resort to withholding source code or licenses if the final payment doesn't arrive.

Answer 13

Half up front, half later. Easier that way.