What Decides the Cost of a Custom Web App (and How to Scope One)

“How much does a custom web app cost?” is the first question almost every business owner asks, and the honest answer is that it depends. That’s not a dodge. Two businesses can both ask for “a booking system” and need things that are weeks of work apart.

This guide explains what actually moves the price, how to describe what you need so you get comparable quotes, and what a fixed bid does and doesn’t include. It gives no price list on purpose: a number without a scope is a guess, and the scope is the part you can control.

Why quotes for the “same” app differ so much

Words like “system”, “portal” and “dashboard” hide a lot. “A system to manage our bookings” might mean a calendar and a confirmation email, or it might mean online payments, QR codes, staff accounts, reports and SMS reminders. One developer prices the first, another prices the second, and both quotes are honest.

When quotes are far apart, the gap is almost always in what each one assumed. The fix is to give every developer the same written scope.

The six things that drive the cost

1. Workflows

A workflow is one job the app does from start to finish, such as “a customer books and pays for a slot” or “a manager approves a request”. Each workflow has screens, rules and edge cases (what if the payment fails? what if two people book the same slot?). More workflows, and more rules within each, is the biggest single cost driver.

2. User roles and permissions

An app with one kind of user is simpler than one with customers, staff and an owner who each see different things. Every role needs its own screens, and each permission has to be built and tested so people can’t see or change what they shouldn’t.

3. Integrations

Connecting to other services, like payment gateways, SMS providers, accounting tools, couriers or your Shopify store, takes real work. It’s not just the connection, but handling failures, repeats and missed messages properly. We cover why that matters in webhooks explained for store owners.

4. Data: moving it in and reporting on it

If your information lives in spreadsheets or chat threads, someone has to clean it and move it into the new system. Reports and dashboards also add cost, because each one needs its numbers defined and checked. If you’re starting from sheets, our guide to moving from spreadsheets to a custom web app covers what to build first.

5. Notifications

Emails and texts, like confirmations, reminders and receipts, look small but each message needs wording, triggers and testing. SMS also has running costs of its own, which we come back to below.

6. Platforms and extras

A web app that works on every phone and computer is one build. A public marketing website alongside it, or a mobile app in the app stores, are separate pieces of work. We explain the trade-off in web app or mobile app: what to build first.

What tends to keep it simpler, and what adds up

How to scope version one on a single page

You don’t need technical language. A one-page scope that you can hand to any developer is enough to get comparable quotes. Cover these points:

• The problem. One or two sentences on what’s painful today, like “we confirm bookings by checking GCash screenshots”.
• Who uses it. List each kind of user: customers, staff, owner.
• The three to five workflows that must work on day one. Write each as “a [person] can [do something] so that [result]”.
• What it connects to. Payments, SMS, accounting, your store, or nothing.
• What’s out for now. The “later” list is as valuable as the “now” list. It stops the first version from growing.
• What you have today. Spreadsheets, existing accounts, branding, anything to be moved or reused.

A good developer will question this scope, and that’s a good sign. Better to find a gap on paper than halfway through the build.

What a fixed bid covers, and what it doesn’t

A fixed bid means the price is agreed against a written scope before work starts, rather than billed by the hour. It protects you from a bill that grows as the project runs, and it protects the developer from a scope that quietly does. Look for:

• Milestones. The price split into stages tied to things you can see, not one big payment at the end.
• An early working link. A staging version you can click through while the build is underway, so surprises show up early.
• A defined support period. What fixes are included after launch, and for how long.
• A change process. What happens when you want something that isn’t in the scope: it should be quoted separately, in writing, before it’s built.

What a fixed bid usually doesn’t cover is anything outside the written scope, plus the running costs of third-party services. That brings us to the part people forget.

The costs after launch

The build is only part of what an app costs over time. Ask for a clear list of:

• Hosting and domain. Where the app runs, who pays, and whose account it’s in.
• Payment gateway fees. Charged by the provider on each payment, separate from the build.
• SMS and email. Messaging services bill by volume.
• Maintenance. Updates, security fixes and new features, whether by retainer or per project.

Also agree early who owns the code, the database and the hosting accounts. It’s a simple question, and much easier to settle before the build than after.

Questions to ask any developer who quotes you

Next steps

If you’re planning an app, write the one-page scope first, even roughly. It makes every conversation shorter and every quote more honest. To talk it through, see our custom web app development service. We give a fixed-bid quote split into milestones before any work starts.