App development cost in Japan: prices by app type, and what outsourcing changes

What decides app development cost in Japan?

Four things decide it: how much the app does (screens, roles, features), how much sits behind it (back end, admin, integrations), how polished it must be (custom design, animation, testing depth), and how the vendor charges (man-months or fixed scope). The country the developers work in changes the rate, but these four change the amount of work.

An app is rarely just an app. A salon booking app, for example, is a customer app, a staff view, an admin panel for services and prices, push notifications, reminders, and a server that holds it all together. Many first estimates in Japan surprise buyers because the part they cannot see, the back end, is half the work.

Our starting price for the app itself is US$600; admin panels and APIs start at US$900. Rather than quoting ranges we cannot justify, we ask for your screen list and quote it line by line. We do not state other vendors’ prices; they vary widely, and the sections below explain why.

How do Japanese vendors price apps in man-months?

Many Japanese development companies estimate in man-months (ninetsuki): the number of people multiplied by the months they work, multiplied by a monthly rate that differs by role. The estimate therefore depends on team size and schedule as much as on features.

A typical estimate lists requirements definition, basic design, detailed design, development, testing and release as phases, each with man-months for a project manager, engineers and testers. Senior roles cost more per month. It is a transparent way to price effort, and it suits large projects where requirements change during the work.

The risk for a buyer is that man-months measure time, not outcomes. If a project runs long, more months are billed. When you compare an estimate in man-months with a fixed-scope quote, convert both into the same terms: what exactly will be delivered, when, and what happens if it takes longer. That comparison is more useful than the headline number.

• Man-month quote: pays for effort; flexible scope; time risk on you.
• Fixed-scope quote: pays for a defined result; changes re-quoted; time risk on the vendor.
• Either way: insist on a written list of screens and features.

App development cost by app type: booking, ecommerce, membership and marketplace

Cost climbs with the number of user types and the amount of money or data moving between them. A one-sided app for your customers is the cheapest; a two-sided marketplace with payouts is the most expensive.

Which features make an app expensive?

Features that involve real-time data, offline storage, money movement, or other companies’ systems cost the most, because each needs extra logic and testing on both iOS and Android. Screens that only display information cost the least.

When a quote feels high, look at this list. Each item is worth doing if your users need it, but each also has a cheaper version. Chat can start as a link to LINE or WhatsApp. Offline mode can start as “save the last loaded list”. Maps can start as an address link that opens the phone’s own map app.

• User accounts with several roles and permissions.
• In-app payments, subscriptions or payouts to sellers.
• Real-time chat or live location tracking.
• Offline mode with syncing when connection returns.
• Integration with POS, CRM, ERP or an existing database.
• Custom animation and complex design systems.
• Multiple languages, including right-to-left scripts.
• Admin dashboards with reports and exports.

Does Flutter or React Native lower app development cost in Japan?

Yes, for most business apps: one cross-platform codebase serves both iPhone and Android, so most features are built and tested once instead of twice. Separate native apps in Swift and Kotlin still make sense for apps that push device hardware hard, such as heavy 3D or specialised camera work.

We build in Flutter or React Native and choose per project. Flutter gives consistent visuals across devices; React Native fits teams that already use React on the web. Both handle Japanese text input, push notifications, payments and maps well. The saving is not just the first build: every future update is also made once.

Ask any vendor which approach they propose and why. If a quote prices iOS and Android as two separate builds for a standard booking or membership app, ask whether a cross-platform build would meet your needs. The answer is usually yes.

How a phased MVP cuts the cost of building an app

Build the smallest version that tests your main idea with real users, then spend the rest of your budget on what they actually use. A phased plan turns one large, risky estimate into smaller ones you approve one at a time.

Phase one might be a single user type, the one core action, sign-in, and a simple admin page. Phase two adds the features early users ask for most. Phase three adds scale: performance work, reports, more integrations. Each phase has its own quote, so you are never committed to spending on features nobody wants.

This is especially useful for startups and for companies testing a new service. Investors and managers also find a working phase-one app far more convincing than a specification document. Our page on MVP development for startups goes deeper on choosing the first scope.

• Phase 1: one user type, one core action, basic admin.
• Phase 2: features requested by real users.
• Phase 3: scale, reporting and integrations.

App Store and Google Play fees for apps in Japan

Budget for Apple’s developer programme at US$99 a year and Google Play’s one-time US$25 registration, plus commission on digital goods sold in the app. Physical goods and services, such as restaurant orders or salon bookings, generally use your own payment provider rather than store billing.

Commission rules in Japan changed recently. Apple announced changes to comply with Japan’s Mobile Software Competition Act, which came into effect on 18 December 2025, including a reduced App Store commission for most developers, a separate fee for using Apple’s in-app purchase, and options for alternative app marketplaces and payment processing. Check the current terms in App Store Connect and Play Console before you set prices.

Both store accounts should be opened in your company’s name. Apple requires organisations to enrol with their legal entity details, and account verification can take time, so start early. We publish the app under your accounts; we never publish a client app under ours.

Apple’s summary of the Japan changes is on Apple Newsroom.

Back end, admin panel and hosting: the costs people forget

Almost every business app needs a server that stores data and an admin panel where your staff manage content, users and orders; with us these start at US$900. Hosting then costs a monthly amount that grows with users and data.

There are two ways to keep this part affordable. First, use managed services where they fit: authentication, file storage, push notifications and databases can be rented rather than built. Second, keep the admin panel simple at launch: lists, edit forms and a few exports, not a full analytics suite.

