Software is supposed to make our lives easier, not harder. Computers can do the easy work and leave our brains to do more difficult and creative things. But without a problem there is no software to solve it.
The alpha development stage is a perfect time to solidify the problem statement(s). You can start out solving one problem and discover other similar ones -- or realise that your initial problem isn't a problem enough people are having to make developing the software worthwhile.
An early functional alpha prototype that people can actually use makes these issues more evident than a mock-up and reduces the risk of failure down the road. Projects can be constructed to the alpha stage without a lot of effort, so they are excellent proof-of-concepts and a relatively inexpensive way to confirm potentional risks in the business plan.
Now is not the time to nitpick. Concentrate on the big picture and respond to feedback quickly. Work on solidifying the big picture: how the software works to solve the problem(s) you are targetting. Detail work is easily thrown out by a reversal of a big decision at this stage, so it's not worth doing a lot of small things.
Deploy the project as soon as possible, even if it's simple (or empty). You don't have to tell people about it right away, just get it to the point where you can share it easily...
...and then update it a lot. Deploy changes as you make them. This is the alpha stage: things will break and wheels will squeak. Don't worry, your early users will be forgiving because you've given the alpha disclaimer and explained the implications. Explore new ideas and respond to feedback quickly because that'll lead to more feedback.
All of this change is good because you're steering your software closer to what people need to solve their problem(s). But code churn doesn't mean the project turns into an unmanageable and broken mess.
Use a unit testing framework as a safety net: make a change, run the test suite to make sure everything still works and then deploy it. Repeat over and over again. Testing is critical to this iterating. Without it, your project is fragile.
"Alpha software" used to mean nearly feature-complete and very buggy software that was ready to be let loose on a testing team to find bugs and report back to the development team. In my definition of alpha development, the software can start high quality and continue to be high quality throughout development.
At the alpha stage the most valuable feedback is directed at the big picture. Releasing early and often doesn't produce the best looking software but it's important for the developers to make a rough design as low of a distraction as possible.
People experienced with using early releases are able to put aside form and concentrate mostly on function. But there are cases where form at the alpha stage is critical and developers need to address these places to reduce that distraction to big picture feedback.
You don't need a lot of people giving feedback early on. As you can handle increasing amounts of feedback, invite more people to use the alpha project. If there are too many people giving feedback you'll find that they all say the same thing anyway.
Find quality people to give feedback instead of quantity. Find people who are experts in the domain or experts with software. You'll get the best feedback from people who are forgiving about the site being ugly and slightly painful to use and can focus on how it solves their problem(s).
Not all ideas people give you at the alpha stage are good ones! Listen to all of the feedback you can and filter out what isn't needed right now. Save all of the feedback you get, even the crazy ideas. Those ideas may not seem crazy a few weeks from now. Put them in a safe place but off your current radar screen.
Concentrate on the domain problems you want to solve with this software and how you are solving them with the alpha. Make it look nice in beta development when things settle down.