There are many people who want to develop apps for various reasons, such as to promote digital transformation or to develop new business or service strategies. However, it is difficult to give an accurate answer to the question, "How much will it cost to develop that app?"
In this article, we will introduce the thoughts on "what kind of requests can be realized with what budget" that were explained at the event (※ 2) by two experts, Tairo Funaki of Sun Asterisk, Inc., a professional in the app development phase, and Taketo Motomura of Macnica, a professional in the planning phase (※ 1).
* 1: Wu Xiaodong from Sun Asterisk Corporation also participated as a facilitator.
* 2: This article is based on the event held at Sun* Otemachi studio on Wednesday, July 10th.
A professional talks about "What is most important in the early stages of app development"
Wu: Today, we will be discussing two main topics. The first is what is most important in the early stages of app development. The second is based on actual case studies, and we will ask Funaki and Motomura about the costs and mindset of development. Motomura, what do you think about the first topic?
Motomura: We operate based on the philosophy of "create first," and within that, we place great importance on "create first" planning our goals, rather than just creating blindly without any thought.
This is just one example, but sometimes clients with their own unique hypotheses come to our consultation sessions with a PDF containing a business plan that is dozens of pages long. However, I often think, "Before we get to that point, wouldn't it be better to first create a minimum level product and test it with users?"
In such cases, the planned schedule, business feasibility, expected ROI, etc. are certainly included in the document. On the other hand, feasibility, success rate, schedule, etc. are all elements that depend on users and feedback. That is why we first create something that targets users and place importance on increasing the resolution of the plan itself.
When you make repeated refinements to your initial business plan, it's not uncommon that the plan ends up going in a completely different direction in the following phases. However, this is only the result of targeting what you've created at the intended users, so you're not just moving forward blindly.
Wu: It's not right to create something without any hypotheses. There's no point in suddenly assuming a story like "If we do this, we'll make 10 billion yen in sales," so you create a hypothesis, then physically test it against users, and then adjust the direction as you grow.
Motomura: Yes. Especially in large companies, organizations that are promoting new businesses often prioritize the management's expectations of "increasing the market by 10 trillion yen" over the perspective of the person in charge. However, in order to succeed in the cycle of new business, I think it is important to first try to tackle the hypothesis that you think is "the one" before thinking about horizontal expansion of results, functional expansion, business scale expansion, etc.
Wu: What about you, Funaki-san?
Funaki: As developers develop products, they inevitably have to make choices about what they expect and what they want to create as a team. If you make everything, the product will become fat and it will take time and money, so I think "what to do and what not to do" is an important point of discussion in app development. When doing so, I think it is important to conduct an examination that clarifies what you hope for, what you expect, and what you are worried about. In other words, it means clarifying the parts that are black Box within the team that is developing together.
For example, an app may consider adding a social networking feature to increase user retention. If the feature is new and does not yet exist on the market, even if the creator thinks it is a good one, there is no way to know how it will be received when released to the market. Therefore, verification of the feature itself is necessary. On the other hand, since it has already been proven in the market that "social networking features increase user retention," it is possible to argue that "we should skip verification, avoid fat apps, and focus on creating an experience that is just that feature."
If the team discusses openly and honestly about anything they don't understand, including where to start development and how much man-hours it will take, development will surely go more smoothly.
Motomura: It's a very good point that we should eliminate anxiety, not risk. When testing hypotheses for new businesses, it's difficult to move forward unless you put psychological safety at the forefront and work as a team, but if you put the word risk first, in today's uncertain world, every element becomes a target for risk taking. I would like to incorporate actions to eliminate anxiety while acknowledging that there is anxiety.
Funaki: In our team building, we use the expression Hope & Fear. The things the team is worried about are risks, but at the same time, they can also reveal things that a consensus has not been reached, which can provide some great insight. When we get down to the finer details, the difference between what each person envisions can become clear through the word anxiety, such as "I think this business will actually work out like this." In order to reflect that in the product, we place great importance on discussing it at the beginning.
Don't lose out on estimates anymore - Learn from the experience of our predecessors and overcome obstacles -
Wu: Now let's move on to the second topic and talk about the following case study.
How much does this case cost? ~Tourist guide matching app~
Wu: The first case is about the costs and mindset when developing a tourist guide matching app. Recently, the number of inbound tourists from overseas has increased, and the background is that we want to provide new value to these tourists. The business model and functions are as follows, but first, Mr. Motomura, what do you think from a business perspective?
Motomura: I tried searching for "tourist guide matching" and all the companies that showed up on the first page were different, so I think there is probably a market. At the same time, there are at least 10 rival companies, so it seems necessary to think about "Can I really win by creating the above functions?"
However, I feel that the penetration rate of these apps is still not high, so the key is how to stand out from the crowd. In other words, it would be better to have an overall strategy of "we can win in this area" after comparing STP with existing companies to see where your competitive advantage lies.
As with the trendy generative AI, despite the rapid increase in vendors and service providers, it is not widely used in Japan. In light of this trend, I think it is necessary to research statistical data such as how large the current market is and what overseas tourists come to Japan for. For example, if we assume that Kyoto is the most popular destination, we can hypothesize that we should segment apps that are specialized for Kyoto. If you want to obtain the desired facts, you can use data provided by the government or data from research companies that can be purchased for a fee, or ask an analyst to conduct a survey.
Funaki: As I was listening to what you just said, I secretly made a quote. In conclusion, if we look at just the development part, it comes to 13.5 million yen.
The numbers in the table, such as "1" and "2," indicate how difficult the story points for each function are in terms of the app and backend. For example, when comparing "User Management" and "Payment Function," the latter will take more than twice as long on the frontend and more than four times as long on the backend.
This method of indicating difficulty becomes difficult as the numbers get larger, so a distinctive feature is that it uses a sequence of numbers (Fibonacci series) that adds the two previous numbers together, such as 1, 2, 3, 5, 8, 13. This is a method of estimation called story points. Once this difficulty level has been decided, it becomes possible to make a rough estimate in the form of "If this takes 20 hours...". Then, add up these rough estimates to calculate man-months, and multiply that by the unit cost to get the total.
The requirements for a single function vary greatly depending on the project. When conducting closed testing with an MVP, if you communicate and fix any bugs to a certain extent, but focus on quality by making sure all the features are working, the development man-hours will be significantly reduced. On the other hand, if you decide to release the product after all the bugs have been fixed, the man-hours will be doubled or tripled.
However, the relative difficulty of creating the function remains the same. Therefore, for one function, for example a user registration function, instead of saying "This is the perspective we aimed for when developing it" or "It took this amount of man-hours," if you say "I wish it was easier" or "I wish it had more time to improve the quality," then the numbers such as "1" in the table will become clearer. Once that happens, you can make corrections. If you originally thought that "1" took 20 hours, but then realize that it actually took 10 hours or 30 hours, the resolution of your plan will increase dramatically.
Given this background, it is important to create a plan based on relative difficulty, but it is difficult to align your perspective. Therefore, you should create the plan while looking at other abstract numbers, and change them if they do not match. PMBOK (※) also requires a very rough estimate, but the range is set as a rule to be minus 50 % to plus 100 %, that is, it can be halved or doubled, so I think this method is very excellent for keeping it within that range.
By the way, the BI and management services written in red on the bottom left are areas that are often overlooked. If you can't track the numbers when you actually verify them, it's completely meaningless, and when you perform management operations, manual responses will suddenly be required, which will increase running costs, so this is also something that needs to be thought about accurately.
*: Abbreviation for Project Management Body of Knowledge, commonly known as "Pinbock." A globally-used reference book that systematically records project management-related knowledge and know-how.
Motomura: This is the kind of information you could only discover by coming across a good book.
Wu: In terms of cost, the range is roughly between 7 million and 27 million. Of course, you wouldn't provide an estimate in this state, but how should the ordering party determine the budget?
Funaki: It depends on the company's budgetary thinking, but one way is to agree to "create XX function" while taking these increases and decreases into account, and then start creating it. On the other hand, if you are in trouble if you don't know the deliverables and the price, you can set up a requirements definition formulation phase to clarify the details, share the price sense, prepare a sample of specifications that match your perspective, and then proceed with concrete development. However, the latter method loses a sense of speed, and it is difficult to make good specifications without actually making it. After all, the product gets closer to a good direction if you work on it as you go.
How much does this screen image cost? ~ Dementia diagnosis system ~
Wu: In the next case, we are considering using brainwaves as a hook to lead people to content related to dementia prevention. In order to respond and guide them through media operations, we are basically planning to provide this as a free diagnostic service to hospitals and medical centers. Functions include uploading brainwaves and an AI diagnostic page. Mr. Motomura, what do you think about this case?
Motomura: Although it is being offered free of charge as a simple diagnostic service, diagnosing dementia is a medical procedure, and so approval under the Pharmaceutical Affairs Law is required. The key point seems to be whether the company wanting to develop this product is really aiming to expand into the medical field, and since the main focus is on preventive content, whether it would be okay to use it in the healthcare field.
If it were the former, it would take years just to process the application, and clinical trials would cost hundreds of millions of yen. On the other hand, if it were the latter, I think it would be necessary to make the project theme something that is far removed from medical practice, such as "This is a support app to prevent MCI and dementia."
From the perspective of players like us who deal with AI, considering that the input for making diagnoses such as "You have symptoms, so you need to be careful" is brainwaves, it will be important to measure how many people's data we need to collect to create the minimum functionality. The functionality is less than the previous case, but it feels like there is a lot to do and it will be difficult.
If personal information is acquired, there are security measures and ethical issues regarding linking it to brainwave information. However, if a truly light preventative app is made and has market potential, it should be possible to release it for a reasonable amount of money.
Wu: Listening to what you've said so far, I'm also curious as to whether preventive content will actually pay for itself.
Funaki: The product is simple, but to advance the modeling and development of the recommendation engine, a large amount of past performance data with answers such as "In a certain situation, XX preventive content is appropriate" will be required. If we create it based on that premise, we came up with the figure of 43 million this time.
However, even if there is a large amount of data, there may be cases where appropriate predictions or recommendations cannot be made due to insufficient attribute information. The difficult thing about AI is that you never know until you try it. In this case, you cannot be absolutely certain that pre-learning will be sufficient, so if there is no AI model, I think it starts with creating the model from existing data and investing in verifying whether it can derive effective results. The range of amounts involved is so unknown that it cannot be included in the definition of a very rough estimate, so it is better to think that something like research investment will be required at the beginning.
I have trouble getting approval from others
Wu: I think the last case is something that happens to every company. This time, the persona is a company with more than 10,000 employees. What advice would you two give to them?
Motomura: Considering the previous two cases, even though the functions were presented, there was no mention of the results that could be obtained. Therefore, even if we were to submit a rough estimate like the one Funaki-san gave us in this situation, I think there would probably be a high risk of it being withdrawn.
Although it says "predictive AI through analysis based on 3D CAD data and simulation results," it would be better to move away from a request that focuses on that one point. In other words, it would be better to have a broader perspective, such as "what will happen when the outcomes obtained through this are deployed throughout the company?", such as what assets will remain for the company through this series of efforts, and how much impact will the resulting technology have on other departments.
Basically, the decision makers have not heard about the detailed arrangements with the vendors, so there is a clear gap in the level of knowledge and understanding between them and the field. The key here is so-called internal politics, or in other words, laying the groundwork. The Harvard Business Review also says that "internal politics are important for innovation," and there are also studies that show that involving more members than just yourself and the decision makers is effective in convincing decision makers, as are techniques for getting more stakeholders involved in the decision-making process, and that output that is close to the final form.
Before submitting a request for approval to aim for the final goal, you can do things like paper prototyping with the intended users to increase the resolution of the feasibility, or gather feedback on Figma, without having to start from scratch with creating a project. If you can prepare the results and a minimal prototype within your own budget without the need for a request for approval from a decision maker, you should be more likely to be convinced when you make a proposal.
When I was helping my clients promote new business, I sometimes had difficulty getting approval from my superiors when I made a presentation. However, when I explained the idea while showing them the product, they said, "Yes, that's what I wanted to say!" and the discussion moved forward easily. After all, it is more important to show a worldview that is closer to the final form than the logic.
Funaki: I think that the company's decision-making flow and "attitude" towards new businesses are important. This is something that many people talk about, but VCs have an expected IRR of around 40 to 50, and they work in a kind of service-like way, making a 6x gain over 5 years. In other words, I think that the relationship between startups and VCs is a well-honed relationship in which they can make investment decisions and position themselves as a result of being selected out of new businesses. Therefore, even when starting a business within a company, it is important to learn that, under the basic premise that "most new businesses will not be successful," you should think about how to pay off when they are successful.
If you look at sales and decide from the beginning that "one hit with this policy is enough," you can throw away about 10 to 20 million yen, which is an extreme example. It is impossible to invest in a project that everyone will be a hit in the first place, so let's try a number of things. I think that a fair relationship in a new business is probably to draw a picture of the future you want as a company, have a sufficient investment effect in terms of ROI, and say "let's take on the challenge with 10 to 20 million yen."
Wu: It would be best if we could base our work on the kind of relationship that Funaki-san talked about, but in the moment, we may have no choice but to move forward using internal politics and loopholes. However, it seems that each company can say that it would be quicker to create something and show it to others, as a way of thinking that can be replicated.
Summary
Wu: Finally, I'd like to hear some comments from both of you.
Motomura: In the cases we introduced, the amounts raised were 13.5 million and 43 million, but there are many cases where those who are promoting through a steady verification process are confident that they can win even if they bet such amounts. When we work with our customers, we place great importance on how many times we can go through the cycle of implementing the voices of the expected users we have actually heard into the product, rather than holding meetings to organize information using a framework. I would be happy if we were able to provide you with some of these hints at this event.
Funaki: I want to see more and more apps that bring about innovation appear in the world, and I am doing my current job because I want to help make that happen. I feel that in society, there are many cases where it is thought that if you do not have a firm grasp of the content when talking to IT vendors, the conversation will not move forward. However, there are many companies, including Macnica and our company, that will think about what path to take and how to develop in order to create a digital product from an abstract point, so please feel free to consult us. I would be happiest if many apps were to be released to the world quickly in this way.
＼Click here for details on Re:Alize／
Latest Information
Case Study
Blog
Document List