How to know which features to launch with when building an app without code

When you have an idea to build an app without code, it’s natural to imagine your product in its completed future state, with a robust set of features and massive user base. Having imagined this vision for some time, it can be tempting to set out to build that exact product from day one.

The issue with this approach is that the long-term vision for the product is rarely the same thing as the version you should launch with. You may find that a few features that took a lot of time and money to complete aren’t being used by most of the people on your app. Or users start asking for new features you hadn’t previously thought of, or want changes to existing features – or they start complaining about the features you spent all those resources on. 

So how can this be avoided? How can you know which features to include/exclude in the first version of your app?

In our experience, the key is to build just enough to solve your users’ needs. 

Below, we’ll explain what that means, how to do it, and share lessons we’ve learned over the last 7 years building apps without code for entrepreneurs, startups, and large businesses who want to get complex products launched quickly – and effectively. 

What it means to “build just enough”

In software development, the general rule of thumb is to build your first product version lean. The idea here is to test your product as quickly and cheaply as possible so that you can learn how it is wrong, and how to make the next version better. By iterating this process, and focusing on learnings rather than outcomes, your path may be circuitous, but you will ensure reaching the finish. The premise behind this is to spend the least amount of time and money to launch fast, learn the most, and build better.

However, while we typically advocate for most of our clients to take the lean approach when building an app without code, there are cases in which it makes sense to build more (see more on this below). Therefore, we prefer to think about launching the first version of your app as about “building just enough”.

This means building a software product that has just enough functionality to solve your users’ core problem and nothing else. In other words, include just the right amount of features and nothing more – which can vary based on the product, need, and use case. 

What are the advantages of “building just enough”?

Building just enough has several advantages:

• It is much faster and cheaper to launch, allowing you to start learning sooner and save more for future iterations
  
• Your product will be simpler to use, which means that new users will be less likely to get confused and leave
  
• It is easier to identify what is working vs. not working when you have fewer moving pieces to test at once
  
• You will be more likely to let your users drive product development, which will result in a product that meets their needs
  
• You are less likely to need to remove features and complexity later (which is always harder than adding them)

How much is “just enough” when building an app without code?

The guidance to build just the right amount can be very subjective. So how do you know which features are “just enough” for your app to launch with?

For most businesses, it’s best to build lean. Instead of broadening your feature set to increase the likelihood of success, you might constrain it to isolate what works (and what doesn’t). Rather than taking your time to build the perfect design, you may launch a series of prototypes to confirm (and reject) assumptions. The key is not to get the answer right on the first try, which is nearly impossible.

However, for other businesses, building just enough might not be lean at all. You might want to build more if you fall into at least 1 of these 3 cases:

• You’re building a consumer app: customers expect more polish than in the enterprise space
  
• There are mature competitors: your app may require more features to get the advantage (though this isn’t always true)
  
• You are replacing old software: your app needs to match everything you can already do today (and more)

How to know which features you should include (and which ones you should leave out)

Instead of solely focusing on building a limited feature set when deciding which features you should keep and which ones you should scrap for launch, we recommend thinking about which features will solve your users’ biggest need first.

This requires having a concrete objective for your work. It will be the core principle that every product feature must answer to.

Because your product and its objective are unique, there’s no standard list of required features that make it “just enough”. However, based on our experience building apps for entrepreneurs, startups, and enterprises, below are 6 lessons we’ve learned that can help guide your feature selection in the first version of your app:

1. Focus on key users: concentrate most on the users you need to impress first.
   - Example - if you’re building Airbnb, you need to attract hosts to create inventory, so you may want to add more features for them first. Or if you already have hosts lined up and you really want to attract renters, you may instead want to focus on building out their experience first.
2. Select a key performance metric: choose the metric you care most about to validate the app, and build features to get to that point.
   - Example - if you're building a music site, plays might be your key metric. This means you might want to encourage lots of discovery options to help people play music, versus focusing on other kinds of features.
3. Do a chronological test: tell the story of your app from your users’ perspective. Focus more on the things that happen earlier in that story to remove bottlenecks.
   - Example - if you're building a custom CRM, the first thing companies might need to do is upload/sync their data. So rather than adding lots of extra features after that point, you should make sure that users can upload and get connected.
