Software development and IT outsourcing for Japan: Tokyo, Osaka and all 47 prefectures

Who we are, and which software projects in Japan we suit

BtechWaleTech is a three-person engineering team in India. One of us is our full stack developer: he builds the screens, the back-end services and the integrations that connect them. Another of us covers AI and machine learning, AWS infrastructure, data pipelines, technical SEO and deployment. The third of us leads project delivery and works on data science, AI and automation. For a client in Japan, that means the person who answers your question about a pricing rule is the person who implements it. There is no project manager, sales representative or subcontractor between you and the code.

We have no office, business registration, staff or postal address in Japan, and all of our work is remote. We do not claim past Japanese clients, publish testimonials or display certification badges; we would rather you judge us on a clear scope, a working staging environment and direct conversations with the engineers. For the wider picture of what we build across the country, our Japan page covers websites, apps, SEO and automation. This page is about software: 業務システム (business systems), web applications, integrations, cloud and data work, システム開発 in the broad sense.

We work in English. None of us writes natural Japanese, so screen labels, messages, manuals and emails that your staff or customers read in Japanese are written or reviewed by you, a bilingual colleague or a translator. We build systems so that this text lives in a separate, translatable file rather than being scattered through the code, which also makes later wording changes cheap and safe.

The projects that suit us best share a few traits:

• Foreign-owned companies and Japanese subsidiaries that already work in English and need internal tools, portals or integrations with global systems.
• Japanese SMEs with one English-speaking manager or IT lead who can own the requirements and relay feedback to colleagues.
• Startups in Tokyo, Fukuoka and other cities building a first product version on a limited budget.
• Teams outgrowing Excel or kintone who want a focused custom system rather than a large package implementation.
• Companies left with an unsupported system after the original vendor stopped maintaining it.

Who should look elsewhere: if your project needs meetings in Japanese, on-site work at your office or factory, an ISO 27001-certified vendor, a Japanese-registered contractor for public tenders, or eligibility for IT subsidies, a Japanese system development company is the better fit, and we will say so in the first conversation.

Custom software we build for businesses in Japan

Software development here means anything beyond a standard website: systems with user accounts, data, business rules and integrations. These are the categories Japanese businesses most often need, and the ones we build.

• Business systems (業務システム). Sales management, quotation and order management, job and project tracking, staff scheduling and approval workflows, built around how your team actually works rather than around a package's assumptions.
• Booking and membership systems. Reservations for clinics, salons, schools, rentals and experiences; member portals with plans, points and renewal reminders; staff-side calendars and capacity rules.
• B2B ordering portals. Customer-specific price lists, repeat orders, order history, delivery date selection and invoice downloads for wholesalers and manufacturers whose customers still order by phone, FAX or email.
• Inventory and operations dashboards. Stock across warehouses and shops, reorder alerts, production progress and sales by channel, updated automatically instead of rebuilt in Excel every Monday morning.
• API integrations. Accounting, CRM, ecommerce, chat, payment and messaging tools connected so data is entered once and flows everywhere it is needed.
• Legacy modernisation. Access databases, VBA tools and ageing PHP or Java systems replaced in stages, with the data migrated and reconciled.
• Cloud migration and DevOps. On-premises servers moved to AWS, Google Cloud or Azure in Tokyo, with automated deployment, monitoring and backups.
• Data engineering and analytics. Pipelines that pull data from POS, ecommerce, accounting and spreadsheets into one place, with dashboards and simple forecasts.

The rest of the stack has its own pages: website development in Japan for corporate and recruitment sites, Android and iOS app development in Japan for store apps, AI automation engineering in Japan for language models, OCR and workflow automation, and SEO services in Japan for search. The general scope of our web application work is on the web development service page, and search visibility for customer-facing systems is covered on our SEO services page.

Typical technology choices are TypeScript with React or Next.js for screens, Node.js or Python for back-end services, PostgreSQL or MySQL for data, and managed cloud services for storage, queues and authentication. We choose well-supported, widely used tools on purpose: the system should be easy for another engineer, in Japan or anywhere else, to maintain after us.

