Android and iOS app developer in Japan, serving Tokyo, Osaka, Nagoya and all 47 prefectures

Who builds your app, and which projects in Japan we suit

BtechWaleTech is a three-person engineering team in India. One of us is our full stack developer and writes the app screens, the API and the integrations. Another of us covers AI and machine learning, AWS, data, deployment and technical SEO, which in app projects means the cloud back end, analytics and release pipelines. The third of us owns delivery, keeping scope, schedule and testing on track, and also works on data science, AI and automation. When you message us about an app, one of the three answers, and the same three build and publish it. Nobody sits between you and the code, and nothing is passed to a subcontractor.

Honesty matters more in app work than in most projects, because an app sits on your customers' phones under your company's name. So, plainly: we have no office, business registration, staff or address in Japan, and we do not meet clients in person. We work in English, and nobody on the team writes natural Japanese. This page does not list Japanese clients, testimonials, awards or partner badges, because we will not invent them. What we offer is direct access to the engineers, a written scope, test builds you can install on your own phone throughout the project, and starting prices well below typical Japanese アプリ開発 (app development) quotes.

We suit companies that can work in English or have one bilingual person in the chat: Japanese arms of overseas groups, founders from abroad in Tokyo, Fukuoka and Osaka building a first product, inbound tourism businesses that need apps in English, Chinese and Korean, and Japanese small and mid-sized companies whose owners want a practical member, booking or ordering app without a multi-million-yen budget. We are a weaker fit if your team works only in Japanese and nobody can review text, if you need on-site requirement workshops, or if you need a subsidy-registered vendor.

App projects also need decisions that only you can make: which features matter at launch, how points or bookings work, who approves the store listing and who answers customers after release. We help you make those decisions in writing, with a screen list and feature list you approve before any code is written. For a wider view of what we build for Japan, including websites, SEO and custom software, see our Japan page.

Apps we build for businesses in Japan

Most business apps in Japan fall into a handful of patterns. Each one below is built as a single Flutter or React Native codebase for iPhone and Android, with an admin panel your staff use in a browser and an API that connects the two. Buyers often search for スマホアプリ 制作 (smartphone app production) or アプリ開発 外注 (outsourced app development) when they reach this stage, and these are the projects behind those searches.

• Membership and point card apps (ポイントカードアプリ). A digital member card with a QR code or barcode scanned at the till, stamp or point balances, coupons, news and push notifications. Common for cafés, bakeries, salons, drugstores and regional supermarkets replacing paper stamp cards. Points rules, expiry and the link to your point-of-sale system are scoped first, because they decide most of the cost.
• Booking apps for salons, clinics and restaurants. Staff and menu selection, open slots, reminders, cancellation rules and a visit history. Many Japanese salons and restaurants already take bookings through portals, so the app usually focuses on regular customers and direct bookings rather than replacing every channel.
• Ecommerce apps. A shopping app on top of an existing Shopify or custom store, with saved addresses, delivery date and time-slot choice, repeat orders and app-only coupons. Physical goods can be paid by card, konbini or code payment through a payment provider.
• Staff and field-work apps. Inspection checklists, photo reports, timesheets, delivery confirmations and maintenance logs for construction, facility management, cleaning, logistics and care services, with offline mode for basements, tunnels and rural sites.
• B2B ordering apps. Wholesale customers such as restaurants, shops and contractors reorder from their own price list, see delivery cut-off times and stop sending orders by FAX or phone.
• Inbound tourism apps. Guides, maps, tickets, audio tours and coupons in English, Simplified Chinese, Traditional Chinese and Korean for attractions, shopping streets, ski resorts and transport operators.
• Startup MVPs. A first version of a consumer or B2B product for founders in Tokyo, Fukuoka or Osaka, built to test demand with real users before a larger investment.
• Progressive web apps. When store distribution adds cost without adding value, we build a web app that installs from the browser instead, covered in its own section below.

Every app includes the admin panel and API behind it. If your project is mostly a browser-based system with a small app on top, the software development in Japan page explains how we scope custom systems, and our general Android and iOS app development service page describes the app plan in more detail.

What app development costs in Japan in 2026, and what we charge

