Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Transcript coming soon.
When it comes to building new apps, it's hugely important to get it in the hands of your target users as soon as possible. Even the most well thought-out and researched ideas are largely assumptions until you prove that users are going to use your app in an expected way.
When it comes to building software to achieve that, we need to keep a balance between robustness and speed of delivery.
Let’s explore some of the considerations when you’re looking to release an early-access app to some of your users.
For very early ideas and concepts, you might not need to build an actual app to be able to prove the concept. Creating any type of coded solution (even a very basic one) comes with a cost of time and resources. Begin with the core of your concept, and prove it in the quickest and cheapest way possible. Be creative with your approach to a proof-of-concept. Even the most technical ideas can broken down and “faked” enough to test ideas.
After you’ve got good feedback that your idea or plan is likely to have some users, and is solving a real problem for them, it’s time to turn that idea into a realistic “backlog” of features.
Once you have proven your concept, you can move on to building a minimum viable product - a coded solution which is just “good” enough for people to start actually using it.
Be ruthless when thinking about what features are essential, and which can be added at a later stage.
Most ideas start out as imagining a finished product, with all the bells and whistles. Just a decade or so ago, it was very common to spend a large amount of time building the complete thing before a real user had even ever seen it. We now know that this is a good way to waste a lot of time and money building something that nobody wants. Instead, we must focus on what is the most essential functionality first.
Be ruthless when thinking about what features are essential, and which can be added at a later stage. The key with an MVP is to start learning from the use of the app as soon as possible, and even potentially build a future customer base at this early point. The more features that you add, the longer it’ll take to release, and you’ll end up with more that might potentially go wrong.
Some things are often overlooked with an MVP, and are essential to getting the most from your app. Things like keeping data safe, and building strong security should likely be non-negotiables for your initial release.
When building the app, a good rule of thumb with the architecture of it is to “build for scale, but focus first on speed of delivery”. A good software team will use best practice to ensure that things are able to build as the app grows, but also be pragmatic with their approach so as to not unnecessarily hold up a planned release.
Performance of the app (how fast it is) might be something that you consider essential to an acceptable experience for your users. But, equally, you might not need to tune it to the point of a “production-ready” level while you’re only onboarding a few hundred people.
build for scale, but focus first on speed of delivery
As with all of these decisions, it’s about balancing time to develop the feature, against how essential it is for an acceptable experience.
Before you release the app to any users, it’s important to try and remove as many bugs as possible. The better the experience for the users, the more likely it is that you’ll get meaningful feedback, rather than “X and Y were broken”.
As much as possible, test your app with your internal team first. Run through “real-world” situations. For a worldwide application, this might mean testing with phones in different time zones. For a server-backed application, you should check that it works with many people connecting at the same time.
Creating a test plan can be a useful task, especially at the early phases of development where often, so much is changing quickly. Simply detail all of the actions step by step that cover the core functionality of the app. Running through this manually before releasing a new version can be a life-saver to ensure that you haven’t broken any of the important features and functionality.
In order to make the most of releasing your app early, you’ll need to ensure that you are able to quickly and efficiently capture all of the data that you want to collate.
Feature requests and bug reports are a really valuable form of feedback from users, but it’s important to capture them somewhere. Hopefully, you’ll already be using some form of project management software to maintain a backlog of features, but it’s worth considering whether you want to immediately put any feature requests there, or if they need to go through some “filter” first. This might be a product owner, or some other person responsible for the app - having an “owner” for feedback can ensure things don’t get lost, and the backlog doesn’t get filled up with duplicate items.
The main reason for getting an app out in an early state is to gather feedback about the concept and execution of an idea. One of the issues that can interfere with this is a suboptimal experience caused by technical issues. Most development frameworks come with easy-to-add tracking for things like statistics/analytics (who is using the app, and how?), and crash/performance logging (what’s going wrong?).
The next important thing to decide how you’re going to get the app in the hands of your early users. This might seem like an easy step, but it does require a bit of thinking to ensure that you’ll be set up for success.
The first thing to consider is how many users you’ll want to onboard, and where they will come from. Having a smaller number of close contacts will be easier to hand-hold through the process, whereas a larger “public” audience are more likely to give up if things get too difficult.
There are a few different options for technically getting an app onto your user’s phones.
One of the better solutions for iOS is Test Flight. It’s built by Apple, and is specifically for getting pre-release versions of apps to your users. You can have up to 10,000 early-access users, and even create a link to allow anyone who clicks on it to get the app.
Google Play Console is the equivalent for Android, and does much the same thing.
You’ll want to ensure that with any method you choose, that:
Early access is just that - be bold and get out there!
With the tips we’ve explored in this post, you’ll be set up for success with releasing an early MVP to your users. Early access is just that - be bold and get out there! The sooner you can start getting real users through your app in real-world scenarios, the quicker you’ll be able to learn about your assumptions.
Bringing people on board early can also cause them to want to help by being a part of the early journey of the product with you. Build a community around what you’re doing, and get feedback and insight from them.
If you’re looking for more tips about how to get the most out of your apps and software, contact us and we’d love to see if we can give you and help or advice.
We're love to see how we might be able to help, without any commitment.
Get in touchOur unique software discovery service is designed to get you from idea to a concrete plan.
Find out more