What system development costs in Japan in 2026, compared with our starting prices

Japanese companies usually collect several competing quotes (相見積もり) before choosing a system vendor, so it helps to know the market range first. The figures below are typical ranges from 2026 price guides published by Japanese agencies and comparison sites such as Web幹事, システム幹事 and 発注ラウンジ, which summarise quotes from Japanese development companies. They are market ranges, not a quote from any single company. Our figures are starting prices, with yen at ¥155 per US dollar for comparison.

Read the ranges with care. A Japanese quote for a mid-size system usually includes a formal requirements phase, design documents, several rounds of testing with written test specifications and a project manager's time, and on larger projects the margins of subcontractors below the prime contractor. Our starting price covers a focused first version: the core screens, roles and integrations needed to replace a manual process, delivered in stages. If your project genuinely needs everything in the Japanese mid-size range, our quote will be higher than the starting price, and we will show why line by line.

The exchange rate. Our prices are set in US dollars. In September 2026 the yen moved between about ¥153 and ¥157 per dollar, so the yen figure shifts a little from month to month. If your budget is approved in yen, we fix a JPY amount in the written quote, and that amount does not change during the project.

Compare like with like. A packaged SaaS tool with a monthly fee can be cheaper than any custom build for a standard process such as expense claims or attendance tracking. We will tell you when an off-the-shelf product fits better. Custom development pays off mainly where your process is a real advantage, where several tools must work together, or where per-user licence fees have grown out of proportion.

What our starting prices buy, and why they are lower

A starting price only helps if you know what it covers. These are the starting prices most relevant to software projects for businesses in Japan, and what each typically buys.

• Custom web app, from US$900 (about ¥140,000): a focused first version of a business system, booking system, member portal, B2B ordering portal or dashboard, with user accounts, roles and permissions, an admin panel, the core workflow, CSV or Excel export and deployment to your own cloud account.
• AI automation, from US$600 (about ¥93,000): one mapped and integrated workflow, for example FAX or PDF orders read by AI-OCR into your order system with a person checking uncertain fields, or kintone records synced with freee and announced in Chatwork. Details are on the AI automation page for Japan.
• Android and iOS app, from US$600 (about ¥93,000): one Flutter or React Native app for iPhone and Android with login, forms, push notifications and an admin panel, often the mobile front end of a custom system. See our Android and iOS app service.
• Ecommerce, from US$750 (about ¥116,000): a store with cart, checkout, Japanese payment methods and order management, which can connect to your inventory or accounting system as part of a larger build.
• Maintenance, from US$120/mo (about ¥19,000/mo): bug fixes, security and dependency updates, backups, monitoring and small changes, after the two free months that follow every launch.

Why our prices are lower. A Japanese system vendor's price has to cover a Tokyo or Osaka office, a sales team that wins the project, a project manager who coordinates it, and often second and third-tier subcontractors who each keep a margin, a pattern the industry itself calls multi-layer subcontracting (多重下請け構造). We carry none of those costs. Three engineers in India, working remotely, scope, build and support the system themselves. That is the reason for the gap, not shortcuts in testing or security.

What raises a quote: many user roles with different permissions, complex approval routes, integrations with older on-premises systems, large or messy data migrations, printed forms that must match existing layouts exactly, and hard deadlines. What keeps it down: one decision-maker, sample data available early, a first release limited to the core workflow, and a willingness to accept standard screen layouts where nothing special is needed.

Costs you pay directly. Cloud hosting, databases, email delivery, API usage for AI models, SaaS licences such as kintone, Salesforce or Slack, app store fees and translation are billed to your company by those providers. We estimate them in the quote so the running cost is visible before you commit. Scope notes for every plan are on the pricing page.

Why Japanese companies outsource software: the IT talent shortage and DX

Japan has had a structural shortage of IT engineers for years. The Ministry of Economy, Trade and Industry estimated that the country could be short of up to 790,000 IT workers by 2030. The gap is felt most outside the big cities, where small and mid-sized companies cannot match Tokyo salaries or attract experienced engineers at all. Many firms therefore have one person who looks after the network, the PCs and the accounting software, and nobody who can build or maintain a system.

