I agree. We have many out of states clients, and all were required to
(and have) sign a contract. There are many ways to deliver contracts, you
should not have to risk not getting paid because of delivery logistics.
You can use:
e-mail
fax
fedEx, Ups, or any other delivery systems.
-use Adobe's PDF Writer to convert to contracts to PDF, so clients cannot
change the content.
We've successfully used the following processes:
1) E-mail original contract--> client sign and mail
it back.
2) E-mail original contract--> Client signed and fax it
back to us.
3) E-mail original contract --> Client signed it, scanned the
pages, and e-mail us the scanned pages (in this case, the scanned
images).
We then print the scanner pages, eh voila! A signed contract.
3) For rushed jobs, we've even had clients submit an electronic
agreement/permission, in conjunction with a hard copy. The electronic
letter would state (a) that they've agreed to our terms (b) that the
hard copy is in the mail, and should arrive by a certain date (c) we
have permission to begin development with the prices listed in the contract
(d) If the hard copy is not received within the listed timeline, then
the electronic copy will take precedence over all documents, and they
automatically agree to ALL of our terms. Those that were, and that
were not listed, on the original contact.
{small encouragement to get the original docs in}
Overall, we pretty much have zero tolerance when it comes to contracts. No
contract, no work. Clients have the tendency to want a lot more than
their budgets can support, and they will try to get over the 'little
people'. They also tend to want to change things, late in the development
process. This can give a new definition to the word 'HELL'.
The best way to prevent being cheated, is to have a WRITTEN agreement.
Once that agreement has been signed, stick to it. Do not change any
portion of it, because it will comeback to haunt you.
====On the technology front===
How about this idea?
PHP's FOPEN() function makes it really easy to access remote information.
Suppose, for example, that you leave the application's configuration file
on your server, and have the program access it via FOPEN().
Whenever the program runs, it will need to access the configuration file
on your server, to initial the application's parameters.
if the client doesn't pay, then you simple disable the
configuration file on your server. Since they will not have access to the
configuration file, then they will not be able to change anything.
Plus, changes they make to their own servers (like changing login info)
will not prevent you from controlling the unpaid program.
Once all payments are in, you can transfer the configuration file to their
server.
I haven't tried this, but I've been thinking about it. Just thought I'll
put it out there. The only limitation, AFAIK, is that of FOPEN(). If I
remember correctly, fopen() will not process any codes in the file that
it is opening.
You'll have to work around that.
Just add that to the Idea Bin, it may lead to a better solution.
-john
_+-----------------------------------+_
P E P I E D E S I G N S
www.pepiedesigns.com
"Providing Solutions That Increase Productivity"
-+___________________________________+-
On Wed, 8 May 2002, Jay Blanchard wrote:
> [snip]
> As any good developer out there knows, first you call them "new friends"
> then "clients" and sometimes it goes to "S.O.Bs" and "bast**ds" and the
> worst part for me is I am not in the states but offer services to a lot of
> U.S clients so a actual contract is pretty much out of the question.
> [/snip]
>
> Why is an actual contract out of the question? With FedEx, UPS, Fax
> Machines, postal services of all types, and electronic contracts with
> electronic signatures it shouldn't matter where the programmer is, even if
> it is not the same locale as the client.
>
> Jay
>
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
