Some people have gotten confused about what CI Factory is and is not: I use it as a platform. Yes, you can use it as a canned solution. However I have found that shortly after you get it up and running the requests start rolling in for more. Hey, can you add this to the zip? Can you add a second zip? Can you manage the developers databases with it? Can you deploy to the testers environment? Can you publish to the release area? Not to mention all the requests for additional private build script functionality.
I use it as a boost to get that much further than if I was going to set up all that stuff manually. I lean on the structure and naming convention to allow me to move scripts and snippets from one factory to another without much if any fuss. For the most part moving a script snippet will just work. In fact I was hoping that this type of portability would allow people to share in smaller units than a Package. I have already taken advantage of this portability to help diagnose issues reported in the user group. I send a snippet, ask the user to run it, and they send me back the output. It has helped immensely.
At my day job we used it to create a ultra fast developer facing build, a reset button heavy build, a release build, and most recently a release management area build. We plan to add a heavy test build next month. Some of my current work deals with DotNetNuke, creating web part zips, and packaging a site.
Last comment on this subject. Some people see that there is too much going on, there are too many Packages, especially the Kitchen Sink Package. The Packages are like a buffet. Are your eyes bigger than your stomach? The release management area build that we just setup only has the Subversion and CSDiff Packages with a little bit of custom scripting. You can make a lite factory.