A prototype gives information about the system that you are about to build. When you plan to use untried technology, you need all the information you can get. The prototype should exercise any hardware, software, algorithms, or other technology that you have not used before. If a software tool that you wanted to use won't do the job, it's better to find out in the prototype before you have spent a lot of effort preparing to use that tool.
The prototype does not need to exercise every feature of the new tool. It just needs to give you enough experience so that you know how to use the tool to build the final application. When you know how the tool performs, you can decide whether you should use that tool or replace it with something else. If no replacement is available, you may need to change the application's design to eliminate the related features entirely. Eliminating paths doomed to failure now can save a lot of time during final development.
The prototype can also help you test new activities that are not directly related to writing source code. For example, you can use a new source code control system, a series of code reviews, or a progress-tracking tool while building the prototype. This will help you learn whether these tools will work for you in the bigger project. The prototype will also give you some experience with these tools while it is still easy for you to change their use. For example, after using a progress-tracking tool in the prototype, you may decide that you need to track progress on only a weekly basis, not a daily basis.
If you test every unknown feature of the system thoroughly in the prototype, you will know how to implement everything during final development. It may be a lot of work, but there will be no surprises. You may decide to switch graphing tools, change the frequency of code reviews, and drop a whole subsystem during prototype development. Building the final application, however, will be a matter of sitting down and writing code to do things you understand.