Do you release apps quickly with bugs or tinker to perfect state?
Do you release apps quickly with bugs or tinker to perfect state?
Hi, I am working on side project, which I want to release for free after it is ready. But how do you know, when it' s time?
I feel like it is never ending process of fixing bugs, refactoring and tinkering.
I dont ask money for this app, but I feel if it wont be good or in near perfect release form first time after publishing, nobody will bother to use app again.
Is it better to release app as beta beforehand to gather feedback or wait for confidence when everything is working smoothly as intended? Thanks a lot
Slap alpha stickers all over it and release it. 😄 What are you worried about?
What kind of product is it anyway? If it was a mobile app and people can leave bad reviews...just pull the app when the alpha is over and release it as a new app. If it's a web app people can't leave reviews anyway. It's not like people are going to go around the internet writing in-depth bad reviews about you for what you've labelled as an alpha.
Release soon so people will tell you what bugs and features are important to them and you'll stop wasting time perfecting areas people aren't interested in. It'll help you focus.
You're not going to reach everyone in the world even if that does happen so there's always going to be more people that could try it later. Worst, worst case you can relaunch later with different branding.
Such a great idea! I'm going to use "beta" though cause I feel like the average user would be more familiar with that word, haha. Gonna charge money for my buggy mess too, huehuehue.
I would release ASAP. My app Soccercruit has been live for over a month now and I discover bugs I couldn't have tested for our thought of by people using it and from customer feedback.
This is the bane of my life and I think all developers suffer from tinkering to much on side projects so you are not alone! However, the quicker you can get it to a friendly beta tester the better. They will quickly reprioritise what actually needs doing and, by doing that stop you spending time on fun but non essential development tasks.
There are bugs in every software project ever coded. Don't release a product (save for a limited circle of trusted users) with known bugs that user can find. If those known bugs are too numerous to fix quickly, the project may not be a great state to release anyway!
If you aren't aware of any bugs that a user would find, then launch and make changes as the usage increases.
I made a list of all the features that I want in the first release and I'm sticking to it. I actually bumped a couple of things off, while building the app, because it didn't seem necessary.
Then I made a separate list for all the features that I would like to see after the release, so I'll know what to work on. You can repeat this process and filter items at each stage.
If you think that it's in alpha or beta stage, then let your users know. Most times they are forgiving and will actually help you to make it better.
There's a pretty good article from Basecamp about this, thinking about the featureset as surface area and the quality as depth. https://signalvnoise.com/posts/2963-what-happens-to-user-experience-in-a-minimum-viable-product
I try to aim at keeping the surface area small and the depth consistent with the quality I want to produce instead of letting the surface area expand and lowering the quality.
By limiting scope up front, it helps stop the tinkering.
Since you have already started you can freeze the scope and evaluate whether the quality meets your own guidelines. If so, ship it!
I also try to evaluate quality from the customer perspective, not the codebase perspective. Refactoring can definitely be a form of procrastination and delaying.