Scope planning for MVP: How to prevent cost escalation?

“My app won’t make sense unless I add one more feature” – does this sound familiar? One feature often entails creating several more, triggering the so-called Diderot effect, where the scope of needs expands. Learn how this phenomenon impacts the app development process, what its consequences are, and what you can do about it – all covered in this article.

Read on to find out:

  • What the Diderot Effect is in the context of app development.
  • What implications it has for you at the stage of planning its scope and receiving an offer from the contractor?
  • Why it’s so easy to succumb to the temptation of adding more features.
  • What you can do, being aware of this phenomenon.

What is the Diderot Effect in the context of app development?

The Diderot Effect is, in short, a situation where the purchase of one product creates the need to buy another. The name comes from the French philosopher who described this phenomenon after he acquired a new, beautiful robe. This led him to replace other elements of his wardrobe and home furnishings that… did not match the aesthetics of the new clothing.

You surely know this from everyday life.

The products we purchase often create the need to acquire more. If you buy sports equipment, such as a bicycle, it always comes with accompanying gear, accessories, and clothing items (helmet, gloves, water bottle, sports glasses). Often, the next purchases will be tools for maintaining your equipment or spare parts, such as wrenches, inner tubes, lubricants, and a pump. You now need to allocate space to store the bicycle and the gear. But mere cubic meters are rarely enough—you will need to organize the storage space for your acquisitions, such as cabinets or racks.

Alright, but how does this relate to software development?

In many aspects, developing a product like an application works on a similar principle: creating one feature creates the need to develop another.

Let’s examine this with a specific example: user registration in a mobile application.

The very possibility of registration automatically means the need to create the following features:

“Must-have” (won’t work without it):

  • Email address verification and password setup
  • Ability to recover forgotten password
  • Ability to delete account and data (required by app stores), which means designing a place in the application for this action, such as profile settings

“Should-have” (may not work properly without it):

  • Ability to change password
  • Two-factor authentication (e.g., confirming account creation via email with an activation link)
  • User management on the admin panel side, ability for admin to suspend or delete an account

“Could-have” (user experience will greatly improve):

  • Adding a user photo or information
  • Logging in using a social media account
  • Preference settings options, such as the ability to hide certain information from other users, choosing an interface language different from the default, etc.

What implications does it have for you at the stage of 1) app scope planning and 2) receiving an offer from an app development agency?

1) At the scope planning stage

More features = longer application development time, additional integrations, more server resources = higher costs.

When planning a feature list, it’s important to be aware that almost every feature on the registered user’s side will need to be reflected in the admin panel. Sometimes it’s a matter of slight customization, other times it will require many hours of programming.

In-app purchases are not just a shopping cart and payment.

It also includes purchase history, the ability to return items, the ability to manage purchases on the admin side, creating notifications for products that are no longer available in the cart, and selecting delivery methods, which involves integrations with courier companies.

Product ratings are not just leaving a star rating and a comment.

It also involves creating a review history for the user, filtering products by rating and the number of reviews, analytics on the admin side, and (as a could-have) the ability to respond to unfavorable reviews in the form of a comment.

2) When receiving an offer from an app development agency

There is a risk that your potential dev shop did not estimate the cost of features that are not on your requirement list but are essential for the proper functioning of the application.

How could this happen?

The dev shop prepares a cost and time estimation based on a list of functional assumptions (estimates are less accurate in this case) or on already designed UX/UI screens with a description of features (more accurate estimates). It might happen that they do not thoroughly analyze the dependencies between features and do not notice that an important screen is missing in the project.

Another possible scenario is that they notice these omissions but choose not to suggest outright that new features need to be included and that the estimate should be much higher, fearing that it will make them less competitive.

Therefore, pay attention to the quality of communication with the dev shop. The fact that they ask you a lot of questions is a good sign.

Why is it so easy to succumb to the temptation of adding more features?

You are probably looking for assurance that your investment in the application will pay off. You might feel that the application would not be “perfect” enough to be published without a range of features. You want to feel that you are doing everything to make your future users love your application and therefore, even before you verify your idea in real life, you are already planning further improvements to your app.

There is often a perception that the level of effort will directly correlate with the results obtained. This can lead us to fall into the trap of thinking that our investment will pay off sooner or later, so it’s better to invest in a complex application right away and then just wait for the return on investment.

Unfortunately, it may turn out that 1) within the assumed budget, you will achieve only 70% of the planned scope instead of 100% of a smaller plan, and 2) you will create many features that may ultimately turn out to be unnecessary for the user.

What can you do, being aware of this phenomenon?

