Aren't some of you breaking the law by suggesting actual amounts to charge for
specific work?
From: talk-requ...@lists.nyphp.org
Subject: talk Digest, Vol 54, Issue 9
To: talk@lists.nyphp.org
Date: Mon, 4 Apr 2011 12:00:01 -0400
Send talk mailing list submissions to
talk@lists.nyphp.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.nyphp.org/mailman/listinfo/talk
or, via email, send a message with subject or body 'help' to
talk-requ...@lists.nyphp.org
You can reach the person managing the list at
talk-ow...@lists.nyphp.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of talk digest..."
--Forwarded Message Attachment--
From: ere...@totalcreations.com
To: talk@lists.nyphp.org
Date: Sun, 3 Apr 2011 12:22:44 -0400
Subject: Re: [nyphp-talk] How much is a site redesign worth?
Ted you hit the nail on the head, that's pretty much exactly what I do.
ER
-----Original Message-----
From: talk-boun...@lists.nyphp.org [mailto:talk-boun...@lists.nyphp.org] On
Behalf Of tedd
Sent: Sunday, April 03, 2011 10:38 AM
To: NYPHP Talk
Subject: Re: [nyphp-talk] How much is a site redesign worth?
At 3:21 PM -0400 4/2/11, Kristina Anderson wrote:
>$100 an hour is great but in many cases, you're not even approaching
>40 hours or even 20 hours a week in billings. Any programmer should
>be good enough with math to see that consistent billing of 40 hours
>per week and less time spent on marketing is the key to greater
>monthly income.
>
>Kristina
That's exactly right.
Most of my projects are done a "cost for project" basis.
Often I figure out how much time the project will take me and then I
provide the client with a "project cost", which usually looks like a
better deal for them because I *do* charge $100 per hour.
For example, I'm current working on a project that if I spent all my
time (100%) working on it I probably could have it done in two weeks.
That would be $8K at $100 per hour.
However, in this case (which is more often than not) I determined
that the client can't be ready in that length of time -- they simply
don't have the graphics, text, and money. So, I provide a quote
saying I can finish the project within two months at cost of $10k.
That gives them time to get things together and gives me room to fit
their project in to my schedule.
If they come back and negotiate, then I have $2k of wiggle room.
However most of the time, clients jump at the "project cost" for they
feel that two months is much longer than 100 hours so they are
getting something additional. Realize that often it perception and
flexibility that you sell, not programming. In any event, the
arrangement presents a win-win situation -- and that's what you want.
So, when the client has the money, I take 50% up-front and the
remainder when the project is finished. It sounds reasonable to the
client and works most of the time for me.
Now, what I *also* do in these cases is to stay with the client until
they get what they want. This conduct will provide me with favor,
which results in more work from both the client and their friends.
Word of mouth means a lot!
Sometimes, this means spending up to 50% more time than expected
without billing for extras. However, at some point, the client should
come to a realization what the scope of the project was at the
beginning and what it turned into. Most clients realize what "feature
creep" is and you can come to a reasonable solution as to how to deal
with it.
If you run into an unreasonable client (rare), then it's best to take
whatever was outstanding and walk away -- don't do the court thing.
As for an unreasonable example, I had one client who offered to pay
me $50 *per week* until the project was finished as he kept adding
things as if this project was a software buffet. I walked and left
the remaining 50% payment plus the 150% effort on the table. In this
case, I made $33 per hour on a failed project. Not good, but not so
bad either.
The bottom line is to determine what the client wants and work their
needs to your advantage. It may sound like you're taking advantage of
them, but clients seldom understand and often underestimate what you
do and that is taking advantage of you. In the end, work the system
to provide quality service for reasonable pay.
Cheers,
tedd
--
-------
http://sperling.com/
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
--Forwarded Message Attachment--
From: iop...@gmail.com
To: talk@lists.nyphp.org
Date: Sun, 3 Apr 2011 23:30:01 -0400
Subject: Re: [nyphp-talk] Pricing a PHP product
On Sat, Apr 2, 2011 at 3:55 PM, Anthony Papillion <papill...@gmail.com> wrote:
> So since the topic of what to charge per hour seems to be being
> vigoriously discussed, I thought I'd throw something out there that's
> bugged me for a while.
>
> How to price a PHP product.
>
> I'm starting my third PHP product (an appointment reminder for a
> software system I wrote) and I'm having a lot of problems coming up
> with a price. I don't want to set it too low, like I seem to have done
> with my rates, but I don't want to over price it either.
>
> The system is straight PHP, JavaScript, JQuery, and HTML, so it's not
> anything terribly complex but it does provider a nice extension to the
> existing software.
>
> What is the best way to price such software?
Hi Anthony,
This is impossible to answer without intimate knowledge of the product
(and I apologize in advance for saying I don't care to know).
But if the M/O of the product is your typical business application
running as an HTTP service accessed by potentially many clients, then
the low end would probably be around $500 USD. That's about what it
takes to cover the costs of just helping people get setup and
collecting payment. If the product is a little side component like a
plugin for something then you might make it less but your margins in
this case are going to be poor. If you're app is something small and
you're thinking about a price like $100 or less, don't waste your
time. You need to write something that is useful enough to reach that
$500 range. If the application is really good and solves an important
business need, it is not unreasonable to charge $10,000 or an annual
fee of $1500 or so (but my guess is that you're not in this upper
range because it would probably be something that requires a
significant amount of man hours in which case you would have one
product and not three). Again it really depends a lot on what the
product does and how well it does it. If your software is really good
at something, customers will gladly buy it and they will not care much
if it's $200 or $500. Most developers / operators are not paying for
this stuff themselves. They're just doing an evaluation and submitting
a purchase order. You have to get to about $1000 before someone is
going to ask "why?".
And of course customers are going to expect a trial package that
doesn't cost anything. And customers demand options. You must have a
trial version that costs $0. And even after the trial expires I
recommend leaving that installation functional in some limited way. Of
course you can also have a version limited to a certain number of
users say for $300 as opposed to a "platinum" version for $600 or
whatever. I provide a lot of pricing options. I have a separate
"confidential" document for each product that I attach to every sales
email query which describes all of the pricing options about
discounts, the cost of versions limited to a certain number of users,
reseller conditions and so on. You can make a lot more money if the
options are structured well. For example, I have a simple formula (and
corresponding easy to read price table) that increases the discount as
the number of installations goes up. I think this scheme alone has
accounted for significantly larger invoice prices.
Another thing you can do is to make the debut price less than the
ultimate target price to leave room for increases. After a few months
when you have a better idea of who the customer's are, what they want
and the product has matured a little, you can decide to go higher
depending on the software's popularity, the economy, etc. Then when
you do a major revision 2 years later maybe you increase again.
Good luck,
Mike
--Forwarded Message Attachment--
From: m...@atopia.net
To: talk@lists.nyphp.org
Date: Mon, 4 Apr 2011 03:37:04 +0000
Subject: Re: [nyphp-talk] Pricing a PHP product
To sum up my response to Mike, this is why I'm a big believer in Software as a
Service (SaaS). Built it once, sell to many.
-----Original Message-----
From: Michael B Allen <iop...@gmail.com>
Sender: talk-boun...@lists.nyphp.org
Date: Sun, 3 Apr 2011 23:30:01
To: NYPHP Talk<talk@lists.nyphp.org>
Reply-To: NYPHP Talk <talk@lists.nyphp.org>
Subject: Re: [nyphp-talk] Pricing a PHP product
On Sat, Apr 2, 2011 at 3:55 PM, Anthony Papillion <papill...@gmail.com> wrote:
> So since the topic of what to charge per hour seems to be being
> vigoriously discussed, I thought I'd throw something out there that's
> bugged me for a while.
>
> How to price a PHP product.
>
> I'm starting my third PHP product (an appointment reminder for a
> software system I wrote) and I'm having a lot of problems coming up
> with a price. I don't want to set it too low, like I seem to have done
> with my rates, but I don't want to over price it either.
>
> The system is straight PHP, JavaScript, JQuery, and HTML, so it's not
> anything terribly complex but it does provider a nice extension to the
> existing software.
>
> What is the best way to price such software?
Hi Anthony,
This is impossible to answer without intimate knowledge of the product
(and I apologize in advance for saying I don't care to know).
But if the M/O of the product is your typical business application
running as an HTTP service accessed by potentially many clients, then
the low end would probably be around $500 USD. That's about what it
takes to cover the costs of just helping people get setup and
collecting payment. If the product is a little side component like a
plugin for something then you might make it less but your margins in
this case are going to be poor. If you're app is something small and
you're thinking about a price like $100 or less, don't waste your
time. You need to write something that is useful enough to reach that
$500 range. If the application is really good and solves an important
business need, it is not unreasonable to charge $10,000 or an annual
fee of $1500 or so (but my guess is that you're not in this upper
range because it would probably be something that requires a
significant amount of man hours in which case you would have one
product and not three). Again it really depends a lot on what the
product does and how well it does it. If your software is really good
at something, customers will gladly buy it and they will not care much
if it's $200 or $500. Most developers / operators are not paying for
this stuff themselves. They're just doing an evaluation and submitting
a purchase order. You have to get to about $1000 before someone is
going to ask "why?".
And of course customers are going to expect a trial package that
doesn't cost anything. And customers demand options. You must have a
trial version that costs $0. And even after the trial expires I
recommend leaving that installation functional in some limited way. Of
course you can also have a version limited to a certain number of
users say for $300 as opposed to a "platinum" version for $600 or
whatever. I provide a lot of pricing options. I have a separate
"confidential" document for each product that I attach to every sales
email query which describes all of the pricing options about
discounts, the cost of versions limited to a certain number of users,
reseller conditions and so on. You can make a lot more money if the
options are structured well. For example, I have a simple formula (and
corresponding easy to read price table) that increases the discount as
the number of installations goes up. I think this scheme alone has
accounted for significantly larger invoice prices.
Another thing you can do is to make the debut price less than the
ultimate target price to leave room for increases. After a few months
when you have a better idea of who the customer's are, what they want
and the product has matured a little, you can decide to go higher
depending on the software's popularity, the economy, etc. Then when
you do a major revision 2 years later maybe you increase again.
Good luck,
Mike
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
_______________________________________________
New York PHP Users Group Community Talk Mailing List
http://lists.nyphp.org/mailman/listinfo/talk
http://www.nyphp.org/Show-Participation
