----- Original Message -----
From: "Tony Schmitz" <tony(at)angelanthony.com>
To: <hwg-business(at)hwg.org>
Sent: Monday, June 24, 2002 12:43 PM
Subject: RE: How to get a client to pay


>
> In a perfect world Ivan's method is the best. Problem is when dealing with
> programming of this nature, developing the app off the server is time
> consuming and not cost effective to the project in many cases.

That really depends.  How much less cost effective is an attorney when your
beautifully crafted app lands in the lap of a judge?

This is not opinion, this is an experience of mine.  Sadly.  Some
interpretations of ownership say that if you have 'released' it to the
client's server, the client has a right to it.  Intellectual property law is
a mine field and good IP attorneys are worth their weight in gold.  We've
got 2 lawyers - one coporporate and an IP specialist and some days they are
my best friends ;)

> We find it much easier to develop "apps" on the server they will be used
on.

There's a reason certain machines are called 'development servers'.  We have
separate development servers running different platforms and the vast
majority of clients host on our machines anyway, so we are intimately
familiar with them. (We develop software as well, so different servers isn't
an option in our case, it's a requirement.)

Now before people argue that multiple dev servers aren't practical for most
shops, I agree.  But even a home-based shop should seriously consider a
cheap desktop that runs some flavor of *NIX (since the vast majority of IPPs
run *NIX), or their own account hosted on a *NIX server and build there.

Porting the app to the final destination and test time should be considered
in the original contract.  Build the time and money in.  One trip to court
costs a heck of a lot more.

Or if it's an account that you host or set up for them, withold the
passwords and access until paid in full.

> For standard development work that doesn't require programming, Ivan is
> right on.
>
> It's a tough spot, I know this has been discussed before and many disagree
> with this method, but we disable our programming when someone doesn't pay.

A slippery slope.  It's not a case of agree or disagree, it's a case of
'what's the law'?

The flip side of the coin is that in addition to your fees owed, you may be
eligible to add 'unjust enrichment' to your claim.  The client knows you
hold that he owes you money, he's not paying it, and meanwhile he's
benefiting from the work that he won't pay for.

> Then we appeal to their nobler motives over, over and over again.
>
> Kind of a killing them with kindness and persistence. Eventually they pay
or
> go out of business.  *shrugs*

Boy, you hit that one right on the head!  For high dollar sites, it might
not be a bad idea to get a few credit references.  Sometimes just asking for
them makes the client sit up and take notice.  New businesses might require
a higher deposit or payment up front.  Explain the statistics to them ;)

And here's a mind blowing thought... don't necessarily take every client
that asks.  <gasp>  If you can't afford not to take them, you definitly
won't be able to afford what happens when you *do* take them! ;-D

These things are even easier applied to new development.  If you're making
additions to an existing site,  slide them a detailed work order and be sure
to include what does or doesn't happen if payment isn't received as agreed.
But even then you have to be sure that whatever you remove does not
substantially cripple the overall application.

We have a policy of mirroring existing sites and doing all additional
development on the mirror because development on active sites is far more
difficult.  Testing while a site is active is asking for trouble.  We demo
how it works, get paid, and then port the changes.

Everyone does what works best for them and if they're lucky, it continues to
work.  I envy those people and wish them continued success.  It seems that
all our policies have been a result of worst-case-scenario thinking and
though the worst cases are few and far between, the policies have saved our
bacon more than once.

/k

-------------
Karin Ransdell  kransdell(at)squishedmosquito.com
Escapade Development Team
Squished Mosquito, Inc.
http://www.squishedmosquito.com  or  http://www.escapade.org
-------------



> __Tony
> ->> TAAG
>
> (wow, my first post to the list...I wonder what took so long?)
>
> -----Original Message-----
> From: owner-hwg-business(at)hwg.org [mailto:owner-hwg-business(at)hwg.org]On
> Behalf Of Ivan Hoffman
> Sent: Monday, June 24, 2002 12:03 PM
> To: David Jourard; hwg-business(at)hwg.org
> Subject: Re: How to get a client to pay
>
>
> At 12:55 PM 6/24/2002 -0500, David Jourard wrote:
> >Hi,
> >
> >I've just completed a large CGI application using Perl.  I took 50% when
I
> >started but now that it is complete and installed on their server
>
>
> You should not be posting anything onto a client's server until you are
> fully paid.  But this issue, and many others, must be covered in a
> thoroughly drafted agreement.
>
> This reply is not legal advice and does not create any attorney client
> relationship.
>
>
>
>
> IVAN HOFFMAN, B.A., J.D.
> Attorney at Law
> Lawyering With Integrity
> Internet Law, Publishing Law, Copyrights, Trademarks, Corporate Training
> and Online Education Law, Web Design Law, Music Law.  *A 6 Times Award
> Winning Site.* http://www.ivanhoffman.com
>
> ---
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.372 / Virus Database: 207 - Release Date: 6/20/2002

HTML: hwg-business mailing list archives, maintained by Webmasters @ IWA