The government has also pushed digital transformation (DX) for years. METI's DX Report of September 2018 coined the phrase "the 2025 digital cliff" (2025年の崖), warning that if companies could not modernise ageing, heavily customised and poorly documented legacy systems, Japan could face economic losses of up to ¥12 trillion a year from 2025. For most SMEs the pressure is more immediate: fewer staff to re-type data, customers who expect online ordering and booking, and legal changes to invoices and electronic records that paper processes handle badly.

For a small company, the practical situation is usually one of three. Work runs on Excel files and email because no system fits. A system built years ago by a vendor that has since stopped supporting it still runs critical processes. Or a SaaS tool was bought but never connected to anything else, so staff copy data between tools by hand. Each is fixable without a large project, and outsourcing is often the only realistic way to do it.

Outsourcing does not remove the need for ownership inside your company. The projects that go well have one person who decides priorities, knows the current process and can test the result. We supply the engineering; that person supplies the knowledge of your business. When nobody inside can take that role, we recommend starting with a smaller first release rather than a large system nobody owns.

If your need is broader than software, for example a new corporate site or local search visibility, the overview of IT services in Japan shows everything we build for Japanese businesses, with prices for each.

Offshore development from Japan, and where an India team fits

Offshore development (オフショア開発) is a familiar model in Japan. Vendors in Vietnam, China, the Philippines, India, Bangladesh and elsewhere build software for Japanese clients, usually through a Japanese sales office and a bilingual bridge engineer who handles communication. The attraction is the same everywhere: engineering capacity that is hard to hire locally, at a lower cost. In the 2025 edition of the オフショア開発白書 (Offshore Development White Paper), published by the Japanese matching site オフショア開発.com, Vietnam was by far the most common destination, followed by China and India.

India is a less common choice for Japanese SMEs, and the main reason is language. Indian engineering teams usually work in English, while many Japanese companies want to specify, review and discuss in Japanese. Some offshore firms in other countries train Japanese-speaking engineers for exactly this reason. We do not pretend to solve that with a translation layer. We recommend an India team, and us, mainly when your side already has someone who is comfortable working in English.

The bridge SE question. On large offshore projects a bridge SE (ブリッジSE) translates requirements, reviews deliverables and manages the offshore team. That role costs money and adds a layer between the people who know the business and the people who write the code. On a small or mid-sized project, a bilingual contact on your side does the same job better: someone who reads the scope, relays feedback from colleagues and approves releases. We make that person's job easy with short English messages, annotated screenshots, a staging environment and a running decision log.

What an India team brings. India has a very large software engineering workforce with strong English and long experience of cloud platforms, data engineering and AI, built through work for clients in the United States, Europe and Australia. For a Japanese company that already runs partly in English, or a foreign subsidiary in Japan, that combination is often a better fit than a Japanese-speaking offshore team whose English is limited.

Making it work. Write the scope in English and keep it short; keep Japanese screen text in a separate sheet; release to staging in small steps so misunderstandings surface within days, not months; and agree which person on each side makes decisions. Offshore projects that fail usually follow the same pattern, long silent periods followed by one big delivery that misses the point, and staged releases remove most of that risk.

Ukeoi, jun-inin and SES: Japanese contract types and how our work maps to them

Japanese software contracts usually fall into a few types, and your legal or purchasing team will ask which one applies. This is a practical summary for planning, not legal advice.

Ukeoi (請負契約), a contract for work. The vendor promises to complete a defined deliverable, and payment is tied to that result. Most fixed-price system builds are contracted this way. The vendor carries the risk of finishing the agreed scope, which is why Japanese vendors invest so much effort in requirements before signing: anything not written down becomes a dispute about scope later.

Jun-inin (準委任契約), a quasi-mandate. The vendor promises to perform work with professional care rather than to deliver a specific result, and is usually paid for time or a monthly fee. Requirements definition, consulting, maintenance and agile development are often contracted this way, because the output cannot be fully specified in advance. Since the 2020 Civil Code revision, a quasi-mandate can also be paid on delivery of a result (成果完成型), which some companies use for phases with a clear output but an open method.

