Web app development cost comes down to a simple formula: the effort needed, measured in person-months, multiplied by the monthly rate of the team doing the work, plus the costs of running the app after launch. Using the assumptions explained below, a focused internal tool might need 4 to 9 person-months of effort, while a core business platform with payments and several integrations can need 20 or more. The rate in your quotes turns that effort into Rupiah.
That is why two quotes for "the same app" can differ several times over. They usually describe different scopes, different teams or different ideas about what is included.
This guide breaks down what drives the effort, gives planning ranges for common types of web apps, lists the costs that continue after launch, and shows how to collect quotes you can actually compare.
The formula behind every quote
Every honest estimate, whether it comes from a freelancer, a local software house or an international agency, is built from the same pieces:
Total cost = effort in person-months x blended monthly rate + third-party costs + running costs after launch
Effort depends on who is needed and for how long. A typical small project team looks like this:
| Role | What they do | When you need them |
|---|---|---|
| Product or project manager | Turns goals into priorities, runs planning and demos | Throughout, often part-time |
| UI/UX designer | User flows, wireframes, visual design | Mostly at the start |
| Front-end developer | Screens and interactions in the browser | Throughout the build |
| Back-end developer | Business rules, database, APIs, integrations | Throughout the build |
| QA engineer | Test plans, manual and automated tests | From the first sprint, not just the end |
| DevOps or cloud engineer | Servers, deployment pipeline, backups, monitoring | Setup, launch and occasional changes |
The blended rate is the average monthly cost of that mix. It varies widely with seniority, location and the vendor's overhead, so this article focuses on effort first. Once you know roughly how many person-months your app needs, you can apply the rates from the quotes in front of you.
What drives the effort up or down
Two apps with the same number of screens can need very different amounts of work. These are the drivers that matter most.
Users, roles and business rules
Each user type, such as customer, cashier, warehouse staff or manager, has its own screens and permissions. Behind those screens sit the rules: pricing tiers, discounts, credit limits, commissions, stock reservations and approvals. This is where most of the real work hides, because a simple-looking form can depend on many conditions that all need testing.
Integrations
Every connection to another system needs design, error handling and testing against the other side's quirks. Common ones in Indonesia include payment gateways for QRIS, virtual accounts and e-wallets, the WhatsApp Business Platform for notifications, Tokopedia and Shopee seller APIs, courier services and accounting software. The quality of the other system's documentation affects effort as much as the feature itself.
Data migration
Moving existing customers, products and transaction history from spreadsheets or an old system means cleaning, mapping and checking data. It is often underestimated because the mess only becomes visible once the work starts.
Design depth and devices
A clean interface built from a component library costs far less than a fully custom, branded experience with animations, and internal tools rarely need the latter. Supporting both Bahasa Indonesia and English, or making every screen fast on entry-level Android phones over a weak connection, adds design and testing time.
Security and compliance
Audit logs, role-based access, backups, security testing and obligations under Indonesia's Personal Data Protection Law (Law No. 27 of 2022, or UU PDP) add work that users never see. Leaving them out makes a quote look cheaper, not the app.
Planning ranges by type of web app
The ranges below are planning estimates, not quotes. They assume a small team of two to six people, a first production release rather than a full roadmap, standard cloud hosting and design built on an existing component library.
| Type of web app | Typical scope | Team | Rough duration | Effort |
|---|---|---|---|---|
| Internal tool | One department, 2 to 3 roles, 10 to 20 screens, basic reports, one integration | 2 to 3 people | 2 to 3 months | 4 to 9 person-months |
| Customer portal or B2B ordering app | Customer and admin roles, catalog, orders, payments, notifications | 3 to 4 people | 3 to 5 months | 9 to 20 person-months |
| Core business platform | Many roles, complex rules, several integrations, data migration | 4 to 6 people | 5 to 8 months | 20 to 48 person-months |
To turn effort into Rupiah, multiply by the blended rate in your quotes. Purely as an illustration, at an assumed blended rate of Rp 30 million per person-month, an internal tool at 4 to 9 person-months would cost roughly Rp 120 to 270 million, and a customer portal at 9 to 20 person-months roughly Rp 270 to 600 million.
That rate is an assumption for the arithmetic, not a market benchmark. If a quote sits far below these effort ranges, ask what has been left out; if it sits far above, ask which assumptions drive it. A good vendor will answer both questions with a breakdown.
Costs that continue after launch
The build is only part of the total. Budget for these from the start:
| Item | What it covers | How it is usually charged |
|---|---|---|
| Hosting and infrastructure | Servers or cloud services, database, storage, backups | Monthly, grows with usage |
| Domain and email | Domain name, business email, transactional email | Yearly or monthly |
| Third-party services | Maps, SMS, WhatsApp messages, OTP, error monitoring | Per use or monthly plan |
| Payment fees | Merchant discount rate on QRIS, cards and e-wallets; virtual account fees | Per transaction |
| Maintenance | Security patches, bug fixes, library upgrades, small changes | Monthly retainer or hourly |
For planning, we suggest reserving 15 to 20 percent of the initial build cost per year for maintenance and small improvements, separate from hosting and usage fees. An app that nobody updates slowly becomes a security risk as its libraries age.
How to get quotes you can compare
Most confusion about price disappears when every vendor answers the same brief in the same format.
- Write a short scope document. Describe the problem, the user roles, the main workflows from start to finish, the integrations and the data to migrate. A few pages in plain language beat a list of fifty feature names. If you are not sure which process deserves an app first, the roadmap in our guide to digital transformation for SMEs helps you choose
- Ask for a breakdown, not a single number. Request effort per feature or module, the team composition and the assumptions behind the estimate
- Ask what is excluded. Design, testing, deployment, data migration, training, documentation, warranty and third-party fees are common gaps that return later as change requests
- Agree on the pricing model. Fixed price suits a clear, stable scope; time and materials suits work you expect to adjust. Either way, tie payments to working, demonstrated features
- Phase the scope. Launch the smallest version that delivers value, then fund the next phase from what you learn. Our comparison of custom software vs off-the-shelf can help you decide which parts should not be built at all
You can also lower cost without lowering quality: use a proven component library for internal screens, rely on managed services for login, storage and email, keep early reports simple with spreadsheet exports, and make one person on your side available to answer questions quickly. Waiting for decisions is paid time too.
FAQ
Why do quotes for the same web app differ so much?
Usually because they are not quotes for the same app. Each vendor fills the gaps in your brief with its own assumptions about roles, rules, design depth, testing and integrations, and team seniority and overhead change the rate. Ask every vendor for effort by feature, team composition and a list of exclusions, then compare line by line. The differences you find often tell you more than the totals.
Is a fixed-price quote safer than time and materials?
Not automatically. Fixed price moves the risk of underestimation to the vendor, so vendors add a buffer and handle every change through formal change requests. Time and materials is more flexible and can cost less when scope is uncertain, but it needs closer involvement from you. For a first version with clear scope, fixed price can work well; for a product that will evolve with feedback, time and materials with a budget cap is often more practical.
Can we build the web app in phases to spread the cost?
Yes, and for most projects it is the better approach. Define a first release that solves one core problem for one group of users, launch it, and let real usage decide what comes next. Ask your vendor to design the architecture so later phases do not require rewriting the first one, and keep the list of deferred features visible so nothing important is forgotten.
Does a web app cost less than a mobile app?
Often, for the same features, because one responsive web app runs on every device while native mobile apps may need separate Android and iOS builds plus app store releases. Cross-platform frameworks narrow that gap, and features such as offline work, background location or heavy camera use can favor a mobile app. Decide by what your users need to do, then compare the effort for both options.
How Weaveward can build this for you
Weaveward's web app development service starts with a short discovery that turns your brief into user roles, workflows and integrations, then produces an estimate broken down by feature, with the team, assumptions and exclusions written down. The first deliverable is a clickable prototype of the core workflow, so you can confirm the scope before most of the budget is committed.
During the build we demo working features every one to two weeks on a staging environment you can access, and track spend against the estimate in the open. If you have a brief or a quote you want checked, talk to our team.