Japanese companies comparing quotes usually start with price guides published by agencies and comparison sites such as Web幹事, システム幹事 and 発注ラウンジ, which gather typical アプリ開発 費用 (app development cost) figures from Japanese development companies. Their 2026 guides describe the ranges below. They are market ranges, not quotes from any particular company, and every app varies with scope. Our column shows starting prices, with yen worked out at ¥155 to the dollar.

How to read the comparison. A Japanese quote for both platforms often means two native apps, one written in Swift for iPhone and one in Kotlin for Android, each with its own developers and test cycle. Our starting price assumes one cross-platform codebase, a clearly scoped first version and an admin panel built from proven components. Compare like with like: ask each vendor how many codebases they will write, who builds the back end, whether store submission is included and what maintenance costs after launch.

Exchange rate. We price in US dollars, and the yen moved between roughly ¥153 and ¥157 per dollar in September 2026. If your budget is fixed in yen, we write a JPY amount into the quote, so the number you approve is the number you pay.

Costs outside the build. Every app has running costs that go to other companies: Apple and Google developer fees, cloud hosting, push notification and email services, map or SMS APIs, LINE Official Account plans and payment fees. We list the expected ones in the quote so the full cost of owning the app is clear before you commit. Scope guidance for all our plans is on the pricing page.

What our starting prices buy, and why they are lower

A starting price is only useful if you know what sits inside it. These are the plans that matter for app projects in Japan, and what each one typically covers.

• From US$600 (about ¥93,000), Android and iOS app: a single Flutter or React Native codebase serving both iPhone and Android, with login, a set of core screens, forms, push notifications, an admin panel for your staff, an API and publication on the App Store and Google Play under your developer accounts. A typical example is a member app with a digital card, points, coupons and news.
• From US$900 (about ¥140,000), custom web app: the heavier back end some apps need, such as a booking engine with staff rosters, a B2B ordering system with customer-specific prices, or a dashboard several departments use every day.
• From US$600 (about ¥93,000), AI automation: one workflow around the app, such as enquiries from the app routed to kintone and Chatwork, AI-OCR for paper orders, or a support assistant that answers from your own FAQs.
• From US$120/mo (about ¥19,000/mo), maintenance: fixes, small changes, OS and dependency updates and store review support, with the first two months after launch free.

What raises an app quote. Payments inside the app, integration with an older point-of-sale or core system, offline sync, several user roles, real-time features such as chat or live location, many languages and a fixed launch date that compresses the schedule. What keeps it down. A clear first version, standard screen patterns, content and images supplied on time, one decision-maker and features that can wait for version two.

Why our prices are lower than Japanese quotes. Three things. We write one cross-platform codebase instead of two native apps. We have no office in Tokyo or Osaka, no sales staff and no directors between you and the engineers. And there is no multi-layer subcontracting, where a prime contractor passes development to second and third-tier firms and each layer adds its margin. We are three engineers working remotely, and the saving comes from that structure, not from skipping testing, documentation or security work.

What a lower price does not include. Japanese copywriting, professional photography, in-person training, on-site meetings and a Japanese-speaking support desk for your customers. If you need those, budget for them separately or choose a local vendor. If you are unsure which fits, ask through our contact page and we will give you a straight answer.

Japan's mobile market: design for iPhone first, but never iPhone only

Japan stands out among large markets because the iPhone holds a larger share of smartphones there than in most countries. For a consumer app in Japan, the iPhone version is usually what customers judge first, and people used to well-made apps from banks, rail operators and convenience store chains notice clumsy scrolling, odd fonts or a web page pretending to be an app.

Android still matters. Many older customers, staff using company-issued phones and buyers of lower-priced models are on Android, and rugged Android handsets are common in logistics and field work. Skipping Android usually means losing a noticeable share of customers or staff. A cross-platform app gives both groups the same features from the first release, with iPhone-specific polish where it counts.

Screen sizes vary widely, from compact phones that people keep for years to large Android devices and the tablets used at shop counters. We design for small screens first, because tap targets, Japanese text and forms break there before anywhere else, and we test with the system font size turned up, since many older users enlarge text.

Everyday habits shape features. QR codes, which were invented in Japan by Denso Wave, are part of daily life, from code payments to event tickets, so scanning and showing codes is standard in member and ordering apps. Cashless payment by card, transit IC card and code payment is widespread, and LINE is how many customers already hear from shops, clinics and restaurants. A good app in Japan fits into those habits instead of asking people to learn new ones.

