I've been doing freelance programming for over twenty years. For a project to really be successful, it needs at least the following:

1. Somebody who knows the programming, software, and hardware technologies used for deployment - or technologies similar enough to learn the deployment technologies really fast
2. Somebody who knows the problem domain, and is able and willing to translate that into specs the programmer can use. (If the programmer is also the domain expert, and the project is simple enough, the specs can be in their head or informal notes.)
3. Somebody who is able, willing, and experienced at managing the project tasks, timeline, etc. well, and knows the kinds of pitfalls you can get into with things like estimating and how to avoid them
4. Somebody to manage the communications and relationships among all the project stakeholders, including the programmer(s) and customer(s)
5. People on both sides, consultant and client, who are experienced at keeping the ongoing business matters solid, including contracts and money. If you don't have this experience yourself, you can get by with an experienced adviser until you are.
6. An arm's-length business relationship where, if you have to make a tough business decision, you don't have problems outside of work
7. A large-enough team, with the right combination of expertise, tools, and resources, to deliver a quality product within the required timeline

You describe a friend-of-the-family who knows nothing about programming, who wants you - an inexperienced programmer - to build an ERP system using a technology you don't know.

It sounds to me like this situation definitely misses on #1, #3, #6, and #7, and maybe all of them. As Adam says on Mythbusters, "This is a recipe for disaster."

Heck, I wouldn't touch this one with a ten foot pole myself. I could go on and on about the other red flags I see here, but basically, my advice to you is go with your gut feel, because you're right: "nothing really good will come from it."

Since this is a friend of the family, if I were you, I would just say, "You have a great project, and you need somebody really good, and I'm too inexperienced to give you the results you should have," and leave it at that.

I've also found that when you have a client who's a problem in one area, they're likely to be a problem in others. A prospective client who would even consider having an ERP system designed and implemented by a junior programmer is either so ignorant as to be a hazard to themselves and others, or ridiculously cheap, and either of those would put them in my "stay away" list.

I've been doing freelance programming for over twenty years. For a project to really be successful, it needs at least the following:

1. Somebody who knows the programming, software, and hardware technologies used for deployment - or technologies similar enough to learn the deployment technologies really fast
2. Somebody who knows the problem domain, and is able and willing to translate that into specs the programmer can use. (If the programmer is also the domain expert, and the project is simple enough, the specs can be in their head or informal notes.)
3. Somebody who is able, willing, and experienced at managing the project tasks, timeline, etc. well, and knows the kinds of pitfalls you can get into with things like estimating and how to avoid them
4. Somebody to manage the communications and relationships among all the project stakeholders, including the programmer(s) and customer(s)
5. People on both sides, consultant and client, who are experienced at keeping the ongoing business matters solid, including contracts and money. If you don't have this experience yourself, you can get by with an experienced adviser until you are.
6. An arm's-length business relationship where, if you have to make a tough business decision, you don't have problems outside of work
7. A large-enough team, with the right combination of expertise, tools, and resources, to deliver a quality product within the required timeline

You describe a friend-of-the-family who knows nothing about programming, who wants you - an inexperienced programmer - to build an ERP system using a technology you don't know.

It sounds to me like this situation definitely misses on #1, #3, #6, and #7, and maybe all of them. As Adam says on Mythbusters, "This is a recipe for disaster."

Heck, I wouldn't touch this one with a ten foot pole myself. I could go on and on about the other red flags I see here, but basically, my advice to you is go with your gut feel, because you're right: "nothing really good will come from it."

Since this is a friend of the family, if I were you, I would just say, "You have a great project, and you need somebody really good, and I'm too inexperienced to give you the results you should have," and leave it at that.

I've also found that when you have a client who's a problem in one area, they're likely to be a problem in others. A prospective client who would even consider having an ERP system designed and implemented by a junior programmer is either so ignorant as to be a hazard to themselves and others, or ridiculously cheap, and either of those would put them in my "stay away" list.

FWIW, as a consultant/freelancer, I wind up filling the roles on my side myself, with advice from my wife. We've figured out what all those items are by seeing projects fail due to lack of them - sometimes, it's been our own projects. And even after twenty years, and despite checking these criteria, I still wind up with an occasional project that doesn't work out - that risk is always part of being in business. I just make sure now that projects don't fail because of anything I've done wrong, and that contracts are structured so I get paid if the other side screws up.