- Mysql is fine for this job, it will take longer for Oracle which is overkill. I've used both and Abigail's comments notwithstanding, I can tell you your choice is fine. I read most of the document she provided and while there are good points there are also a lot of people with great experiences on MySQL and I find much of it outdated FUD particularly with regard to the needs of your project.

- You must have telnet access to stay sane now and in the future, you might need to look at the apache error logs or maybe compile your own perl modules some time. Rackspace is nice, I have not used them but have been very impressed with their responsiveness at night. ssh is better than telnet if you can get it. I recommend linux with RAID 5 disk array.

- Unless you must do clickpath tracking or very high volume accesses, don't use mod_perl on this project. It is a lot of fun but you need to be able to restart the server and it takes a lot longer. There is not a ton of documentation compared to the number of issues that come up with it, so experience is important.

- Don't do credit cards in the beginning. It is complicated and other companies and laws will be involved.

- As for project schedule, you may have trouble on this project if you allow the client to eat up your development time with figuring things out. Development time starts after the spec is signed.

- You need to get a dialogue going and confirm your understanding of what they are saying. The client has to participate in developing a detailed specification, and must also be coopted to promote success of the project by the following activities:

- Signoff on screen mockups and detailed functional descriptions before development

- Signoff on delivery of parts, if you can handle that.

- You make weekly risk assessment reports ( a number 1-10 may be good) and use "that increases risk" and "decreases risk" when new functionality or deadlines are mentioned. The idea is that you do not want to get behind the eight ball trying to defend yourself against an unrealistic deadline from feature creep or some other problem that may crop up.

- Check out some of the ideas of XP programming philosophy, it has old and new ideas and may give you some ammunition if you use some of them.

- It will probably take 2-3 times as long as you think. Keep a schedule with expected man-days per task, including testing on your side, bugfixes, testing on their side, content delivery, whatever. Actually content delivery is in addition to that. The variables you generally have include the number of people on the project, the budget, the time until delivery, the quality/robustness of the code, and the SCOPE. Scope means how much you are going to do. It is easiest usually to change scope so you must get the client involved so they do not make it difficult to change scope.

- There was a very good recommendation above that you look at how your man-days projections match reality and then multiply the difference as a time stretching factor across the entire project. I didn't believe it when I first heard this but it is true.

- Make different phases of the project. The first phase is consulting which you should get paid for, it involves making the spec and figuring out what they want down to screen mockups (line and text is fine). Also a designer is probably going to be involved. Make sure of what you are responsible for, including do you write HTML. Supported browser types may be another thing to make sure of up front.

- The different phases will make it possible to move functionality to a later phase if you need to. Have the client set priorities (no, they can't say 100% or nothing) so that you can identify what core functionality must be perfect by launch, what is best effort, and what is later phase. Then you can get them to put feature creep functions into the next phase, or get them to change other variables like schedule or maybe remove a different function.

- Get feedback as soon as possible from other people in organization so you don't get nailed at the end. Also try to decide as much of the software architecture as early as you can, preferably well before signoff on the spec.

It looks like this is a dangerous project if you don't think of some of the above things. You will have to help your client figure out what he/she wants, and you are only working part time while there is a learning curve for some of the things you will be doing. I would say give yourself a large buffer, start the clock after signoff on the detailed spec, and get the client involved in the process so they can see what will happen if they become unrealistic about things. Don't handicap yourself in the beginning by agreeing to a lump payment at the end (especially if you are meeting milestones and have a consulting report deliverables in the beginning), and if schedule is really important then discuss the possibility of budget changes to add another guy if you really need to at some point.

That's all for now, good luck!