The advantages of continuous build systems are most commonly extolled for multi-developer projects, but they do have some advantages for smaller teams or sole developers.
First lets look at the typical use case: A large project with lots of committers. It's possible that sometimes, the build will be broken. Maybe someone's local environment doesn't match up with the server and they commit code that only compiles on their machine, or someone doesn't check their code compiles because they're in a hurry, or someone's checkout is not up to date when they edit and commit.
Either way, the build is now broken. The bug needs to be fixed, but it's possible it won't be clear who actually caused it, and time is of the essence! As people update to the head, they will no longer have code that compiles, making it harder for them to do work.
Monitoring the status of the build can help avoid many of these events occurring. As soon as the offending code goes into the repo, the build will fail, but they will know immediately so people won't check it out. As it's the current head, it's easier to just revert. Even if people do end up with that code, at least they know who caused it, and which commit it was.
It may even (depending on the speed of the build) be possible to have build checking as a pre-commit hook, stopping bad code ever getting into the central codebase in the first place.
So what does it give smaller teams or lone developers?
Well, it might still be handy to know if the build breaks, depending on what your work practices are like with writing and testing code. In small teams, if there was geographical separation in particular, I can see it being useful to know the build is broken and who when and what broke it.
There are other things you could use it for. If you have it set up, then you have a server that always has a copy of the latest build on it. If the server was web facing, you now have an easy way for people to try out the latest version of your software (e.g. Firefox nightlies and things like that). People outside your project may also be interested in whether the code builds on their platform, or if it passes particular tests.
Finally, take a look at the CI dashboard for Chromium for an idea of what sort of information you can get. We can see the build status on each platform, the commits and what effect they had on that, code coverage statistics, download latest builds, and for a build that failed we can see which test it failed and what the error message was. Pretty cool!
1"So what does it give smaller teams" - I work with two other developers and we use Hudson for CI. It works out pretty well, we have 24 hour builds of our documentation and on-commit builds of our app. It's quite useful for non-developers, they can get the latest documentation or the latest version of our app out to test without bothering us. – ta.speot.is – 2010-12-04T23:45:16.060