You need a contract but be careful paying for a lot of boilerplate. Most things you see spelled out in contracts are matters of law, and contracts can't override or nullify state and federal law. For example in many jurisdictions contract disputes (and many other civil suits) for small-ish amounts of money automatically go to mediation to keep the courts clear of he said/she said cases, regardless of what the contract might say. Don't expect your case to hinge on clever wording in the contract, it doesn't work that way. Mediators and judges look at what was promised and reasonably expected, what actually happened, and what could have been reasonably foreseen. They don't pay attention to technical details of the contract.
I have served as an "expert witness" in several software project breach of contract cases, and I routinely take over projects after the developer and customer have parted ways. To protect yourself be very clear on the deliverables, the expected payment, and who is responsible for what. The primary mistake both sides make is not defining deliverables in a way that can be measured. Over and over I see major projects described in a few vague sentences with a fixed fee for everything, and that's almost always going to go bad because neither side can predict the future, and neither side has clear expectations.
Unless you have significant experience and are working with a client you trust and understand, keep the deliverables small and manageable, so you can clearly define them. If you promise something like "new e-commerce web site" that leaves just too many opportunities for misunderstanding. I usually spend my first few consulting hours (paid) helping the customer define their priorities and turning those into defined deliverables, so we both know what "done" means. The more ambiguity and vagueness in the agreement the more likely it will turn into a misunderstanding and then a lawsuit.
It's normal for project requirements to change during development. It's normal for the developer to run into unexpected technical problems. It's normal for customers to misunderstand or change their mind after they've agreed to something. It's normal for customers to not have their deliverables (business rules, assets, data, etc.) in the usable state they promised. Anticipate these things, they are routine, not exceptions, and build those into your process and your agreement.