SES (system engineering service). A common Japanese arrangement in which a vendor supplies engineers, often to work at the client's site, under a quasi-mandate contract. Because it is not worker dispatch, the client is generally not supposed to direct those engineers directly; doing so risks being treated as disguised contracting (偽装請負). We do not offer SES and do not place engineers under a client's direct instruction.

How our projects map. New builds are fixed-scope: a written scope, a fixed price, milestone payments and acceptance against agreed criteria, which is close to ukeoi. Maintenance and continuous improvement are a monthly service, closer to jun-inin, and can be stopped with notice. Discovery work on an unclear problem can be a small fixed-price phase whose output is the scope document itself. Model contracts for system development have been published for the Japanese IT industry, and your team is welcome to use one as the starting point, with the Japanese-law wording checked by your own adviser.

Requirements, testing and acceptance: meeting Japanese quality expectations

Japanese system development traditionally follows a clear sequence: requirements definition (要件定義), basic design (基本設計), detailed design (詳細設計), coding, then unit, integration and system testing, and finally the client's acceptance testing and formal acceptance (検収). Each phase ends with documents the client reviews. The model is heavy, but the expectation behind it is reasonable: nothing should reach production that has not been checked against something written down.

How we adapt it. We keep the discipline and drop the weight. Requirements become a short English scope with a screen list, user roles, data items, business rules and acceptance criteria. Design becomes screen sketches and a data model reviewed together in a call. Instead of one delivery at the end, features are released to staging in small batches, so your team checks real screens against the scope every week.

Test specifications. Japanese clients often expect a test specification (テスト仕様書): a table of test cases with steps, expected results, actual results and a pass or fail mark. We write one for the main workflows and for the business rules that matter most, such as tax rounding, closing dates and permission checks, and we add automated tests for calculations and integrations so the same checks run on every future change.

Acceptance. Before release, your team tests on staging for an agreed period using real scenarios, ideally with anonymised copies of real data. Issues go into one shared list with screenshots and are classified as defects against the scope or as new requests, then fixed or quoted accordingly. Sign-off happens when the agreed criteria pass, and it triggers the final milestone payment.

Defects after delivery. Since the revision of Japan's Civil Code in 2020, the old concept of warranty against defects (瑕疵担保責任) has been replaced by liability for non-conformity with the contract (契約不適合責任), under which a client can generally ask for repair, a price reduction, damages or termination when a deliverable does not match the contract. Under the default rules the client must notify the vendor within one year of discovering the problem, but contracts commonly set their own period and limits, so this should be written into your contract and reviewed by your adviser. In practice, anything that does not match the agreed scope is fixed at no cost, and the two free months of maintenance after launch cover fixes and small changes.

Japanese business rules that custom software has to get right

Most software problems in Japan are not technical. They come from business conventions that foreign templates and packages ignore. These are the ones we plan for from the first scope document.

• Closing dates and payment terms. B2B billing usually runs on a monthly closing date (締め日) with terms such as closing at month end and paying at the end of the following month (月末締め翌月末払い). Customer-specific closing dates, payment terms and consolidated invoices covering many deliveries must be modelled in the data from the start, not bolted on later.
• Consumption tax and rounding. The standard 10 percent and reduced 8 percent rates must be tracked per line, and on a qualified invoice the tax is rounded once per rate per invoice rather than line by line. Getting this wrong produces one-yen differences that accountants notice immediately.
• Dates and fiscal years. Many companies run an April-to-March fiscal year, some documents and older customers expect Japanese era years such as Reiwa next to the Western year, and business-day calculations need Japanese national holidays plus company closures around Golden Week, Obon and the New Year.
• Bank transfer files. Bulk supplier payments and payroll are often uploaded to banks as files in the Zengin format (全銀フォーマット), a fixed-length layout in which account names are written in half-width katakana. Systems that pay suppliers need to generate it exactly.
• Names, readings and addresses. Family name first, a katakana reading field (フリガナ) for sorting and phone calls, postal-code address lookup, and normalisation of full-width and half-width characters so that searches and duplicate checks actually work.
• Forms that print. Quotations, delivery notes and invoices (帳票) often have to match an established layout, sometimes with the company seal image, and are sent as PDF. Layout work belongs in the scope, not in the last week.
• Approval routes. Purchases, discounts and contracts often need a multi-step internal approval (稟議), with substitutes when a manager is away. We build routes that follow your internal rules and keep a complete audit trail.
• CSV and Excel. Staff open exports in Excel on Japanese Windows, which reads plain CSV files in the Japanese Shift_JIS encoding by default. We export UTF-8 with a byte order mark or native Excel files so Japanese text never turns into garbled characters.

