Low-tech “proof-of-concept”

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.

Minimum viable product

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.

‍

Be pragmatic

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.

Test internally

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.

Capturing data

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?).

Build a release strategy

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:

• It’s easy to get people to install the app.
• It’s easy to get new versions to your users. This is important in the early stages, where you’ll want to quickly get critical bug fixes out.
• You can easily communicate that it’s an early version.
• Gather any feedback, crashes, or screenshots from your users.

Early access is just that - be bold and get out there!

Be bold

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.

‍