4. Focus on a primary journey: pick one primary action/path and focus on building features required for that experience to be excellent. Don’t add features that will distract someone from taking the action you really care about.
   - Example -  if you’re building Linkedin, don’t spread yourself too thin with posts, job search, messaging, e-learning, etc. choose the core one like creating a profile/resume and finding people.
5. Build for current scale: focus on the features that work at the scale your business is currently at.
   - Example - if you're building an event site, you may not want extensive event browsing and filtering when you just have a handful of events. Instead, you can have a simple list or have someone reach out to a "concierge" to recommend one.
6. ‍Research your alternatives: consider what easy, pre-existing alternatives there are to making a feature that may take a lot of time and money to build.
   - Example - if you’re looking to book doctors appointments, you could easily use Calendly vs. complex scheduling.

Common features to include in the first version of your app

Every feature added to an app should provide benefits/value to your users. For some apps, this means certain specific features must be included in the first version so that it can achieve its core functionality. Below are several common features our clients have included in the first version of their product:

• Payments: payments are a critical part of many apps, especially marketplaces and any kind of eCommerce app. To allow buyers to pay for purchases directly from the app and enable sellers to accept online payments, it’s important to build some sort of payment processing feature into your app.
  
• Transactional emails/notifications: oftentimes, apps need to provide the user with reminders, communication from other people, or other timely information from your app. Users can tap the notification to open your app or take an action directly from the notification/email. Transactional emails and notifications are essential to engaging users within your product and lets them know when to come back to the tool to check for updates.

Common “bells and whistles” to build later

Once your app meets the requirements of your stated objective, has just enough functionality to solve your users’ primary problem, and you’ve validated the concept through testing, you can move into potentially adding the following features:

• Scheduling: for some apps, booking needs are basic — they simply need a way to reserve time and perhaps add payment. In those cases, you might not really need to build your own booking feature; you could simply integrate with an already existing one. For others, though, bookings and scheduling make up a core purpose of the application and need to be highly customized to specific provider or customer needs (or both).
  
• Reviews: reviews can be a critical way to provide additional details and information from previous users to build trust in your product. It’s best to wait to add reviews once your engagement volume is higher.
• ‍Refunds: it is often the case that the early stage of an app doesn’t need any features to handle refunds of disputes. A simple form for email address to lodge an issue, handled either by you as the app administrator or by a ticketing vendor like Front or HelpScout, can be sufficient. If you need to issue a refund, you can do that directly through the payment processor. However, as you grow you can offer a more robust feature for streamlining the refund process.
• Analytics: data is always important for a growing product. You can use it to see how your users are engaging with the app, where they might be struggling, who they are, etc. in order to improve the app experience. However, to avoid accumulating an overwhelming amount of non-actionable data, it’s best to add an analytics feature a bit later so you know exactly what data you want to capture and focus on.
  
• Filters/search: it’s critical that your users can find the information they’re looking for. And early on it might seem like offering more search options is better, but that’s not always the case. Too much choice can overwhelm users and cause them to not find what they are looking for or abandon the app because of decision fatigue. It’s best to show users the minimum number of options they’ll need to find what they are looking for, and add additional filter/search options later after some testing.
  
• Messaging: in some apps, users may need to communicate with each other. Early on, you may want to let users converse off your platform. However, you may want to add an in-app messaging feature in cases where your app promises to increase efficiency/productivity or your business model relies on transaction platform feeds (e.g.. marketplaces). 

Overall, the features you launch with and those you add later will be dependent on how fast you need to launch, how much money you’re willing to spend, and your app’s objective. 

The reality is that it is extremely unlikely that all (or even most) aspects of the product as you are envisioning it will resemble the optimal version. You may have the right service but the wrong customers, or the right price point but the wrong monetization approach, or the right messaging but the wrong communication channels – and none of this is a bad thing. 

By following the rule of including “just enough” when building your app without code, you can avoid spending money/time on features that nobody wants or having to go back to the drawing board because you picked the wrong features. Instead, you can rapidly launch an app that immediately begins solving your users’ core problems, start testing to make it even better. 

Need a no-code developer to help build your app?

Airdev works with hundreds of startups, growing businesses, and Fortune 500 companies to launch complex, production-grade apps in a fraction of the time and cost of traditional development.

‍Contact us here to discuss your project!

‍