I'm looking for a consensus for one or the other
Beta; Release software that is semi- functional to a limited audience and let users guide the process until an application is complete.
No Beta; Define all functionality based on previous user-feedback and/or business logic, build the software, and test it with whatever time you give yourself (or are given).
I disagree with both of your cases.
How about internal QA? They find bugs too, you know. Only release a beta to customers when you have no known serious bugs.
Also, always test adequately. If time is pressing and you haven't finished all your tests, then that's just tough. Finish testing, whether you have time or not.
Hmmm...Beta is for a product you think is finished...until you give the Beta users to play with it and they break it in ways you haven't thought of.
So, yes, go with Beta, unless you want to burn your product on many users.
Without knowing what the app is and what it's audience will be, I think that would be a hard choice to make. However if it's an Open Source project, it seems like the consensus is usually "Release Early and Release Often".
The real question is this: Do you know exactly what your users what?
If you answer yes, then design and build everything and launch it with no Beta.
If you answer no, then Beta is the way to go - your users will help define your software and they will feel more a part of the process and have some ownership.
I say Beta. But I disagree with your premise. You should never release semi-anything software. The software released as Beta should at least be feature complete. This way your users know what they're getting into.
As far as finding bugs. Internal testing is best. However, anyone that has released software knows that no matter what the user will find a new and interesting way to break it.
So Beta 'til your hearts content.
I would suggest alpha testing first, to a select group, that is not feature complete, so they can help you find bugs and determine which features are needed.
Once you get what is thought to be feature complete, then release it to a larger group, mainly to find bugs, and to get comments on feature changes, but you may not make feature changes unless there is something critical.
At this point you are ready for release, and you go back to step (1) for the next release.
After finishing (you think) your software, and believe that there are no serious bugs, conduct alpha testing. Make the software available within the test staffs of your company, fix the bugs reported.
Next, release the software to customers as beta testing, collect comments, fix bugs & improve features.
Only then you're ready for release.
Neither.
You shouldn't release a beta until you feel that the product is bug-free. And at that point, the beta users will find bugs. They will, trust me. As far as letting the beta users 'guide the design', probably not a good idea - you'll end up with software that'll look like the car that Homer Simpson designed. There's a reason why beta users aren't software designers.
As far as the second option - unless you are an extraordinary tester, you will not be able to test it as well as end-users (they will do the silliest things to your software). And if you "test it with whatever time you give yourself (or are given)", you will not have enough time.
My answer is that there are many factors that would determine which makes more sense:
1) Consequences of bugs - If bugs would result in people dying, then I think a beta would be a bad idea. Could you imagine running beta software on a nuclear reactor or on a missile system? On the other hand, if the consequence is fairly minor like if there is a temporary outage on some fantasy sports site, that may not be so bad to put out in beta.
2) Expectations of users. Think about the users of the application and how would they feel about using something that is a "beta"? If this would make them scared to actually use the software and be afraid that it is going to blow up on them regularly and be riddled with bugs, that may also play a role.
3) Size of the application. If you are going to build something very large like say an ERP to handle the legal requirements of 101 countries and contain hundreds of add on modules, then a beta may be more sound than trying to get it all done and never get to where you have customers.
4) Deployment. If you are setting up something where the code is run on your own machines and can easily be upgraded and patched, then a beta may be better than trying to get it all done right in the beginning.
5) Development methodology. If you take a waterfall approach, then no beta is likely a better option, while in an agile scenario a beta makes much more sense. The reason for the latter is that in the agile case there will be multiple releases that will improve the product over time.
Just a few things I'd keep in mind as there are some cases where I easily imagine using betas and in other cases I'd avoid betas as much as possible.
Undoubtedly beta!
Some benefits of running a beta period ...
Launch quickly and iterate often.