Flutter, React Native or native Swift and Kotlin?

Buyers searching for Flutter 開発 (Flutter development) or React Native development usually want to know one thing: can one codebase really feel right on both platforms? For the kind of apps most businesses in Japan need, yes. Member cards, bookings, catalogues, ordering, checklists and forms are all well within what cross-platform frameworks handle, and the saving over two native apps is large.

Flutter, maintained by Google, renders its own widgets, so the interface looks identical on every device and custom designs, animations and brand-heavy screens are straightforward. It needs one extra detail for Japan: when an app does not declare Japanese as its locale, Flutter can fall back to Chinese glyph shapes for some kanji, because Chinese and Japanese share Unicode code points but draw certain characters differently. We set the locale and font fallbacks so Japanese users see the Japanese form of every character.

React Native, maintained by Meta with a large open-source community, uses each platform's native components and suits teams that already work in TypeScript or run a React website, because business logic can be shared. Expo, a popular React Native toolchain, speeds up builds, store submission and over-the-air updates for JavaScript changes within the stores' rules.

Native Swift and Kotlin remain the right choice for a small set of apps: heavy real-time audio or video processing, advanced augmented reality, deep use of brand-new operating system features on launch day, or projects that already have a large native codebase. If your app is in that group we will say so, and the quote will reflect two codebases.

Whatever the framework, the native layer still needs native knowledge: push notification keys, background location permissions, deep links, in-app purchase setup, privacy manifests and store signing. Those details, not the screens, are where cross-platform projects most often go wrong, and they are part of our standard build rather than an extra.

When a progressive web app or a LINE mini app beats a store app

Not every business needs an app in the App Store. An app costs money to build, carries yearly store fees and needs updates whenever Apple or Google changes something. Before quoting a store app, we ask how often a customer will open it. A restaurant that sees a customer twice a year, or a clinic with annual check-ups, rarely persuades people to download an app, however good it is.

Progressive web apps (PWAs) are websites that can be added to the home screen, keep working offline for cached screens and, on current iPhone and Android versions, receive web push notifications once installed. They need no store review, and every update is live immediately. For B2B ordering portals, internal tools on company phones and booking pages linked from Google Maps or Instagram, a PWA is often the better investment. The website developer in Japan page covers the web side of these builds.

LINE-based apps. Many Japanese customers would rather not install another app but already follow shops on LINE. With LIFF, the LINE Front-end Framework, a membership card, booking form or order screen opens inside LINE, and the Messaging API sends reminders through your LINE公式アカウント (LINE Official Account). LINE also runs a separate LINE MINI App programme with its own review process. For a salon or café, a LINE-based member card can be a sensible first step, with a store app added later if usage justifies it.

Store apps earn their cost when people use them weekly or daily, when dependable push notifications matter, when the app needs the camera, Bluetooth, NFC or background location, when staff work offline, or when being found in the App Store is part of your marketing. We are happy to recommend starting with a PWA or a LINE flow and building the store app once the numbers support it.

Publishing on the App Store and Google Play from Japan

Store accounts belong to your company, not to the developer. You enrol in the Apple Developer Program and open a Google Play developer account as an organisation, then add us as team members with the roles we need. Both stores ask organisations for a D-U-N-S number, the nine-digit business identifier from Dun & Bradstreet, and Apple also checks that the person enrolling has authority to sign for the company. In Japan, D-U-N-S numbers are administered by Tokyo Shoko Research, where you can check whether your company already has one; Apple can also request one for you free of charge, which can take a week or two. Start this early, because a store account registered in a developer's personal name is very hard to move later.

The store fees are set by Apple and Google and paid by you directly: the Apple Developer Program costs US$99 a year (or the local price Apple sets for Japan), and Google Play charges a one-time US$25 registration fee. Neither is part of our price, and both accounts stay with your company whoever maintains the app.

Japanese store listings. Both stores let you localise the app name, subtitle, description, keywords, screenshots and preview video for Japanese. The listing is marketing copy, so it should be written by a native speaker; we prepare the structure, screenshot sizes and keyword fields, and your side writes or approves the Japanese. Store search behaves like web search, with kanji, katakana and English variants of the same idea, so the keyword field deserves the same care as a web page title.

