As c-era and broquaint say, the key is fork. This will make a "clone" of your program that is not attached to the terminal, and thus, the main program can exit and leave you with the shell prompt.

This is all fine and well, but make sure you are aware of some key issues:

• Don't fork right away. Make sure your program is "up and running" before the big fork call. This way you can report any errors, such as those with command line parameters or configuration files, to the console. If you fork and then warn or die, the output can't be captured. If this is called from a "crontab", you won't even see the error. So, configure, warn/die if required, then fork.
• Sometimes you don't want the program to fork. Including an option that prevents this, or alternatively, enables this, would be helpful when trying to debug. Otherwise your debugger might stop on the fork call, leaving your clone to run wild and free.
• If your program is a "daemon" type process, try and blend in by following standard conventions. This might mean making an "/etc/rc.d/"-compatible (SysV-Init) RC boot file, creating a PID file in /var/run, and so forth. This will help you figure out if your thing is running already, and help manage start/stop operations.

Just food for thought.