“How much does it cost to build an app?” cannot be answered with a single number, and not because vendors are being evasive. The reason is more fundamental: price is determined by the number of decisions, not the number of screens.
Two applications with the same screen count can differ by multiples, depending on whether the payment flow is already standard, whether data must be migrated from an old system, and how many exceptions were previously handled by a person and now have to be written down as rules.
Six components that make up the price
| Component | What it covers | Why it gets underestimated |
|---|---|---|
| Analysis and process mapping | Translating business process into specification | Looks like meetings, yet determines every later cost |
| Interface design | Screen flow, layout and components | Redesign is far cheaper than rewriting code |
| Development | Writing features on the client and server | The most visible part, rarely the most expensive |
| Integrations | Payment gateway, courier, accounting, legacy systems | Often discovered mid-project and changes the budget |
| Testing and fixes | Finding and closing gaps before launch | Cut when chasing a deadline, then paid for twice |
| Data migration and training | Moving old data and preparing the team | Most often forgotten, yet it decides adoption |
One sentence that saves a great deal of money: Ask for the quote to be broken down by the components above. A vendor who can break it down has usually thought the work through; one who cannot is guessing — and that guess becomes your change order later.
Why quotes differ by three to ten times
Large gaps between quotes almost always come from four sources, and almost never from one being simply expensive and another cheap.
- Quietly different scope. One includes testing, migration and training; the other counted development only.
- Degree of customisation. Building from scratch is a different job from adapting an existing system.
- Who does the work. Senior teams cost more per hour but often less per feature because there is less rework.
- Ownership model. The price differs when you request full ownership of the code rather than a right to use it.
Three routes, three cost structures
Before requesting quotes, decide which route you actually need. Many budgets disappear because a company chooses the most expensive route for a requirement that was genuinely ordinary.
| Route | When it makes sense | Cost structure |
|---|---|---|
| Buy a ready system | Your needs are standard and time is short | One payment, then servers and maintenance |
| Semi-custom | A ready system nearly fits but needs adjustment | System price plus adaptation cost |
| Fully custom | Your process is distinctive and is a competitive edge | Highest upfront, most flexible long term |
As a concrete anchor, proven ready-made systems span a very wide range depending on scope. In the MDH catalogue itself, plugins and lighter systems sit in the hundreds of thousands to one million rupiah, a production-ready omnichannel CRM platform sits around seven and a half million, a self-branded mobile app around ten million, and a full point of sale with an HRM module around fifty million because its scope is far broader.
Those numbers are useful as anchors. If a custom quote lands far above the price of a ready system that already covers your needs, ask precisely what the ready system cannot do.
The costs that appear after launch
This is the part most often missing from budgets, and the reason many systems are abandoned a year later.
A simple rule: Budget annual maintenance as a fixed percentage of project value, agree its scope in detail, and set a response time for incidents. A system without a maintenance budget is a system waiting to be abandoned.
How to cut cost without cutting outcome
- Cut features, not quality. Shipping fewer features that are genuinely used beats many half-finished ones.
- Fix the process before building. Every exception you delete on paper is a cost that never materialises.
- Use ready systems for anything that is not your edge. No business ever won by building its own attendance module.
- Pay in stages tied to verifiable milestones, not to calendar dates.
- Ask for a trial with real data before a large contract. It surfaces problems while fixing them is still cheap.
Frequently Asked Questions
The MDH team maps the process first, shows which parts a ready system can cover, and which genuinely deserve custom work. Initial consultation is free.
Discuss Your Requirements