Review. Apple reviews every build against its App Review Guidelines, and Google Play combines automated checks with policy reviews. Common reasons for rejection include missing in-app account deletion, a login wall before users can see what the app does, incomplete privacy details, a demo account that does not work for the reviewer, and payment flows that break in-app purchase rules. We submit with reviewer notes and a working demo account, and we handle the back-and-forth if questions arrive.

Developer name and support contact. The developer name appears on every store listing, and Google Play shows developer contact details. Make sure the legal name and support email match your company profile, because Japanese users check who publishes an app before they trust it with points, payments or personal details.

Payments in apps: store rules, Japan's smartphone act, PayPay and konbini

Payment design is where app projects in Japan most often need a careful decision, because the store rules depend on what is being sold. Under Apple's App Review Guidelines and Google Play's payments policy, digital goods and features used inside the app, such as premium content, subscriptions to app features or virtual currency, have generally had to use the store's in-app purchase system, with the store taking a commission. Physical goods and real-world services, such as products shipped to a home, takeout orders, salon appointments or event tickets, are paid through ordinary payment methods instead.

The Mobile Software Competition Act. Japan's スマホソフトウェア競争促進法 (Mobile Software Competition Act) designates Apple and Google as providers of smartphone operating systems and app stores, and it took full effect on 18 December 2025. It is intended to open the door to alternative app stores and alternative payment options for apps distributed in Japan, and both companies have published Japan-specific programmes with their own conditions and fees. The practical picture for a given app, including which commission applies when a user pays outside the store, depends on detailed terms that are still being refined. We read the current terms for your app type before recommending an approach, and your adviser should review anything contractual. This is not legal advice.

Physical goods and services. For shopping, delivery, bookings and B2B orders, we connect a payment provider that supports Japanese methods. Cards must include JCB alongside Visa, Mastercard and American Express. For Japanese businesses, Stripe handles cards, konbini and bank transfer, while local providers add options such as code payments and deferred payment. With konbini payment, the app shows a payment number and deadline, and the order is confirmed only when the payment notification arrives, so the order flow has to handle a pending state for days rather than seconds.

PayPay and other code payments. PayPay is one of the most widely used code payment services in Japan, and d Barai, au PAY and Rakuten Pay are other familiar options. Each needs a merchant contract and screening in your company's name, and each hands the user over to its own app and back again, a flow we test on real devices. Apple Pay and Google Pay can shorten card checkout for physical goods.

Points and prepaid balances. Point programmes are a normal part of Japanese retail, but a balance that customers buy with money in advance can count as a prepaid payment instrument under the Payment Services Act (資金決済法), while points given free as a bonus on purchases generally do not. If your app will sell prepaid value or let customers buy points, ask your adviser early, because the answer changes how the feature, the records and the refund rules should be designed.

LINE Login, LINE messaging and push notifications without fatigue

LINE has more than 100 million monthly users in Japan, according to LY Corporation's figures for the end of 2025, and for many customers it is the default way to hear from a business. Apps for Japan therefore often combine three channels: push notifications from the app itself, messages through a LINE Official Account, and email for receipts and account matters.

LINE Login. Signing in with LINE removes a password step and gives you a LINE user ID to link to the member record, which in turn lets you send LINE messages to the right person. We store that link on your server, request only the profile permissions the feature needs and let users unlink. On iPhone, Apple's guidelines generally require an app that offers third-party login to offer an equivalent privacy-focused option as well, and Sign in with Apple is the usual way to meet that.

LINE messaging. The Messaging API can send booking reminders, shipping updates, point balances and coupons, and can receive customer messages for a support flow. LINE Notify was shut down in March 2025, so staff alerts that relied on it have to be rebuilt on the Messaging API or moved to Slack, Chatwork or Microsoft Teams. LINE Official Account plans include a set number of messages, so we design flows that send fewer, more useful messages.

Push notifications. iPhone and recent Android versions both ask users for permission before showing notifications, and a refused permission is hard to win back. We ask at a moment when the benefit is obvious, such as right after a booking, rather than at first launch, and we split notifications into categories users can switch on or off: bookings, points, campaigns and news. Push goes through Apple Push Notification service and Firebase Cloud Messaging, with the sending logic on your server so staff can schedule messages from the admin panel.

Message fatigue. The fastest way to lose a customer is a daily campaign push. We set frequency caps, avoid late-night sends in Japan time and show opt-outs next to opens in the admin panel, so you can see when messages start to annoy people. Booking confirmations and other service messages stay separate from advertising, so customers never switch off reminders they actually need.

