So that leaves hourly or by the project (not mentioned). Personally, I
like to do it by the project, although I am probably a minority in my
preference. By the project gives the client a nice set price. However,
the scope has to be extremely well defined. It should be anyway, but
more so if charging by the project. I then charge by the hour for
requests outside the original scope, which happens all the time. It also
keeps them in check on their requests. Depending on the client, I
require a third or half up front for a project.
Ditto, Ditto and Ditto


Find a contractor or find a contract at

----- Original Message -----
From: "Chris Wesley" <[EMAIL PROTECTED]>
To: "php-gen" <[EMAIL PROTECTED]>
Cc: "Gerard Samuel" <[EMAIL PROTECTED]>
Sent: Thursday, July 25, 2002 12:45 PM
Subject: Re: [PHP] Paying Job...

> On Thu, 25 Jul 2002, Gerard Samuel wrote:
> > Do you charge by the page, script or by the hour (that would be nice).
> It's a tough thing to do, but consider charging by the project.  You'll
> find a most equitable payment/compensation when you establish up front how
> valuable the project is to the client, and how valuable your time and
> services are.  I find this is the best way to put a client at ease [(s)he
> knows what (s)he's paying ... no surprises, unless they're
> client-inspired], and you can concentrate on the project instead of how to
> make the site fit into X pages or how to justify or fit the project into Y
> hours.
> Get a couple small projects under your belt, just for the learning
> experience, and you'll get a good feel for a process that suits your
> needs.
> Things I did to get become acquainted with a good process:
> - did small projects for free, just to prove (to the client and myself)
>   that my code and I can survive
> - did small projects for an undervalued price to get my foot in the door
>   of potential future paying clients, to build a decent portfolio, and to
>   assemble a good list references
> - did projects just because I love to code and solve problems, not for the
>   cash.  (YMMV.  There are a myriad of reasons I employ this philosophy,
>   that I won't preach about here.)
> Typically what I try to establish up front:
> - the total project specs
> - terms on deliverable(s) (how many stages a project is divided into)
> - a reasonable estimated time of delivery for each stage, and the project
>   as a whole
> - documentation requirements
> - feature-creep clauses (it's such a pain to have the project change
>   in mid-development ... you have to watch your own back for this.)
> - maintenance requirements (to fix bugs for X number of days/months after
>   delivery ... NOT FOR ADDING FEATURES: do that in separate projects)
> - compensation/fees
> - payment terms (25% upon delivery of stage1, 100% by stage3, etc.)
> For FREE projects ... just leave off the last two points.  Even though a
> project may be done pro bono, it should still be relatively chaos-free.
> A chaotic project done for free will probably just end up being a waste of
> time for your client, and mostly for you.
> g.luck,
>         ~Chris
> --
> PHP General Mailing List (
> To unsubscribe, visit:

PHP General Mailing List (
To unsubscribe, visit:

Reply via email to