One of the most common first meetings I have goes like this. A business owner sits down, slides two quotes across the table, and asks: "Why is one of these ¥1.5 million and the other ¥12 million? It's the same app."
It almost never is the same app. The two vendors read the same short brief and imagined two very different products. One pictured a simple web tool for five staff. The other pictured native iOS and Android apps, an admin dashboard, integration with the accounting software, and a support contract.
That gap is the real problem with custom business app development cost: the price depends far less on "an app" than on dozens of decisions nobody has made yet. In this article I'll walk through when a custom app actually makes sense, what drives the price, what ranges are realistic for a small business, what you'll keep paying after launch, and the patterns I see behind projects that fail.
Do you actually need a custom app?
Before talking money, an honest question: maybe you don't need one at all.
Three options are worth comparing first.
- Off-the-shelf SaaS. For accounting, payroll, attendance, scheduling, CRM or e-commerce, there are mature products built by companies that do nothing else. You pay a monthly fee and get updates, security patches and support included. If your process looks like most companies' process, start here.
- No-code and low-code platforms. Tools like kintone (by Cybozu) or Google AppSheet let you build simple business apps — forms, lists, approvals, basic workflows — on top of a database or spreadsheet, without writing code. They're priced per user per month and are a great fit for internal tools with modest complexity.
- A custom app. Software built specifically for your business, which you own and can shape exactly as you need.
A custom app starts to make sense when one or more of these is true:
- Your process is genuinely specific and is part of what makes you competitive, so bending it to fit a generic tool would cost you.
- You need hardware or special features: camera, QR codes, facial recognition, offline use, Bluetooth devices, GPS.
- The app is for your customers, not just your staff, and the experience has to reflect your brand.
- You've hit the ceiling of a no-code tool: performance, permissions, complex logic, or per-user pricing that becomes expensive as you grow.
- You need several systems to talk to each other in a way no single product supports.
If none of these apply, a SaaS or no-code tool plus some smart business automation between them is often the better answer. And as we wrote in our article on why SMBs fail at DX, buying the solution before you've defined the problem is the most expensive mistake there is.
What drives the cost of a custom business app?
App development cost is mostly people's time: design, development, testing and project management. Everything that adds time adds cost. These are the main factors.
Platforms: web, iOS, Android
A web app runs in the browser on any device. For internal tools used on office PCs and tablets, it's often the cheapest and simplest choice, and there's no app store involved.
Mobile apps make sense when you need the camera, push notifications, offline use or a place on the customer's home screen. Supporting both iOS and Android, plus a web admin panel, is effectively three front ends.
Native vs. cross-platform
Native development means writing one app in Swift for iOS and another in Kotlin for Android. You get maximum control, but you build and maintain two codebases.
Cross-platform frameworks such as Flutter (from Google) or React Native (from Meta) let one codebase run on both platforms. For most business apps this is the sensible default: lower cost, one team, consistent behaviour.
Integrations
Connecting to your accounting software, an existing database, a payment provider, LINE, or a government API is often where the hidden effort lives. A clean, well-documented API is quick; an old in-house system with no API can take longer than the app itself.
Admin panel and roles
Almost every business app needs a back office: managing users, editing content, viewing reports, exporting data. Who can see what (staff, managers, admins, customers) adds design and testing work.
Security and data
Logins, encryption, access logs, backups, and handling of personal or medical data all take time to do properly. With customer or patient data, it's never the place to cut corners.
How much does a custom business app cost? Realistic ranges
I'll give ranges rather than a single number, because anyone quoting a precise price before understanding your requirements is guessing. These are rough figures based on what we see in the Japanese market for small and mid-sized businesses; your project can fall outside them.
- Simple internal web tool (forms, lists, a few screens, one user role): roughly ¥1–3 million, 1–3 months.
- Business app with mobile + admin panel (iOS/Android via cross-platform, web back office, logins and roles): roughly ¥3–10 million, 3–6 months.
- Complex system (multiple integrations, advanced features like image recognition, high security requirements, many user types): ¥10 million and up, 6–12 months or more.
For reference, at SolidTech an MVP starts from around ¥1,000,000. That gets you a working first version of the core feature, not a stripped-down demo.
If a quote is much lower than these ranges, ask what's missing: testing, an admin panel, app store publication, source code ownership, or support after launch. If it's much higher, ask which assumptions drove it.
The MVP approach: launch small, then improve
MVP stands for minimum viable product: the smallest version of the app that solves the core problem for real users.
Instead of specifying 60 features up front and waiting a year, you pick the 5–10 that matter most, launch in a few months, and let actual usage tell you what to build next. In my experience, a good share of the features owners consider essential at the start turn out to be rarely used once the app is in people's hands — and some feature nobody thought of turns out to be the one everyone asks for.
The MVP approach gives you:
- Lower risk. You find out early whether the app works for your staff or customers, before most of the budget is spent.
- Faster value. The core feature starts saving time or earning money months earlier.
- Better decisions. Phase 2 is based on data and feedback, not guesses made in a meeting room.
It's the same principle we described in our AI case study for a 15-person company: solve one painful problem first, then expand.
What does an app cost after launch?
This is the part many quotes leave vague. Plan for these running costs:
- Hosting and services. Servers, databases, storage, email sending, maps or AI APIs. For a small business app this is often a few thousand to a few tens of thousands of yen per month, depending on usage.
- App store accounts. Publishing on the App Store requires the Apple Developer Program, an annual membership (US$99 per year, charged in local currency in Japan). Google Play requires a one-time registration fee of US$25. Make sure these accounts are registered in your company's name, not the developer's.
- OS and store updates. Apple and Google release major OS updates every year, and Google Play regularly raises the minimum API level apps must target. An app that isn't updated can break or be removed from the store.
- Maintenance and support. Bug fixes, security updates, library upgrades, small improvements. A common rule of thumb is to budget around 10–20% of the initial development cost per year, though it depends heavily on how much you keep adding.
An internal web app avoids the app store costs entirely, which is another reason to ask whether you truly need a mobile app.
Case study: MediSupp and DoraCheck
One of the projects I'm proudest of shows what happens when an app project goes wrong — and how it can be rescued.
MediSupp is a patient verification and medication management system for medical facilities and nursing homes. Its job is simple to describe and critical to get right: make sure the right medication reaches the right patient. It combines facial recognition to identify the patient with scanning of the medicine bag's QR code and text, so staff can confirm the match before giving medication.
The client came to us after a large IT company had failed to deliver the system.
SolidTech built and shipped the system in about a year, using React and Node.js. We then built DoraCheck, the mobile companion app, with Flutter so that a single codebase runs on both iOS and Android. Staff log in with facial recognition, and several staff members at a facility can use the same device or their own smartphones.
The lesson I take from this project isn't "small is better than big". It's that a project succeeds when the team building it stays close to the people using it, focuses on the core workflow first, and makes decisions quickly. Company size doesn't guarantee any of that.
Why custom app projects fail (and how to avoid it)
When I look at failed projects — ours to rescue or ones clients tell me about — the causes are rarely technical. They're almost always these five.
- Vague requirements. "An app to manage our orders" can mean anything. Write down who uses the app, what they do step by step today, and what should be different. Screen sketches on paper are worth more than a 40-page specification nobody reads.
- No owner on the client side. Someone in your company has to answer questions, test early versions and make decisions within days, not weeks. If everyone is "too busy", the project drifts and the vendor fills the gaps with assumptions.
- Big-bang scope. Trying to build everything at once means a long wait, a big bill, and a launch where every problem appears at the same time. Phase it.
- Vendor lock-in. Proprietary frameworks, servers only the vendor can access, or an app published under the vendor's developer account make it painful to switch later — and they know it.
- Not owning the source code. Your contract should state that the source code, designs and accounts belong to you once paid for, and that you get access to the repository. Without that, you've rented an app, not built one.
Frequently asked questions
How long does it take to develop a business app?
A focused MVP typically takes 2–4 months. A full business app with mobile, admin panel and integrations is usually 4–8 months, and complex systems can take a year or more. Your speed of feedback and decision-making matters as much as the developers' speed.
Is Flutter good enough for a business app?
For the vast majority of business apps, yes. It lets one codebase serve iOS and Android, which lowers both development and maintenance cost. DoraCheck is built with Flutter.
Can we start with no-code and move to a custom app later?
Yes, and it's often a smart path. A no-code prototype in kintone or AppSheet helps you clarify requirements cheaply. When you outgrow it, those learnings make the custom app's specification far more precise.
Are there subsidies for app development?
Japan's main IT subsidy, renamed in 2026 from IT導入補助金 to デジタル化・AI導入補助金, mostly covers pre-registered software tools rather than custom development, and the rules change every year. We explain how it works in our guide to Japan's IT subsidy for small businesses. Check the current official guidelines before assuming a subsidy will apply.
Thinking about building an app?
If you're weighing a custom app against SaaS or no-code, or you have quotes that don't make sense, I'm happy to look at them with you. We'll tell you honestly if you don't need a custom app. If you do, we'll help you define a realistic MVP and budget. Have a look at our app development service, or get in touch for a free consultation.