Integrating kintone, freee, Money Forward, Salesforce, LINE, Slack and Chatwork

A typical Japanese SME uses several cloud tools that do not talk to each other: kintone for customer or project records, freee or Money Forward Cloud for accounting and invoices, Chatwork or Slack for internal chat, Google Workspace or Microsoft 365 for email and files, and sometimes Salesforce or HubSpot for sales. Much of the value of custom software in Japan is simply connecting them, so information is entered once and trusted everywhere.

Common patterns. A paid order in Shopify or your own system creates an invoice or journal entry in freee or Money Forward Cloud. A new kintone record appears in a customer portal, and changes made there flow back. A won deal in Salesforce generates a quotation PDF in the company's own layout. An overdue task posts a reminder to Chatwork. A booking confirmation, reminder or delivery update reaches the customer on LINE.

LINE. LINE has more than 100 million monthly users in Japan according to LY Corporation, so many customer-facing systems send notifications through a LINE Official Account (LINE公式アカウント) and the Messaging API. LINE Notify, which many companies used for quick internal alerts, ended in March 2025, so older scripts that relied on it need moving to the Messaging API, Slack, Chatwork or Microsoft Teams. Message volume affects what your company pays LINE, so we design notifications to be useful rather than frequent.

Doing integrations properly. We use official APIs and webhooks rather than scraping screens. Each integration runs under a service account your company owns, with the narrowest permissions the job needs. Failed calls are retried safely without creating duplicate invoices, every sync is logged, and a person is alerted when something needs attention. When a SaaS vendor changes its API, maintenance covers the update.

Where the integration is mainly about automating a human routine, such as reading orders, drafting replies or summarising meetings, the AI automation engineer page for Japan covers the AI side in more depth.

Replacing Excel and outgrown kintone apps

Excel still runs a great deal of day-to-day work in Japanese companies: quotations, order books, stock lists, shift rosters and sales reports passed around by email or kept on a shared drive. It works until two people edit different copies, a formula breaks without anyone noticing, or the one person who understands the macros moves on.

kintone, Cybozu's no-code business app platform, is a common next step, and a good one for many teams. Problems start when an app grows beyond what it was designed for: dozens of lookup fields between apps, plugins stacked on plugins, JavaScript customisations nobody documented, and reports that still need an export to Excel. Performance, permissions and data integrity become harder to manage with every change.

Signs it is time for a custom system: the same data is entered in two places; month-end closing depends on one person's spreadsheet; customers or suppliers need access that your current tool cannot give safely; calculations such as pricing, commissions or stock valuation are too complex for formulas; or licence costs grow with every user who only needs to look at data.

How we approach it. We collect the current files and screens, list every field and rule, and agree which ones still matter. The new system gets a proper relational data model, user roles, a history of who changed what, and exports in the formats staff rely on. Existing data is cleaned and migrated in rehearsals before the switch. Where kintone works well as an entry screen, we can keep it and move only the heavy processing, customer access or reporting into a custom service connected through the kintone REST API.

A focused replacement like this fits our custom web app starting price of US$900 (about ¥140,000); the quote depends on how many workflows, roles and reports it covers.

Legacy modernisation and cloud migration in the Tokyo and Osaka regions

