The recommended practice for adding items to a sharepoint site is to use features.
One useful technique is to create a feature with an activation receiver.
When you install and activate this you can do whatever you like to the site in code.

The problem is keeping track of what you have done (and did it work).
I would recommend creating a private announcement list that the installer feature writes to.
This makes it easy to check that the install has worked (especially in a SOX environment where you won’t be the one running the script).

Sharepoint contains it’s own schededuler (similar to Cron).

Here is an article detailing some of the parameters.

I have been investigating creating custom content types in Sharepoint and basing lists off of them.
I have been working with the feature xml documents.

There is an insideous bug that you need to be aware of: the name and the guid for a custom field must both be unique.
If you reuse the name of a field when creating a custom type then when the type is activated the duplicate field will be silently dropped – no warnings or errors.  This took me a day to track down – I was wondering why the view that I built on a list was missing some columns. When I checked these were thecolumns that I had used in an earlier prototype.

There is another catch – you may need to recycle the app pool between un-registering and re-registering features.  Sharepoint seems to prefer to use the cached values rather than the newly supplied ones.

The above was exasperated by the substandard documentation supplied with the product.  While there is lots to read, it is incomplete and contains errors.

It appears that Sharepoint 2007 was realeased too soon – the internal design is not consistent (three styles of guid are required to register a content type!), the error handling is patchy – varies from excellent (exactly which field is incorrect) to vague (a field is wrong somewhere).