Japanese localisation inside an app: fonts, names, addresses and dates

An app for Japanese users has to handle the language in ways that go well beyond translated labels. These details are engineering work, which is why we can do them properly even though the Japanese words come from your side.

• Fonts and glyphs. iPhone uses Hiragino Sans for Japanese and Android uses Noto Sans CJK, so system fonts usually look right and add nothing to the download size. Custom Japanese fonts contain thousands of glyphs, so we bundle or subset them only when the brand needs it, and we set the Japanese locale so kanji render in their Japanese forms.
• Line breaks and text length. Japanese has no spaces between words, so buttons, headings and notifications can break in awkward places. We apply line-breaking rules (禁則処理) so small kana and punctuation never start a line, and we check every screen with the final Japanese text, which often differs greatly in length from the English draft.
• Names. Family name first, in separate fields, with a reading field in katakana or hiragana (フリガナ) so staff can pronounce and sort names. Sorting in the admin panel follows the reading, not the kanji.
• Addresses and postal codes. A seven-digit postal code fills in the prefecture, city and district from Japan Post's postal code data, and the address continues down to block, building and room number. Delivery apps also keep a separate field for the building name, which couriers rely on.
• Japanese input. Japanese keyboards type kana and then convert to kanji, and the return key often confirms a conversion rather than submitting. Forms must not validate or submit while text is still being composed, and search boxes should wait for the converted text. Full-width and half-width numbers, letters and katakana are normalised instead of rejected.
• Dates, times and money. Dates run year, month, day, often with the day of the week in brackets, and some audiences expect the Japanese era year (Reiwa) as well. Booking screens usually use a 24-hour clock. Consumer prices are shown including consumption tax, with a 税込 (tax included) label where it helps.
• Accessibility. Support for larger system text, VoiceOver and TalkBack labels, enough colour contrast and generous tap targets. Japan's large older population makes this practical rather than optional, and the Act for Eliminating Discrimination against Persons with Disabilities has obliged private businesses to provide reasonable accommodation since April 2024. We apply the WCAG principles behind Japan's JIS X 8341-3 web standard to app screens as well.

Multilingual apps for inbound visitors add English, Simplified Chinese, Traditional Chinese and Korean, each with its own font fallbacks and text lengths. We keep all strings in translation files your translators can edit directly, and add a language switch inside the app so the phone's system language is not the only option.

Offline mode for field staff and B2B ordering apps

Field-work apps are some of the most useful apps a Japanese company can build, and they are also where cheap builds fail first. Staff work in basements, plant rooms, tunnels, mountain sites and rural areas with weak signal, and an app that loses a half-finished inspection report when the connection drops will not be trusted twice.

How we build offline mode. The app stores data in a local database on the phone, writes every change to a queue and syncs with the server when the connection returns. Photos are compressed and uploaded in the background. Each record shows a clear status, such as saved on phone, sending or synced, so staff know what the office can see. Where two people can edit the same record, we agree conflict rules in advance, for example the newest change wins for notes but a supervisor's approval can never be overwritten.

Typical features. Checklists that follow your existing paper forms, photo capture with automatic timestamps, signatures on screen, barcode and QR scanning for equipment and parts, including JAN codes on products, GPS location where staff agree to share it, and PDF reports generated on the server in the layout your customers expect. Many Japanese companies still file stamped paper reports, so the PDF output often matters as much as the app.

B2B ordering. Restaurant owners, shop managers and contractors order from their own price list, repeat last week's order with one tap, see delivery cut-off times and get confirmation instantly. The supplier's staff see orders in the admin panel or in kintone instead of retyping FAX sheets. Where FAX orders continue, the AI automation engineer in Japan page explains how AI-OCR can read them into the same system.

Company phones. Company-issued devices can be managed with mobile device management tools, and internal apps can be distributed privately instead of through a public store listing. We choose the distribution route that fits how many staff use the app and how your IT team manages devices.

The admin panel, API and hosting behind the app

The app on the phone is the visible part. Behind it sit an API, a database, an admin panel for your staff, push notification services and often integrations with your website, point-of-sale system, kintone, Shopify or accounting tools. Japanese quotes sometimes price this back end separately; in ours it is part of the scope from the start.