Where your company already has systems, such as a web shop, a reservation service or a customer database, the app can read from them through an API instead of duplicating data. That often costs less than a new back end, provided the existing system has a usable API. We check that before quoting.

What does app maintenance cost each year?

Plan for continuing maintenance, because Apple and Google release new operating system versions every year and periodically raise the requirements apps must meet to stay listed or be updated. An app that nobody maintains eventually stops working well or cannot be updated.

Maintenance covers compatibility updates, library upgrades, security fixes, crash monitoring and small changes. With us, the first two months after release are free, and then care starts from US$120/mo. Hosting and third-party services are billed separately by those providers.

New features are not maintenance. They are quoted separately, approved by you, and planned into releases. Keeping these two budgets apart makes it easier to see what the app really costs to keep alive versus what you are choosing to invest in growth.

Japan-specific cost factors: language, payments, LINE and APPI

Japanese apps often need a few local features that add cost: Japanese UI text and fonts, local payment methods for physical goods, LINE login or messaging, and privacy handling under the Act on the Protection of Personal Information (APPI).

Japanese UI text is supplied or approved by you; we build the language files and make sure longer or shorter strings fit on small screens. For payments, card and wallet methods are standard, and some businesses want convenience-store payment for orders; see konbini payment integration. Many Japanese users prefer signing in with LINE, and some services are better delivered through a LINE chatbot than an app at all.

For personal data, the app collects only what it needs, encrypts data in transit, limits admin access, and keeps logs. If data is stored on servers outside Japan, APPI has rules for providing personal data to third parties abroad; your counsel confirms what your privacy notice and consent screens must say. Compliance is your responsibility; we build the controls.

Free, paid or subscription: how your revenue model changes the build cost

How the app earns money changes what must be built. A free app that supports an existing business is the simplest; a subscription app needs purchase flows, entitlement checks, restore-purchase handling and store configuration on both platforms, which adds real work and testing.

Free companion apps, such as a clinic’s booking app or a retailer’s points card, earn their keep by saving staff time or bringing customers back. They need no store billing, so the budget goes into the features themselves. Apps selling physical goods or real-world services usually take payment through your own payment provider, which means a checkout integration rather than store billing.

Apps selling digital content or features, such as premium lessons, extra storage or ad-free use, fall under store billing rules or the alternatives now allowed in Japan. Subscriptions add screens for plans, trials, cancellation information and server-side checks that a paying user really has access. Each of those is modest on its own, but together they can add a meaningful share to the app development cost in Japan, and they need careful testing in each store’s sandbox before release.

Advertising-funded apps need consent handling for tracking and an ad network integration, and they only pay back at large user numbers. For most business apps we suggest proving usage first and adding a revenue feature in phase two, when you know what users value enough to pay for.

Hidden costs in app projects and how to spot them

The hidden costs are usually design revisions, testing devices, store review rejections, third-party service fees, and content your team must prepare. None is large alone, but together they explain why many app budgets overrun.

• Design rounds beyond those in the quote.
• Store review rejections needing changes and resubmission.
• Push notification, SMS, maps or email service fees.
• Screenshots, descriptions and privacy details for store listings.
• Test accounts and data for store reviewers.
• Legal review of terms and privacy policy by your counsel.
• Staff time to answer users and moderate content.

Our quotes list what is included and what is not, so these items appear before you approve rather than after launch.

How long does it take to build an app, and does time change the cost?

With us, most first versions take six to ten weeks for the app and six to twelve for a larger back end, and our quote is fixed to the scope rather than the calendar. With man-month pricing, time directly changes the cost, which is why schedule matters so much in Japanese estimates.

Time usually goes on four things: agreeing the screens, designing them, building and testing, and store review. Store review for a first release can take longer than updates, so we submit early builds for testing through TestFlight and Google Play’s testing tracks while the final work continues.

If your date is fixed, such as a store opening or an event, we cut scope rather than rush quality: the launch version does the core job well, and the rest follows in an update a few weeks later.

Sample budgets for three hypothetical apps

These scenarios are invented to show how a budget is built from our starting prices; they are not client projects. Convert the USD figures to yen at the day’s rate for your own planning.

Who owns the app, the code and the store listings?

Your company should own the source code, the Apple and Google developer accounts, the server accounts, and every signing key and certificate. Without these, you cannot update your own app if you change vendors.

We work in your repository from the first day, publish under your store accounts, and hand over build instructions, environment settings and documentation. If you later hire another developer or build an in-house team, they start from a complete, working project.

Before signing with any vendor, check that the contract says the code belongs to you on payment, that store accounts will be in your name, and that you will receive signing keys. These three points protect the whole investment.

Working with an app team in India from Japan

India is three and a half hours behind Japan, so we overlap with your afternoon from about 12:30 pm JST. Weekly calls review a new test build; between calls, questions go through WhatsApp, answered seven days a week.

We work in English. Short messages in Japanese are fine, and we confirm understanding in simple English before building anything significant. The estimate is in USD, and each milestone can be paid in USD or JPY through Wise or bank wire. Invoices come from India; consumption tax treatment is for your accountant.

Comparing offshore locations? Read India vs Vietnam for offshore development.

App budget checklist before you request quotes

Prepare a screen list, user types, must-have integrations, a target launch date and your maintenance expectations before asking for quotes. With those, vendors can quote accurately and you can compare fixed-scope and man-month estimates on equal terms.

• List of screens, even as rough sketches.
• User types and what each can do.
• Payments: what is sold, and through which method.
• Existing systems the app must talk to.
• Languages needed at launch.
• Launch date and whether it is fixed.
• Store accounts ready in your company’s name.
• Who will maintain the app after release.