

Myth of the Flat Fee - roytomeij
http://www.80beans.com/nl/blog/2011/05/25/myth-of-the-flat-fee

======
dasil003
Of course this is a good message to send to big clients with big projects who
merely "don't get it". On the other hand, there are a _lot_ of small
businesses and other clients with very limited means who have maybe
$1000-$10000 for a project. Web development is new territory for them, and
they have no other way to approach the problem other than to put a fixed-
budget stake in the ground, and of course their requirements are going to
evolve as they learn.

One of the reasons I joined a startup was because I was sick of working under
those conditions, and writing an FU blog post like this is the luxury afforded
to those of us who can more or less pick what we want to work on.

That's great, but there is still a pool of small clients who can be
profitable, but you have to understand how to work with them:

\- Learn to use off-the-shelf software to build lots of functionality quickly
in a predictable fashion (WordPress, Drupal, Expression Engine).

\- Charge a flat fee only for something you've done before, and make sure it
has padding. It's not unethical (as suggested by another commenter) because
this is how you are able to afford a flat fee. You'll be churning out hundreds
of these so you need to work the law of averages. This allows you to be a bit
accommodating instead of going into conflict mode every single time.

\- Turn your creativity to your own systems. Face it, on a $5000 budget you
are not going to do anything revolutionary for a client. You can however build
your own systems that you leverage in order to serve a hundred clients better.
Do it well enough and you actually build a business that scales better than
top creative agencies working on 6-figure budgets.

\- Be customer-service oriented. Face it, someone paying you $1000 a year is
just not very important to you and it's easy to let that attitude show. The
thing I've found is that small clients actually are more accommodating than
big clients as long as treat them with respect. That said...

\- Dump toxic clients. There are always those with unreasonable expectations
and no respect for what you do. The worst is when they are sort of borderline
stringing you along, but you end up losing time and money over the long haul.
How you get rid of them is a matter of tact; maybe you say you are all booked,
maybe you raise your rates for them to an exhorbitant level, maybe you just
give it to them straight ("I am not profiting from having you as a client"). I
don't have a one-size-fits-all solution, but get rid of them you must.

~~~
raganwald

      Learn to use off-the-shelf software to build lots of
      functionality quickly in a predictable fashion 
      (WordPress, Drupal, Expression Engine)
    

Bravo. This is the way I look at it: if it has been done before, somebody,
somewhere has productized it. If it isn't a full-blown CMS, it's a bundle of
Rails plugins and all I'm doing is writing glue code.

If it hasn't been done before, because it's really specific to a client's
domain and idiosyncratic processes, it's R&D and we shouldn't pretend we know
how to do it with enough rigor to provide a competitive quote.

In many cases, the problem is that it has been done before, buut the client
doesn't want to "colour within the lines" and run with the limitations of an
existing CMS or other platform, they want a bunch of customizations that have
little or no ROI.

The Big Sell in those cases is convincing them to scale back their
expectations about customization and live with having the 20% of the features
baked into the off-the-shelf system that deliver 80% of the ROI. Even if they
want to pay by the hour, it's not a good investment to build what amounts to
business chrome.

~~~
dasil003
Interesting tangent to this, after doing PHP from 2000 to 2005, I hopped on
the Rails bandwagon full-bore and was using it even for small clients. 6 years
later I feel that it was a bit self-serving because those old Rails sites are
creaky and painful to upgrade—or even to find someone else to work on—compared
to my PHP sites from the same era.

Now that I have ample outlet for my creativity I can be a bit more objective
and admit that as much as I love Rails, it's a terrible platform for build-it-
and-forget-it. Rails shines for core business apps under continuous evolution.

~~~
rhizome
What do you consider to be a good "build-it-and-forget-it" platform?

~~~
dasil003
PHP, Java, Cobol? It's all relative I suppose.

~~~
endtime
You're recommending COBOL as more maintainable than Rails? I don't know Rails,
but I find this very hard to believe.

~~~
dasil003
Where did I say maintainable? This is about stability over time.

~~~
endtime
>creaky and painful to upgrade—or even to find someone else to work on

What do you mean by maintenance, if not that?