Admin panel. Staff manage members, bookings, points, coupons, news, orders and push messages in a browser, with roles so a part-time employee cannot export the customer list. Labels can be in Japanese supplied by your team, and we keep screens simple enough for staff who are not technical.

Hosting in Japan. Tokyo and Osaka both have cloud regions from AWS, Google Cloud and Microsoft Azure. With users in Japan, the API and database sit in Tokyo for low latency, and backups are copied to Osaka as protection against an earthquake or a regional outage. Japanese price guides often quote around ¥20,000 a month for app servers; a small app can cost less and a busy one more, and the cloud provider bills your company directly.

Security basics. HTTPS everywhere, tokens kept in the phone's secure storage, no secret keys inside the app, rate limits on login and point redemption, server-side checks on every price and point calculation, and audit logs for admin actions. Point and coupon apps attract abuse, so points are always calculated on the server and never trusted from the phone.

Integrations and the web side. Common links include Shopify for products and orders, kintone for records staff already use, LINE for messaging, Google Maps for store finders, and freee or Money Forward Cloud for invoices. Most apps also need a landing page with store badges, deep links and a privacy policy, which we build alongside the app; our web development service page covers that work.

APPI, store privacy rules, external transmission rules and other app rules

This section summarises the rules we design around when building apps for Japan. It is not legal advice; for formal questions, speak to a lawyer or adviser qualified in Japan.

APPI. Under the 個人情報保護法 (Act on the Protection of Personal Information), your company must state why it collects personal information and handle it securely. In an app that means a privacy policy reachable from inside the app, collection limited to what each feature needs, permission prompts that explain the purpose in Japanese, and deletion of accounts and data on request.

Our access from India. If our team can see your users' personal data, for example in the production database or admin panel, that counts as provision to a third party in a foreign country under the APPI. The usual bases are consent given after the user is told which country is involved and how its data protection works, or a recipient that maintains protection equivalent to the APPI's standards. India's own law, the Digital Personal Data Protection Act, 2023, is coming into force in stages. We build and test with dummy data, keep production access to a minimum, sign data-handling terms and leave the legal basis to your adviser.

Store privacy disclosures. Apple requires App Privacy details describing what data the app and its SDKs collect and whether it is used for tracking, and asks users for permission through App Tracking Transparency before tracking them across other companies' apps. Google Play requires a Data safety section. Both stores require apps that let users create an account to let them start account deletion inside the app. We check every SDK, from analytics to crash reporting, so the disclosures match what the app actually does.

External transmission rules. The external transmission rules added to the Telecommunications Business Act in June 2023 oblige services within their scope to disclose which user information SDKs and tags pass to outside companies, typically analytics and ad networks. Many apps that simply promote a company's own business fall outside the rule, but apps that provide services such as messaging, search, information or marketplaces may be covered. Where the rule applies, the app gets a disclosure screen naming each SDK, the data it receives and the purpose.

Selling through the app. Apps that sell goods online must show the seller information required by the 特定商取引法 (Specified Commercial Transactions Act). Rules in force since June 2022 also require the last screen before an order is placed to spell out the quantity, total price, payment and delivery timing, and cancellation or contract terms, which is where subscription apps most often slip. Prices shown to consumers include consumption tax (10 percent in general, 8 percent for most food). Point campaigns and influencer promotions must also respect the Premiums and Representations Act, including the stealth marketing rules in force since October 2023.

Health, finance and children. Apps for clinics, supplements, lending or children face extra advertising and platform rules. We flag them at scoping so your adviser can review wording and features before they are built.

Android and iOS app development across Japan: all 8 regions and 47 prefectures

We work with businesses in all 47 prefectures remotely from India; none of the places below is an office location. App needs differ by region, from inbound tourism in Hokkaido and Kyoto to factory and field-work apps in Chubu and Kyushu. These notes describe the patterns we plan for in each region.

Across the country, the same few app types appear again and again: member and point card apps for local shops, booking apps for salons and clinics, field apps for construction and maintenance, ordering apps for wholesalers and multilingual guides for tourism. The region table further down summarises them, and our overview of IT services in Japan covers the websites, SEO and software that usually go alongside an app.

Tokyo and the 20 designated cities: app demand city by city

