I've always been a proponent of right-sized process; that is, enough process to do the job, but no more than necessary. Though most development efforts fail on the side of too little process, it's reasonable to be nervous about too much process just for the sake of process. Fortunately, there's an effective minimum that's easy to implement. Read on and make sure you're doing at least the minimum to keep yourself on track.
Over the years, I've seen a surprising number of development efforts that put themselves at unreasonable risk of failure simply by skipping on some simple pieces of infrastructure. Often, this is done in the name of speeding development; as in, "if we skip this bit of process here, we can get this done faster." That makes sense in the same way that skipping an outline will help you get a research paper done more quickly.
In fact, the right amount of process or infrastructure is right because it helps you get the job done as quickly as possible. Some things, like source code control, save time by eliminating those catastrophes that inevitably crop up during the course of a development project. Others, like bug tracking, simply reduce overhead needed to keep track of what's going on. The items I've listed here have made a real difference in my teams' ability to deliver software over the years -- they should be considered minimum requirements if you're building software for internal or external clients.
Source Code Control. This should be pretty obvious, but it's staggering how much software development happens without source code control of any kind. If you're a one-man wrecking crew, you may be able to get away with burning a CD every day, but there are plenty of commercial-quality SCC systems out there that are free for single developers or non-profit development -- check them out. If you're part of a team, this is simply not optional. Pick a system and start using it.
Build Machine. Some may be surprised to see this show up on a list of "must-haves", but it's been a key for me over the years. Simply put, this innoculates you against "it works on my machine". By setting up a build machine that is connected to the team via your SCC system only, you guarantee that you have one and only one system configuration that produces your "official" builds.
Note that there's nothing here that says developers can't do builds on their local machines; on the contrary, that can help boost individual productivity. If your build system is able to handle this, that's fantastic. Under no circumstances, however, can you ever consider a build done anywhere other than your build machine to be considered "real".
A related but separate issue is build frequency. I'm a fan of daily builds, but I've used build machines for weekly or ad-hoc build schedules, and the concept is just as valid in these other settings, too.
Bug Tracking. This can be an excel spreadsheet if you're really compelled to go minimalist, but again, there are so many great options out there that don't cost a thing, that I think you'd be foolish not to set up a "real" system. Use it to track bugs, and be religious about it -- it it's not in the system, it never happened. Don't let this be an excuse to be abusive to customers who don't have access or knowledge to use the system; you may end up entering some bugs for them. Just be sure they're in the system.
You may find that you want to track feature requests, support incidents, or other to-do items in your bug tracking system. Once everyone's in there on a regular basis, this can make a lot of sense, and can take the place of "big process" for things like requirements management and help desk support. Go ahead and exceed the minimum if that makes sense.
Automated Testing. If there's an optional item on the list, this is it. There's often a fair bit of work involved in setting up effective automated testing, but once it's in place, it's a powerful tool. Find some small amount of unit testing to start with and give this a try. You should be able to see results quickly and convince yourself that futher work is worthwhile.
Good luck with these -- I'm sure you'll need to exceed these minimum guidelines for many projects, but if you ever stumble into one where you're not meeting these minimums, get them in place as quickly and as carefully as possible.