Many Japanese companies still run important systems on an on-premises server in the office or a data centre: an Access database, an Excel VBA tool, a Visual Basic client application, or a PHP or Java web system written ten or twenty years ago. The original vendor may have closed or stopped supporting it, the server's operating system may be out of support, and the source code may be incomplete or undocumented.

Staged modernisation. We avoid big-bang rewrites. First we document what the system actually does, including rules found only in the code or in staff habits. Then we rebuild in slices, one workflow at a time, with the old and new systems running side by side and data kept in sync until each slice is proven. The riskiest part, usually the data, is rehearsed more than once before the final switch.

Japanese data conversion. Legacy Japanese data brings specific work: text stored in Shift_JIS or CP932 converted to UTF-8, machine-dependent characters such as circled numbers and single-character company abbreviations, half-width katakana in names and addresses, custom kanji (gaiji) used in people's names, Japanese era dates stored as text, and codes whose meaning lives only in someone's memory. We write conversion scripts with checks that count and compare records, so nothing disappears quietly.

Cloud architecture in Japan. AWS (Tokyo ap-northeast-1 and Osaka ap-northeast-3), Google Cloud (Tokyo asia-northeast1 and Osaka asia-northeast2) and Microsoft Azure (Japan East and Japan West) all operate regions in Japan. A common design runs production in Tokyo and keeps backups, and for critical systems a standby environment, in Osaka, so an earthquake or regional outage in one area does not stop the business. The account is opened in your company's name, which keeps billing, data and access under your control and makes data residency in Japan straightforward to document.

DevOps. Infrastructure is defined as code so it can be reviewed and rebuilt, deployments run through an automated pipeline with tests, and monitoring, log retention, cost alerts and backup restore tests are set up before launch. Another of us, who handles AWS and deployment on our team, documents the setup in English so the next engineer can take it over without guesswork.

Data engineering, dashboards and analytics for Japanese businesses

Many companies in Japan have plenty of data and little time to use it: POS exports, ecommerce orders from their own store and from marketplaces such as Rakuten and Amazon, accounting data, spreadsheets from branches and records in kintone. Management reports are rebuilt by hand every month, often by the same overworked person.

We build pipelines that pull these sources into one database or warehouse on a schedule, clean and join them, and feed dashboards that answer the questions managers actually ask: sales by store, channel and product, stock cover, gross margin by customer, and how this month compares with the same month last year. Dashboards can live in tools such as Looker Studio or Power BI, or inside your custom system.

With clean history in place, simple forecasting becomes realistic: expected demand over the coming weeks, seasonal patterns around Golden Week, Obon and the year-end gift season, or reorder points by product. Another of us and the third of us handle the data science side, and we keep models explainable, because a forecast nobody trusts will not be used.

Data work touches personal information more often than people expect, for example customer names inside order records. We aggregate or pseudonymise wherever possible, so analytics can run without the India team seeing identifiable customer details.

Security practices, and what we do not claim

Japanese companies commonly send vendors a security check sheet (セキュリティチェックシート) before signing, and larger clients often ask whether the vendor holds ISO 27001 (ISMS) or the Privacy Mark (プライバシーマーク). We hold neither certification, and we answer check sheets honestly rather than ticking every box.

This is what we do on every project:

• Least-privilege access: each person and service gets only the permissions it needs, and access is removed when a project ends.
• Multi-factor authentication on cloud, repository and SaaS accounts, with your company as the owner of each account.
• Code review before changes reach production, and dependency and security updates applied as part of maintenance.
• Secrets such as API keys stored in a secrets manager or protected environment configuration, never in source code.
• Separate development, staging and production environments, with staging running on dummy or anonymised data.
• Encrypted backups with tested restores, and logs retained long enough to investigate an incident.
• Common web vulnerabilities, such as injection, cross-site scripting, broken access control and unsafe file uploads, addressed in design and checked before release.

If your policy requires a certified vendor, penetration testing by an accredited firm or on-site security audits, the testing can be arranged with a third party at your cost, or a certified Japanese vendor may simply be the right choice. We would rather tell you that before the project than after it.

APPI, invoices, electronic records and other rules that shape business software

