[consulting] Drupal web design as hobby - shall I start consulting?

[Larry Garfield]

On Sunday, August 15, 2010 03:19:47 am Alexei Malinovski wrote:
> Larry, thank you for lengthy answer.
> 
> 2010/8/15 Larry Garfield <larry at garfieldtech.com>
> 
> > On Saturday, August 14, 2010 05:19:30 pm Alexei Malinovski wrote:
> If you're doing mostly click-together sites, that's less of an issue.
> 
> 
> What is "click-together sites" ?

Download a couple of modules, built some node types with CCK, configure a 
couple of views, throw a downloaded free theme on top of them... click-click-
click-click...

Mind you, the ability to "click together" 80% of what you need is what makes 
Drupal such a great platform.  You can even get some really amazing 
functionality that way without writing any code, just making clever use of 
existing modules.  That last 20%, however, is what separates a "looks like 
Drupal" site from a finely tuned, custom-themed, customized solution.  It's 
also where most of the time, effort, and money goes in a project.

Now, many many sites don't need that last 20%, or they may think they do but 
really don't.  Part of a consultant's job is to help a client figure out which 
of that 20% they really need, and which they can afford.

A consultant's job is to make the client happy in the end, not to give the 
client what they say they want.  That's a very subtle but important 
distinction. :-)

> "Host and support a site built by someone else" is one of Acquia's main
> > business channels.  They may be out of the price range for your clients,
> > but
> > it's worth considering.  Acquia's Gardens project is also targeted at
> > rapid creation of reasonably conventional sites (I won't say cookie
> > cutter, but less-than-fully-customized) that are hosted on their
> > heavily-tuned infrastructure.  Both are definitely worth looking into.
> 
> Thank you for suggestion! I will look into that. Though, I'm not sure that
> those guys speak Russian :)

I have no idea on that front. :-)

> BTW, do anyone see any problem to make sites without the contracts at all?
> I understand monetary issue - if there is not contract noone will force
> Customer to pay you money for the work. Any other problems with such
> approach?

No guarantee that they'll pay you.

No firm definition of scope means the client can come back and insist on extra 
work and you can't say "that's not what we agreed to" because it's not in 
writing.

No statement that if they lose money or don't make as much money as they 
expected from the site then it's not your fault and they can't sue you.

Really, if you're serious about doing web development you want a contract.  
Even with people you know.  It doesn't have to be a long and complicated 
contract, but even the process of creating it can help convince the client 
(and you) to take it seriously; it also is an ideal time to work out the scope 
and process for the project; do they owe you designs or do you make up the 
design?  Are they going to get to give feedback on design?  How many times?  
Just how much functionality are you building?

Figure that sort of stuff out, put it in a contract, get it signed, then go to 
work.  That way you and the client both know what to expect, which in the end 
makes both of you happier.

Yes, that can sometimes be a non-trivial process.  Roll that fact into your 
hourly rate.

--Larry Garfield