1) At the scope planning stage

Whether you represent a startup or a large organization, it’s worth approaching app planning with the spirit of MVP (Minimum Viable Product). In short, this approach can be translated to:

Most Valuable First

MVP assumes creating one or two truly priority features that provide the greatest value to the user. The goal is to publish the application as quickly as possible to allow real people to use it in the shortest time possible. This way, you can test the market, gather feedback, and find out which direction to further develop your product. This stage often brings about unexpected ideas.

Number of features in MVP: not just “what,” but “how”

Instead of creating many features that may be too burdensome at an early stage of app development, it’s worth sticking to just fewer but doing them really well. Consider what could be the “lever” that will make users love the app more. This means seemingly small improvements that can deliver very large results, especially in the area of UX/UI (user experience and aesthetics).

Users often stop using an app because it is too slow or complicated. They’re unsure if they understand its features well or find it challenging to use smoothly, for example, if they need several clicks to access a desired function. Improving these factors has a huge impact on the success of a digital product.

Remember, MVP does not mean an ugly and user-unfriendly product.

Designing a high-value MVP for the user requires knowledge of technological possibilities and good UX/UI practices. Applying these will make your app visually appealing and practical from the start, even without a large number of features. At the very beginning of app creation, it’s worth investing in Product Design workshops, during which, together with our experts, you will design how the app should look and work.

2) When receiving an offer from an app development agency

If you’re looking at offers from a few dev shops and the price difference is significant, ask them:

  1.  what assumptions were made during the estimation of each function, meaning a step-by-step description of how exactly the user will interact with it

Why?

You and your dev agency may discover that the user path requires planning additional features that were not included in the estimation, especially if it was too low.

  1. whether creating a particular function may entail additional features, including those on the app’s admin side, and how the dev agency recommends doing it.

Why?

Another common situation we encounter is when the application’s feature list is focused solely on the end user. It’s important to remember that the administrator panel reflects the application’s capabilities from the user side. Depending on the case, the panel may need functionalities such as: viewing and managing users (editing data, manually adding or deleting users), adding advertising content (e.g., banners), determining the lifespan of messages, and managing notifications. If your admin panel anticipates multiple roles (super-admin, regular admin), you’ll need features for adding administrators and defining their permissions.

Pricing differences can also depend on the proposed technologies. When building an admin panel for startups, we often recommend using FireCMS. This Google platform allows optimizing the panel’s construction time by using ready-made components that only require customization for the project’s needs.

If you represent a larger organization and your application integrates with existing company systems or involves many custom functional solutions, creating a dedicated panel is usually the best solution.

Summary

It’s very easy to exceed the assumed budget for application development and lose control over the project scope. This happens due to difficulties in estimating the needed number of app features and the desire to overly expand it at the initial stage. A thorough analysis of application requirements and an honest discussion with a potential dev agency should help determine the actual scope and investment amount.

Need to consult your idea with specialists? We’re here to help you.

Let’s talk

Get some useful knowledge.

View all posts
24/05/2024

How much will it cost you to build an app? A detailed step-by-step breakdown

Costs, costs, and more costs. This is what you need to prepare for if you’re developing an application. If you’re doing it for the first time, the amount of investment required might come as a surprise (and not the pleasant kind),  because you may not understand where it comes from. In this article, we will look at how much money needs to be spent before you can even see the first results of the programming work, and most importantly – what exactly is behind the costs.

Kasia Sitarz
Business Development Specialist
Poznaj odpowiedzi by lepiej zrozumieć proces tworzenia aplikacji, ale także efektywniej komunikować się z software house'm.
11/01/2024

Building an App? We reveal 15 questions a Software Development Company will ask you

Before contacting a Software Development Company that will potentially create your application, check the list of questions you need to know the answers to. The list will prepare you for the conversation so that you will be treated as a partner and receive a valuable offer. Additionally, the Agency will be able to more accurately estimate the required time and expected cost of building the application.

Michał
Michał Cal
Head of Growth
Modele rozliczeń w IT: Fixed price, time & materials, fixed budget
01/02/2024

Billing Models in IT: Fixed Price, Time & Materials, Fixed Budget

Fixed Price, Time & Materials, or perhaps Fixed Budget? Choosing the right billing model is a crucial step when starting a collaboration with a software development agency. Each of them has its unique features, advantages, and limitations that should be carefully considered before making a decision. In this article, we will take a closer look at these popular billing models. We will discuss when and why each variant is used and what their main advantages and limitations are.

Kasia Sitarz
Business Development Specialist

We’re available for new projects.