This is practical groundwork we build into systems for Japan, not legal or tax advice. For formal questions, please speak to a qualified adviser in Japan.

Personal information. Japan's Act on the Protection of Personal Information (個人情報保護法, APPI) requires businesses to specify their purposes of use, keep personal data secure and supervise contractors who handle it. Systems we build support that with role-based access, audit logs, retention settings, and export or deletion tools for handling requests from individuals.

Access from India. If our team can access personal data in your system, that is provision of data to a third party in a foreign country under the APPI. It generally requires the individual's consent, given with information about the country and its data protection system, or a contractor with a protection system equivalent to the APPI's standards. India's Digital Personal Data Protection Act, 2023 is being phased in. We minimise access, develop with dummy data, restrict production access and sign data-handling terms; your adviser decides the legal basis your company relies on.

The invoice system. Since October 2023, buyers generally need qualified invoices (適格請求書) from registered issuers to claim input tax credits. Billing systems for registered Japanese companies must show the registration number, the applicable tax rates and the tax amount for each rate. Our own invoices to you are different: we are not a registered qualified invoice issuer, we do not add Japanese consumption tax, and your tax accountant should confirm the treatment.

Digital invoices. Japan's Digital Agency publishes JP PINT, the Japanese specification for Peppol e-invoices, which supports qualified invoices and the monthly consolidated invoices common in Japanese B2B trade. Adoption is voluntary and still growing, and several Japanese accounting and invoicing services already support Peppol, so a new billing system should at least be able to hand invoice data to such a service rather than only printing PDFs.

Electronic records. Under the Electronic Books Maintenance Act (電子帳簿保存法), transaction records exchanged electronically, such as PDF invoices, must be stored electronically from January 2024, searchable by date, amount and counterparty and protected against undetected changes. Systems that send or receive invoices should store them that way, not only as email attachments.

External transmission rules. Since June 2023, the Telecommunications Business Act requires many online services to disclose information sent to third parties through tags and SDKs, such as analytics and advertising scripts. Many corporate sites that promote a company's own business are out of scope, but customer portals, apps and online services may be covered, so we list every third-party script and add a disclosure page where needed.

Accessibility. Since April 2024, reasonable accommodation for people with disabilities has been mandatory for private businesses under the Act for Eliminating Discrimination against Persons with Disabilities. For web systems, JIS X 8341-3, which is aligned with WCAG, is the reference standard; we build customer-facing screens with keyboard access, labelled fields, sufficient contrast and clear error messages.

Consumer-facing systems. Prices shown to consumers must include consumption tax, a rule in force since April 2021, and online stores need a Specified Commercial Transactions Act page and a final confirmation screen that meets the rules in force since June 2022. Advertising claims inside the system fall under the Premiums and Representations Act, which has also covered stealth marketing since October 2023.

Software development across Japan: all 8 regions and 47 prefectures

We build software for companies in all 47 prefectures, remotely from India. Needs differ by region because industries differ: a parts supplier near Nagoya, a wholesaler in Osaka and a distributor in Hokkaido need very different systems. The notes below describe typical demand in each region. They are not office locations; we have none in Japan.

Across every region, the same few needs come up again and again: replacing spreadsheets and paper with a shared system, connecting accounting and sales tools, giving customers and suppliers a safe way to order or book online, and moving an ageing office server into the cloud. The region table further down summarises the pattern for each part of Japan.

Software development in Tokyo and Japan's 20 designated cities

Tokyo's 23 special wards and the 20 ordinance-designated cities, which hold many powers that elsewhere belong to prefectures, are where much of Japan's corporate demand for software is concentrated. The table shows the kind of software work each city's economy typically generates. We serve all of them remotely, along with every smaller city and town.

For companies outside these cities, remote development is often the more practical option anyway: prefectural capitals such as Kanazawa, Takamatsu, Matsuyama, Nagasaki, Kagoshima and Naha have capable local vendors, but few of them have spare capacity for a small custom project. A cloud system built remotely works the same in Naha as in Marunouchi.

Working hours: Japan time and India time

