![AI App Development Cost [2026]: What ¥1M–5M Buys](/assets/posts/thumb-app-development-cost.avif?v=5da00d76)
- App development cost — what it means
- App development cost is the price of a build, determined by the person-month unit price and the effort across requirements definition, design, development, testing and maintenance. It generally runs ¥1,000,000–5,000,000.
Hi, I’m Masato. I work as a Webflow specialist while keeping up with the latest AI tools. I run Webharu, a web production company in Shiogama, Miyagi, Japan.
“I want to outsource an app, but I have no idea what it costs” is a question we get often. Search around and one company says “from ¥1,000,000” while another says “from ¥10,000,000” — figures an order of magnitude apart, which usually leaves people more confused than before.
What this article covers
- The market rate for app development, and what a quote is made of
- Why a “simple little app” ends up costing millions of yen
- How AI is changing the structure of development cost
The conclusion first.
App development is generally quoted at ¥1,000,000–5,000,000 (survey-based; sources below). But that is the price of a person-month business, where the number is set mainly by how many months people worked. Now that AI sits at the center of development, that structure is changing, and an app with a tight feature set can realistically be commissioned from the several-hundred-thousand-yen range.
This article walks through what makes up the market rate, how to order in a way that keeps costs down, and the costs that keep running after launch. A mobile app is not finished when it ships — costs continue. Knowing that up front is what saves you from judging on initial cost alone.
App development cost: the market rate (survey-based)
First, a caveat: the figures in this chapter are not our own quotes but a summary of publicly published survey information. According to the IT comparison site System Kanji (Japanese), app development typically runs ¥1,000,000–5,000,000. That range covers everything from small internal efficiency tools to full mobile apps with membership and payments, so the first thing that matters is knowing where the thing you want to build sits.
“App” is one word, but an internal efficiency tool, a web app that runs in the browser, and a smartphone app installed on a device need different technology and different effort.
Internal efficiency tools have no store review and a limited set of users, so features are easy to narrow and costs are easier to contain. Web apps run in the browser, so there is no store review and covering both iOS and Android is straightforward. Smartphone apps add per-OS review handling and testing on real devices, which pushes the effort up. Deciding which form to build first is the first fork in the road for cost.
| Type | Characteristics | Cost tendency |
|---|---|---|
| Internal business tool | No store review, limited users | Easy to narrow features; the most containable of the three |
| Web app (runs in the browser) | No store review, easy to cover iOS and Android | Less effort than a smartphone app |
| Smartphone app (store distribution) | Per-OS review and testing on real devices | Review handling adds effort |
You will sometimes see ads like “apps built from ¥100,000”. Most of those reuse a near-template structure, or the price is mainly a monthly no-code tool subscription. For original features built from scratch, treat the ¥1,000,000-and-up level above as the going rate.
Why is the range so wide? Most development quotes are built on a “person-month unit price”. In Iridge’s explanation (Japanese), that unit price runs ¥400,000–1,600,000. That is the cost of one engineer or designer working for one month; the larger the app, the more people and months are involved, and the total grows multiplicatively.
For a sense of scale and price, here are the figures we publish on our own service page.
| App scale | Roughly what it contains | Typical market rate |
|---|---|---|
| Simple tool | Recording, calculating, displaying | ¥1,500,000–4,000,000 |
| Mid-size | Membership, database integration | ¥4,000,000–10,000,000 |
| Large | Payments, complex business systems | ¥10,000,000 and up |
The “typical market rate” column is one way of reading published prices from development firms and industry surveys. The real number moves by hundreds of thousands of yen even within the same “mid-size” bracket, depending on feature count, external integrations and how far the design is worked. Use it to place your own requirements on the scale.
What a quote is made of: why a “small feature” costs millions
App development quotes are generally built by stacking up the following phases.
- Requirements definition: putting into words what will be built, who uses it, and what counts as finished. A mismatch here becomes rework across every later phase
- Design: deciding screen structure, how data is held, and how external services connect
- Development: actually writing the code. The largest block of effort, and the phase AI changes most
- Testing: confirming it behaves as intended under various conditions. Smartphone apps also need checks per device and OS version
- Maintenance: post-launch bug fixes and keeping up with OS updates
Even an app that looks like “just some buttons in a row” carries person-month effort at ¥400,000–1,600,000 across all five phases. An app that appears to “just record how much time you spent” changes enormously in required design and implementation depending on whether the data lives only on the device or syncs across several, and whether it has notifications. “Looks simple” and “is simple to build” are not the same thing.
One more thing to confirm as a premise for any quote: the contract type. Under Japanese law, app development contracts split broadly into two types: a work-completion contract (請負, ukeoi — a fixed price for a finished deliverable, with the contractor liable for defects) and a quasi-delegation contract (準委任, jun-inin — payment for time and effort, closer to time-and-materials). Work-completion suits projects whose specification is fixed from the start; quasi-delegation suits MVP and AI development where the specification is found by trial and error.
How additional requests generate cost depends on which of the two you signed. When comparing quotes, before the size of the number, check whether all five phases are included, which contract type it is, and what falls outside as a separate charge.
What AI app development changed: from person-months to building small
From here on is my own experience. Now that AI can write most of the code, the person-months in that “development” phase are structurally falling. Instructing in natural language, letting AI implement, and having a human review and finish it — sometimes called vibe coding — has moved past hobby territory and become ordinary in real work.
The big changes are mainly in the development and testing phases. Putting requirements into words, and judging what should be built at all, remain human work. With less manual output required, people can spend the time on deciding what to build and whether it is truly needed. For the same requirements, a quote that assumes AI and one that does not now differ in the estimate of development effort itself.
That said, publishing AI-generated code without review is risky. In apps that handle personal data especially, human checking is essential.
We have taken several of our own apps from concept to App Store release with AI at the center of development: the meditation app Sati, Token Map for tracing the locations of Japan’s famous and National Treasure swords, and the reading-notes app Booket. None of them carries a large membership system or payments — they are simple tool apps with a tight feature set.
Concept to release in about a week
To be concrete about time: from concept to App Store release takes roughly one week. Not several months. A week.
Why that is possible comes down to one thing: the AI models we use have become a different animal over the past year. Implementation speed and quality have reached a level the old intuitions cannot explain. Put differently, quoting without having felt that change means the number still gets stacked on the assumption that “apps take months”.
Honestly: the technical gap has mostly disappeared
What follows is the part people in this industry dislike hearing.
I think there are almost no companies left in this industry that do not use AI in development. And frankly, what AI builds comes out better than what is built by hand alone — that is my experience. Even on performance, it is no longer unusual for AI-written code to be the faster one. 3D and open-world work is still hard, but outside of that, AI is the only sensible choice.
In other words, AI output has shrunk the technical gap between production companies to almost nothing. So what does create a difference? Direction — the planning that decides what to build. People who can do that are, I believe, genuinely rare even inside large firms. Land on one of them and you get something very good.
I hear the opposite story too. A game app commissioned from a large firm under an influencer’s lead came out after a year and ¥20–30 million, and was startlingly thin. My read is that a long stretch of time and labor was spent striking the pose of “we are doing this properly”. It is a pointed way to put it, but that is how it looks to me.
What I want to say to the client side is this: ask whether they use AI. A company that uses it but will not say so gives you reason to suspect they want the build to look long so the price can stay high. We do not hide that we build everything with AI, and we run operations with AI too. We promise to keep chasing the leading edge of the technology and to deliver it.
If that is the case, a one-person firm or a local production company whose face you see every day and who is fully committed every day will be dramatically faster. It does not have to be us. Now that the technical gap has narrowed, the selection criterion has moved from “size” to “who will look after this, and how seriously”.
One caveat: a client who is not familiar with AI cannot produce that same speed alone. It takes skill in giving instructions and an eye for reviewing. Outsourcing precisely because you do not have that is an entirely correct decision.
Our own contracted app and system development sits on the same line. Rather than large greenfield builds, it is mostly spot development that solves a business problem in the smallest possible configuration — for example a site build for a robot outsourcing service and partial feature development for a CRM support center. We have also published a record of prototyping an attendance app with Figma Make.
How to order in a way that keeps costs down
There are five things the client side can do to keep the budget realistic.
1. Narrow the features to an MVP
Try to pack in every feature you want from the start and the scale jumps to “mid-size” or beyond immediately. Launching with a minimum configuration (MVP) that solves only the single most pressing problem, then adding features as you watch the response, keeps the total smaller. For example, park the membership feature for now, launch in a state where information can simply be viewed, confirm demand, and expand from there.
2. Confirm first whether you really need to build it
Honestly, it is not rare for a problem that an existing SaaS or no-code tool would solve to get built from scratch anyway. If an API integration with a spreadsheet or an existing business system is enough, a newly developed app may not be necessary at all. Before you talk to a development firm, spend some time looking for an existing service with similar features. It reduces sales opportunities for the development firm, but it is the cost cut that works best for the client. Concretely: if the requirement is “share stock levels internally”, try whether an existing inventory SaaS or a spreadsheet integration covers it before building a dedicated app. A requirement that would run into the millions from scratch can land at a few thousand to a few tens of thousands of yen per month as a combination of existing services.
3. Write the requirements down before you talk to anyone
Putting “what”, “for whom”, and “what counts as finished” into writing in advance — even roughly — reduces the development firm’s requirements-definition effort and improves the accuracy of the quote. A single page of bullet points shortens the back-and-forth far more than talking through the image in your head.
4. In quotes, confirm what is included
Before comparing figures, confirm how far the quote covers across requirements definition, design, development, testing and maintenance, and whether the contract is work-completion or quasi-delegation. Whether post-launch running costs (covered in the next chapter) are inside the quote is another thing to settle before signing. Also confirm in the contract whether the source code and copyright of the finished app transfer to you. Sign with that left vague and you may find you cannot even receive the source code when you later want to change development firms.
5. Order in phases
Commissioning only requirements definition and design first, then signing the development contract once the content is settled, is another effective approach. Rather than contracting for the whole thing up front, you see the result of the first phase and move to the main figure only when you are satisfied. Just covering these five changes the final quote for the same requirements.
Maintenance and running costs: what you pay beyond development
An app is not finished at launch. You need to know the continuing costs in advance.
- Store registration fees: publishing on iOS requires the Apple Developer Program annual fee of US$99; publishing on Android requires the Google Play registration fee of US$25 (one time only).
- Server and infrastructure: a configuration that uses servers incurs usage-based charges or a fixed hosting fee. If you build it as a web app, this becomes the center of your running costs.
- Fixes and updates: the cost of keeping up with OS version upgrades, and of bug fixes and new features. Additional feature development usually restarts from requirements definition, just like a new quote.
At the quoting stage, ask for these three to be stated as monthly and yearly figures. Judging “cheap” on development cost alone can leave unexpected costs stacking up after launch. Comparing on a “total over several years” that combines initial development with these continuing costs keeps you from being swayed by the size of the quote alone. These costs are sometimes presented together as a maintenance contract and sometimes settled as they occur. Which of the two it is, is also worth confirming before signing.
What to look at when choosing who to commission
Just as important as negotiating price is judging the partner. Comparing on money alone causes trouble later.
Is their work published concretely?
“Numerous development projects” with no detail on what was actually built gives you nothing to judge on. Choose a company that publishes what problem was solved, and at what scale. We publish the app and system development we have handled on our work page.
Does the point of contact continue after launch?
There is a large difference in long-term peace of mind between a company that finishes at delivery and one where the same contact handles post-launch bugs and improvements. Asking “who handles things after launch?” at the quoting stage tells you a lot about a company’s stance.
Do they show you something working early?
AI development produces something usable soon after kickoff, so “will they show me something I can touch early?” is another way to judge an outsourcing partner. If you are shown nothing until the build is nearly complete, you notice a mismatch in direction far too late.
An individual developer, or a company?
On cost alone, commissioning an individual developer is easier to contain. But the setup depends on one person, so illness, departure and the presence of continuing maintenance are all less certain than with a company. A company costs somewhat more but can be expected to provide a consistent setup covering review handling and maintenance. Rather than one being right, it is a question of whether you prioritize cost or setup. These four are things a written quote alone will not tell you. It is worth checking them in the first conversation or meeting.
How we work
We have covered market rates, what a quote contains, ways to reduce cost, post-launch running costs and how to judge a partner. Finally, our own approach.
For app and system development we start with a hearing and then provide a rough estimate. Unlike website production, we do not use package pricing, because scale varies enormously with requirements. During the hearing we also state, on the spot, every recurring real cost such as store registration fees. We work on Android and web apps as well as iOS, so please get in touch either way.
The process has four steps: (1) consultation and requirements sorting, (2) a quote (free), (3) AI development with human review throughout, and (4) review and release. Conversations at the “still just an idea” stage are welcome too.
We apply what we learned publishing and running three of our own apps on the App Store directly to contracted work. It is fine to arrive not knowing where to start. Begin with a free consultation and tell us what you want to build and the budget you have in mind.
FAQ
What is the minimum budget for commissioning an app?
At typical market rates, a simple tool app centered on recording and displaying starts around ¥1,500,000. As AI development spreads, a tightly scoped feature set can bring that down further. The exact figure depends on requirements, so the fastest route is a rough estimate from a free consultation.
Should I commission an individual developer or a company?
On cost alone an individual developer is easier to contain, but there are risks around setup and continuing maintenance. A company is easier to hand maintenance and store review to, at a somewhat higher cost. Rather than price, we suggest judging on whether they publish their work concretely.
What should I check when comparing quotes?
Before the size of the number, check that all five phases — requirements definition, design, development, testing and maintenance — are included. Also confirm before signing whether post-launch running costs such as store registration and server fees are charged separately.
Are there costs after development finishes?
Yes. iOS carries the Apple Developer Program annual fee of US$99 and Android the Google Play registration fee of US$25 (one time only), plus continuing server and improvement costs. It matters to have these real costs stated at the quoting stage.
