However, I think you're asking the wrong question. Don't ask "What happens if I deliver a crappy product?"

Instead, ask "How can I make absolutely certain that I will deliver a product that the client is pleased about?"

You won't get it right all the time, especially not at the beginning, but you'll find that in general that's most to do with your ability to manage client expectations than with your coding skills, so don't worry about delivering a crappy product - instead worry about managing client expectations so they're never negatively surprised by what you deliver.

In short (to be blunt): Don't promise what you can't deliver.

perhaps a better takeaway is to learn to deliver what you promise (and learn to promise what you know you can learn to deliver).

Either way, you can often land the project (at a slightly lower rate) by being upfront with the client about the fact that it will be a learning process for you. Which comes full circle to properly managing client expectations.

I love to tell people that the hardest parts about writing software have nothing to do with code. It all has to do with communication.

Also, there will always be risk that you will deliver a crappy product because your client did something that made it that way (eg "but we MUST have .Net ASP on the front end talking to a PHP back-end and ONLY using flatfiles") - that's a constant regardless of your degree of familiarity with a given technology or problem space (you can mitigate that in other ways but that's beyond scope here I think).

Take stock of what it is that you are comfortable working on:

* Technologies you have clearly demonstrable capabilities

* Problem spaces you have worked in before

* Areas you have researched

Now extrapolate by one degree - eg so if you are familiar working with Hadoop you probably could set up and use Cassandra if you needed to. But to say you have experience setting up a massively scaled and redundant data warehousing operation would be too far.

If you have built mainly consumer focused apps you might feel comfortable trying a social network app, but jumping into financial software might be too far.

etc.

Now with the above market clearly the technologies and spaces you have experience in and don't be afraid to take on jobs that exist in the "1 degree apart" space - but be cautious of anything that falls outside of that.

Sorry if this is a long windy reply - I've spent the last 5 years consulting and the above is my basic methodology for this.

Pick projects that will leave you with a clearly demonstrable experience of a marketable technology (eg Node.JS is cool but difficult to find wide market interest at this time).

But only do this if you have time between gigs - always take a gig over a project because you will always gain some kind of experience from any gig, in addition to getting paid.

You could also try structuring your work and charging methods so you have a week or two of lower-paid 'research' at the start of the job to really figure out if you can execute or if it's something you should leave well alone. Once you have a client waiting and are in the swing of things, though, the ability to execute is somehow higher :)

The key with consulting is to always communicate with your client, let them know where you are and how much more work you think you have. Be honest about how you feel about the quality of it as well, a good client with work with you and help you deliver a great product.

Do research, learn, talk to people who have done it before, manage client expectations. Best of luck -

The thing is if you're a bit smart and know how to code, there's very little you probably can't do. The question is how long will it take you to figure out how to do it. You will much more likely be wondering whether you are doing it right.

So now its a question usually of scheduling. When you start getting in doubt about your ability to deliver on time, thats the time to raise your concerns. Tell them you might need to bring someone else on, maybe you can do this on budget or maybe you might have to eat some hours for free. Again its not perfect but if I hired someone like you and they went that route - I'm pretty okay with that, and I'm going to respect your honesty. Also if you're setting schedule make sure you build some buffer time in, and try to avoid projects with super hard and fast delivery dates.

Some people may flip out, but if you manage to keep them as close to on time and on budget as possible thats okay.

A third alternative is to reduce the scope to something you can finish. 37signals advocates compromising on scope but never on deadline, and I agree.

Any of those options would be fine. What's important is that you keep the client in the loop so that they can find another developer if they need to, before the project is 2 months late with no end in sight.

As a corollary, be upfront about your skillset, and don't take jobs you know you can't finish. As with anything, lying will bite you in the ass.

This lets me give a more realistic estimate for completion and cost. If the customer wants too much more or doesn't like my cost estimate, we're both better off knowing earlier than later.

Bad Consequences? You can get a reputation of being promiscuous (or worse) if you handle things poorly. People can find out you're not a good kisser, you're not good in bed, you're unreliable, you're cheap, etc. Or they can find out that you're responsible, you try hard, you're willing to give it all you got, you're romantic, etc.

The only risk I see is "is this girl worth my time to pursue?" There are 6 billion people in the world and only one you. Your time is limited, potential clients are not.

For example, I was requested to quote for a project that had to use Joomla for a certain type of website (well, it was Facebook and a document management system). That was enough to ring alarm bells and steer away from it.

But if you try at all, you might find that in the real world the bar is actually pretty low. Just being able to deliver anything at all is the first step!

You won't be able to say "No" until you've said "Yes" and failed.

Just try it, if you suck, move on, or try to improve, but you'll never know otherwise.