You're moving out of the alpha development stage to polish your software but don't lose sight of the big picture. Read the problems you discovered and refined in the alpha stage every day to remind yourself if you need to.
Are the problems set in stone now? Not at all! If you discover major issues with your approach you can go back to the alpha stage, adjust your plan and evolve your software in that direction before moving back to beta again.
Now's not the time to stop listening to people. Let more detailed feedback make it through your filter and start handling the less serious usability issues. Give oil to squeaky wheels but also look for squeaks yourself. Get some design and usability help if you're not an expert, it's worth every penny and more.
Like in the alpha stage, releasing often proves you listen to what people are telling you. Then they will be eager to send more feedback and tell their friends about your software. Why? Because they helped design it. That doesn't mean you have to act on all of the feedback you get but be prepared to justify your decisions. If you don't respond to feedback, it will dry up.
Why do you want to leave the beta stage so quickly? A lot of big companies are using the beta word to release software to the masses without having to be completely responsible for its quality. If a problem happens with beta software people are more forgiving simply because it's labelled beta. They will even help you track down the bug.
The good news is that the beta term is catching on and more people know what beta means and what to expect from beta software. As more software is developed in this iterative fashion with an emphasis on real people giving feedback, expect that more software will be available publicly at the beta stage.
Your software goes into "maintenance mode", gathers dust and dies? It doesn't have to. While your beta version stabilizes towards a final production release, start a new development branch and do the alpha process over again on the software. Make a staging subdomain and pick some eager people to try the next version of the software before anyone else.
With the lessons you've learned getting stable on this iteration you can certainly make some improvements. Software made in this way can continue to evolve and live a lot longer than a rigid design. Your business can take advantage of this flexibility instead of taking the risk of starting a Version 2.0 from scratch all over again.