------
mgkimsal
I've got myself stuck in a "fixed price" contract, and while the number of
features the client's asked for haven't really increased all that much, the
depth of interrelation between those features was not at all apparent up
front. Throw in agreeing to migrate existing data in to a new data structure
without _really_ understanding the nature and complexity of the existing data,
and you've got a recipe for a long-overdue project. No one's happy. :/

~~~
PaulHoule
Oh yeah, you can easily bill a month of full-time work for fixing an old app
with a busted data model. After that you reach the place where you can sell a
change that takes 30 minutes of work for $150 and really do it in 30 minutes,
but getting there is expensive...

~~~
mgkimsal
I'm at the point now where the time invested in the project has paid off - I
understand the business problems much better now, and some of the intricate
work I did months ago is paying off in spades (basically, having put together
a flexible data model up front). Things that might have taken days to do
before I can do and redo in minutes or hours. But it's taken way too long to
get here, and ultimately this is a one-off - most of the knowledge gained
isn't transferable to any other projects directly.

------
amosson
A few large consulting companies in the 90's, Cambridge Technology Partners
and Viant, for example, were very successful with this model. They were
selling against the $100-200/hr Big 6 type consulting firm so there was plenty
of room budget for the "risk" associated with going over the time estimate.
The other key to their success was getting the client to agree to pay for an
upfront 'spec'ing' phase before bidding on the development work. If you do the
spec'ing phase correctly you can give a fairly good bid on development and
truly assess what is in scope and what is a change order.

------
raganwald
"Lies, damned lies, and software development estimates:"

[http://weblog.raganwald.com/2007/06/which-theory-first-
evide...](http://weblog.raganwald.com/2007/06/which-theory-first-
evidence.html)

------
jtbigwoo
The flat fee game the OP describes is pretty much standard operating procedure
even for big consulting companies like IBM and Accenture. First they agree to
a flat fee (sometimes after a bit of requirements exploration) that cuts their
margin for error fairly close. Then, after the work has gone down the road a
bit, they bury the client under a blizzard of change requests for every last
detail that wasn't documented in the initial requirements. The change requests
are where the real money is made for consulting companies, especially if
they're getting their employees to work unpaid overtime to fulfill the extra
requirements.

------
nickburdick
I think this statement is extremely poignant, "Because you're looking for a
sense of security when you're spending your budget on a web app". I think a
big problem is lack of knowledge on the part of the client. Most people just
have no idea what it takes to build web apps. $1000 (or even $5000) just
doesn't go very far. But without learning and experience on the customer's
side, how are they able to bound the project to understand the potential
costs?

~~~
roytomeij
I should maybe have indicated that the clients we're talking to usually have
between $20,000 and $70,000 to spend. They employ people who're expected to be
experienced.

------
wccrawford
This issue is why I'm not a contractor. I can't deal with estimates because
they are always wrong. People claim to understand that, then fly off the
handle when it comes up wrong.

Overestimating on purpose isn't the right way either, and not just for ethical
reasons. Finishing early makes the client think you cheated them, and actually
working the whole time makes you think you cheated yourself. Especially if you
end up having underestimated after all.

And changes? Ugh. Clients truly don't understand why X is harder than Y, and
they think it should cost the same.

I've been pretty successful in the past at guiding management into solutions
that are easy to code and maintain, rather than the nightmare they asked for,
but having to explain all that to a new client each time would be too much.

~~~
roytomeij
I completely agree. It's tiresome to repeat yourself over and over, specially
when you know it's also in the clients' best interest to not work with someone
who guesses (and therefore often overestimates to be on the safe side). I'm
hoping our prospective clients will read this blog post first and then -still-
want to contact us. They are the gems you want to work with.

~~~
PaulHoule
To be fair there definitely are people who get burned several times by
eLancers and cut-rate web shops in their town and eventually realize that they
get what they pay for.

------
rakkhi
Amazing how often this happens to even large corporations. Sign a very
expensive contract with a supplier at a "flat fixed fee", requirements are
never detailed enough and always changing. Much better off paying time and
materials or create a partnership where both benefit from the outcome