Japan Standard Time (UTC+9) is three and a half hours ahead of India Standard Time (UTC+5:30), and because neither country observes daylight saving, the gap never changes. We work from 9 am to 9 pm IST, which is 12:30 pm to 12:30 am JST, seven days a week on WhatsApp.

For software projects this overlap supports a simple rhythm. Your team tests on staging in the morning and logs issues; we pick them up when we come online at lunchtime Japan time, and fixes are usually ready for review later that afternoon or evening. Weekly progress calls fit between 1 pm and 6 pm JST. Production releases and database migrations run in low-traffic hours agreed with you, often the Japanese evening, and a 10 am JST call can be arranged in advance for launch days or meetings with your full team.

Holidays matter too. We mark Golden Week, Obon and the New Year break in the schedule, since approvals on your side slow down then, and we share Indian public holidays well in advance so nothing important lands on a day we are offline.

Maintenance, response times, documentation and handover

In Japan, maintenance and operations (保守運用) are usually a separate contract from the build, and over the life of a system they can cost more than the build itself. Every system we launch includes two months of free maintenance: bug fixes, security and dependency updates, backups, monitoring and small changes. After that, maintenance continues from US$120/mo (about ¥19,000/mo), or you can call on us only when needed.

Response times. We agree response times in writing, typically a same-day reply to issues raised during our working hours and priority handling for anything that stops the business. We do not run a 24-hour staffed operations centre. For systems that must be watched around the clock, we set up automated monitoring and alerts and help you plan out-of-hours cover.

Documentation in English. At handover you receive a developer README, an architecture diagram, the data model, a list of integrations and where their credentials are stored, deployment and rollback instructions, and a short operations guide covering backups and routine tasks. Screen manuals for Japanese staff can be produced as short recorded walkthroughs, with Japanese captions or text added by your translator.

No lock-in. Code sits in a repository your company owns, infrastructure is defined as code, and every account is in your name. If you later move maintenance to an in-house engineer or another vendor in Japan, the handover takes days rather than months.

Planned upkeep. Software needs care even when nothing is broken: framework and runtime versions reach end of life, cloud services retire features, and SaaS APIs change. Maintenance includes planned upgrades so that today's new system does not quietly become the next legacy problem.

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

Whoever you choose, a few checks remove most of the risk of an offshore software project. Use this list with every vendor you speak to, including us.

• Meet the engineers. Ask who will write the code, by name, and whether any part will be subcontracted. Talk to them before signing.
• Name your bridge. Decide who on your side reads the English scope and relays feedback. Without that person, even a good team will build the wrong thing.
• Get a written scope with acceptance criteria. Screens, roles, rules, integrations, data migration, exclusions and how acceptance will be judged.
• Ask for staged releases. A staging environment within the first weeks and regular releases after that. A vendor who wants to show everything at the end is asking you to carry all the risk.
• Own every account. Code repository, cloud account, domain, database and SaaS accounts in your company's name from day one.
• Check the security answers. Ask how access is controlled, where data is stored, how backups are tested and who can see personal data. Vague answers are themselves an answer.
• Clarify the contract type. Fixed deliverable or time-based, how changes are priced, how defects after delivery are handled and when intellectual property transfers.
• Stage the payments. An advance, a payment at design approval and the balance before launch is fair. Full payment upfront is not.
• Ask about year three. Who maintains the system later, what documentation you receive and how easily another team could take over.

Red flags: a quote without a scope; a price far below every other quote with no explanation; client logos or reviews you cannot verify; a claimed Japan office that turns out to be a virtual address; cloud or code accounts registered in the vendor's name; refusal to let you talk to the developers; promises that nothing will ever go wrong; and pressure to sign before a discount expires.

When a Japanese vendor is the better choice: meetings and documents in Japanese, on-site work, public-sector tenders that require a Japanese entity, mandatory ISO 27001 or Privacy Mark, IT subsidy funding, or round-the-clock operations support. For those, a Japanese system development company is worth its higher price. For everything else, contact us with a short description and we will tell you honestly whether we are a good fit.