Web app pricing — what drives cost?

“How much does a web application cost?” is a natural question. A useful answer does not start with a single number — it starts with scope: which problem we solve, who will use the system, what it connects to, and how critical reliability is after launch. This article helps you prepare for a project conversation: understand differences between proposals and gather what is needed for an individual estimate.

I price every project individually, based on business goals, expectations, feature scope, required integrations and timeline.

If you are still unsure whether you need an application or a website is enough, start with web application vs website. When you already know you are building a system, the idea-to-launch process is a useful companion.

Why screen count is not enough
Internal tool, MVP and SaaS product
What usually increases complexity
Scope examples — illustrations, not packages
What to cut in v1 — and what not to skip
Costs after launch
What to prepare for an estimate
How to compare proposals with different scope
Summary

Why screen count is not enough

A five-screen mockup can look “simple” and still require several roles with different permissions, CRM sync, Excel history import, email notifications and error logging. Another mockup with fifteen screens can be cheaper if it is mostly lists and forms without integrations or complex rules.

That is why estimates based only on “how many screens” or “how many coding days without a brief” usually compare different things. What matters:

the business process — how many paths and exceptions the system must handle;
the data — where it comes from, how sensitive it is, how history is migrated;
system boundaries — what lives in the app versus spreadsheets, email or another tool;
quality of the first version — demo only, or a tool the team relies on every day.

Internal tool, MVP and SaaS product

These three labels appear often in enquiries, but they mean different product responsibility.

A simple internal tool usually serves one team, one main path and a limited set of roles. Data rarely leaves the company. Integrations — if any — tend to be point-to-point (e.g. export to a sheet or a webhook to one system).

An MVP is the smallest version that lets a user complete real work and lets you gather feedback. It does not mean “sloppy”: sign-in, basic permissions and a deployable release still matter. It does mean consciously deferring features that do not block first use. More on that stage: building a web app from idea to launch.

A SaaS product (customer accounts, plans, self-service, often multi-tenant) adds a product layer: onboarding, billing, data isolation between customers, an operator admin panel and operations under continuous traffic. DevSentinel’s own products — for example Recevio as a SaaS with accounts, a business dashboard and channel/payment integrations — illustrate that complexity class in practice: it is a different scale from a panel for a single internal team. This is not a “price like Recevio” claim — only a reference point: accounts + integrations + payments + post-launch operations expand scope far beyond an internal tool.

What usually increases complexity

Roles and permissions

One “user” role is different work from a matrix: customers see only their data, staff see a queue, managers see reports, admins configure the system. Every access rule needs design, tests and ongoing care when features grow.

Integrations

Connecting CRM, ERP, payments, Meta, calendars or a partner API is a project inside the project: data mapping, auth, error handling, rate limits and monitoring. Details: system integration via API.

Data migration

“Import from Excel” can be simple with clean tables. Cost rises when history is inconsistent, keys are missing, several sources must be merged, or numbering and relationships must stay continuous.

Payments and subscriptions

A payment gateway is not only a “pay” button. Statuses, retries, invoices/notifications, refunds and alignment with how you actually sell (one-off vs recurring) all matter.

Reports and exports

A simple filtered table differs from dashboards with aggregations, view-level permissions and accounting exports. A report “like Excel, but nicer” often hides substantial logic.

Reliability and operations

Environments (dev/stage/prod), monitoring, backups, rollback and a sensible release process are not decoration — they decide whether a Friday-evening outage ends in a quick restore or manual firefighting. Related: CI/CD and migrations.

Scope examples — illustrations, not packages

The examples below are not client case studies and not packaged offers. They show how complexity differs when briefs sound similar (“a ticket panel” vs “an app with accounts”).

Element	Example A: internal request/ticket panel	Example B: app with customer accounts and integrations
Users	Company team (a few internal roles)	Customers + staff + operator admin
Core process	Intake → statuses → closure	Sign-up / sign-in → order or booking → handling
Data	New database or a simple import	History migration + customer personal data
Integrations	Optional email / Slack	CRM, payments, external APIs, notifications
After launch	Internal maintenance, process-driven growth	Monitoring, user support, further integrations

Example A helps frame scope when you want to organise team work without opening the system to the outside world. Example B is closer to a product or customer portal — more attack surface, more paths and more dependency on external systems. Both names can sound similar in a brief; in an estimate they are usually different projects.

What to cut in v1 — and what not to skip

Worth deferring if it does not block first use:

elaborate dashboards “just in case”;
a second and third integration channel when one already closes the process;
polishing rare exceptions you already handle manually and infrequently;
a full admin area before the main user path works.

Not worth skipping in a sensible first version:

a clear role model for non-public data;
validation and error messaging on the critical path;
basic deployment, backups and access to logs;
safe storage of secrets and integration credentials;
an explicit decision on what is in MVP versus consciously “later”.

Saving on foundations usually returns as a more expensive refactor or downtime.

Costs after launch

The project budget is not only the build. After launch you typically face:

infrastructure — hosting, database, file storage, environments;
external services — payment gateways, email/SMS, AI APIs, monitoring tools (often usage-based);
maintenance — updates, fixes, watching integrations when a partner changes an API;
growth — further features driven by real use.

Having no plan for this part does not lower cost — it only postpones it until an outage or an urgent change.

What to prepare for an estimate

The more concrete the description, the easier it is to compare scope options instead of guessing. Helpful inputs:

Business goal in one or two sentences and a success criterion after 30–90 days.
Who uses the system (roles) and what each role must not be able to do.
A “how it works today” process outline and what should change.
Systems to connect plus whether you have API docs / sandbox access.
Whether historical data must be migrated and in what quality.
Non-functional needs: availability, sensitive data, auditability, timeline.
What is must-have in the first version versus what can wait.

You do not need a 40-page specification. An organised outline is enough — we refine the rest in discovery.

How to compare proposals with different scope

When three quotes differ widely, the assumed scope usually differs — not only the “rate”. Before comparing, clarify:

whether the estimate includes discovery, UX, testing, launch and documentation, or only coding;
which integrations are included versus optional;
whether data migration and team onboarding are in scope;
how changes are handled (fixed scope vs staged / time & material);
what happens after launch: bugfix window, care package, further development.

A “cheaper” proposal that omits an integration critical to your process is not cheaper — it is incomplete relative to your need. A “more expensive” proposal that includes operations and monitoring may be closer to the real first-year cost.

Summary

The cost of a dedicated web application comes from process, data, roles, integrations and reliability expectations — not from screen count alone. Distinguishing an internal tool, an MVP and a SaaS product, plus a clear now/later list, makes conversations and vendor comparisons more honest.