Some of the alternatives are:
Manual/Home-grown Builds: Creating a build process from scratch is not much fun, tends to be error-prone, and is usually a waste of time and money.
Batch Files: A poor choice for automating builds because it's cumbersome to implement error handling, doesn't provide easy status and logging, and there is no simple way to continue from an error after correcting the problem.
Make Files: While make files serve a useful purpose in many builds, they tend to be arcane and cryptic and are not well-suited for managing the entire build process.
Script Languages like Perl, PowerShell, and VBScript can be used to automate many tasks, but they require writing a lot of custom code, don't provide a framework for displaying build progress, logging tool output, or stopping and resuming from error conditions.

Save time and money - Automating your builds with Visual Build can save many hours of manual effort every month and easily pay for itself in the first month alone.
Improve product quality - By implementing a regular build process, your team's software quality will improve and bugs will be found and repaired more quickly.
Avoid boring jobs - Visual Build performs the menial, repetitive tasks so you can focus on the fun, challenging stuff. Its intuitive, full-featured GUI interface makes creating, debugging, and managing builds enjoyable.
Eliminate key-person dependencies - "Tribal knowledge" about the build procedure (often kept only in people's heads) will be replaced by a documented build framework.
Create a permanent build record - XML project files and log files, which become part of your project's source code (and can be maintained in source control), provide a persistent, documented record of how builds are performed.