Japan's 20 designated cities are large municipalities that hold many powers normally reserved for prefectures, and together with Tokyo's 23 special wards they contain a large share of Japan's businesses and consumers. The table notes the kind of app projects each city typically generates. Every one of them, and any town between them, is covered by the same remote team.

Beyond the big cities, places such as Kanazawa, Matsuyama, Takamatsu, Naha, Kagoshima and Nagasaki have their own retail chains, tourism operators and manufacturers. For smaller businesses there, a well-scoped cross-platform app or a PWA is often the first realistic way to offer the kind of digital member card or booking flow customers already use with national chains.

Our hours in Japan time

The time difference is a fixed three and a half hours, because neither Japan nor India changes its clocks, so our hours in Japan time never move: 12:30 pm to 12:30 am JST, which is 9 am to 9 pm IST, every day of the week on WhatsApp. Calls fit best in the Japanese afternoon, and a morning call around 10 am can be arranged in advance.

For app projects this rhythm is useful. Your team tests the latest build during the morning and sends notes and screenshots, and we are online from lunchtime. Fixes usually reach a new test build on TestFlight for iPhone and Google Play internal testing before your day ends, so there is something new to install when you arrive the next day. For release days we agree the timing in advance, so we are online when the app goes live in Japan.

Hiring an offshore app developer from Japan: checklist and red flags

Offshore app projects fail for familiar reasons: a vague feature list, store accounts registered in the developer's name, no test builds until the end, a back end nobody documented, and a developer who disappears after launch, leaving an app that breaks after the next iOS update. Use this checklist with any vendor, including us.

• Meet the people who will build it. Ask for the developers' names and whether any work will be subcontracted.
• Get a screen list and feature list in writing. Every screen, every user role, every integration, what the admin panel does and what is excluded from version one.
• Ask how many codebases. One cross-platform app or two native apps changes both the price and the cost of maintenance.
• Open the accounts yourself. Apple and Google developer accounts, Firebase, cloud hosting, the domain and the Git repository must belong to your company.
• Ask for test builds from the first weeks. TestFlight and Google Play internal testing let you install real builds on your own phone.
• Check payment design early. Ask how the vendor will handle Apple and Google payment rules for what you sell, and which Japanese payment methods they will connect.
• Test their Japanese input handling. Ask to see how their apps deal with furigana, postal code lookup, kana-to-kanji conversion and Japanese fonts.
• Agree maintenance before launch. Who updates the app for new iOS and Android versions, how fast crashes are fixed and what it costs per month.
• Split payments against milestones. A vendor asking for the whole amount before any work is visible is a risk you do not need to take.
• Ask where personal data goes. Which countries it can be viewed from, and what legal basis covers that access under the APPI.

Red flags: a promise of guaranteed store approval or top rankings in store search; store accounts opened under the vendor's name; client logos and reviews you cannot verify; a price with no screen list; no answer on who maintains the app after launch; and a supposed Tokyo office that is only a mail-forwarding address.

Choose a Japanese developer instead if you need requirement sessions in Japanese at your office, a vendor that writes the Japanese copy and store listing for you, or a registered provider for subsidy funding. The higher price buys things we cannot offer, and we will point that out before you commit.

After launch: OS updates, store policies and app maintenance

An app is never finished in the way a brochure website can be. Apple releases a major iOS version every year, usually in September, and Google ships a new Android version every year as well. Each release can change permissions, notification behaviour, background tasks or screen layouts, and both stores periodically raise the SDK and API levels that new submissions and updates must target. An app that goes a year or two without updates can stop meeting store requirements.

What maintenance covers. Crash monitoring and fixes, framework and dependency updates, adjustments for new OS versions, renewing push notification keys and certificates, answering store review questions on updates, small content or feature changes, and checking that integrations such as LINE, payments and maps still work after their providers change their APIs.

What it costs. The first two months after launch are included free. From month three, maintenance is available from US$120/mo (about ¥19,000/mo), or you can contact us only when changes are needed, although apps left without updates for a long time usually cost more to bring back to current standards. Cloud and third-party services continue to be billed to your company directly.

Growing the app. Version two should come from data rather than guesses: which screens people use, where they drop out of bookings and which notifications they switch off. Store search and the app's own website both bring installs, so a simple landing page with store badges, deep links and good search visibility helps; our SEO services in Japan page and the SEO services overview explain that side.