A web app is not simply a website with a login page.
A website mainly helps people understand, trust and contact a business.
A web application lets people do work:
- create records;
- upload documents;
- collaborate;
- make payments;
- approve requests;
- run reports;
- manage customers;
- change system state.
That difference explains why web-app estimates are wider.
For 2026 planning, I would use these bands:
| Type | Planning budget |
|---|---|
| Focused workflow / MVP | $8k–$20k |
| Internal business application | $15k–$40k |
| Client/customer portal | $20k–$60k |
| Production SaaS | $30k–$100k+ |
| Complex / regulated platform | Scope individually |
These are planning bands, not universal market averages.
The interface is only one layer
A production web app usually contains:
Interface
What users see and interact with.
Business logic
What the system is allowed to do.
Data model
What records exist and how they relate.
Authorization
Who is allowed to see and change each record.
Integrations
What other systems the product depends on.
Operations
How it is deployed, monitored, backed up and repaired.
Two apps with ten screens can therefore have completely different budgets.
User roles change the architecture
Imagine a client portal that begins with two roles:
- admin;
- client.
Then discovery reveals:
- company owner;
- company staff;
- external accountant;
- account manager;
- support;
- platform administrator.
Now ask:
- Can staff invite colleagues?
- Can one accountant access several client companies?
- Can support see private records?
- What survives when a user is removed?
- Who can transfer company ownership?
Those are product rules, not UI details.
Supabase’s current documentation describes Row Level Security as granular authorization enforced inside Postgres and recommends enabling RLS on exposed tables. See Supabase RLS.
The broader principle applies to any stack: access rules should be explicit and testable.
Integrations create failure states
A web app may connect to:
- Stripe or Paystack;
- accounting tools;
- CRMs;
- email/SMS providers;
- maps;
- identity services;
- AI APIs;
- storage providers;
- legacy databases.
The happy path is rarely the difficult part.
The difficult questions are:
- What if the provider times out?
- What if an event arrives twice?
- What if the provider succeeds but our database write fails?
- Can the action be retried safely?
- How will support know what happened?
That operational work is invisible in a mockup.
A good MVP is not a disposable prototype
“MVP” should mean the smallest product that tests an important business assumption.
It should not mean:
- public data that should be private;
- no backup/recovery plan;
- payment access granted from a browser redirect;
- production secrets in frontend code;
- nobody owning deployment.
Cut features before cutting basic engineering quality.
If your priority is first-version scope, see my MVP development cost guide and MVP development service.
What can push a project above $50,000?
Costs rise quickly when several of these appear together:
- complex role hierarchies;
- subscriptions and entitlements;
- large legacy migration;
- many integrations;
- mobile apps alongside web;
- real-time collaboration;
- advanced reporting;
- offline operation;
- enterprise SSO;
- marketplace logic;
- audit requirements;
- regulated data;
- several regions/currencies.
The problem is not one feature.
It is interaction between features.
Security needs a definition
“Secure app” is too vague for procurement.
The OWASP Application Security Verification Standard exists to provide concrete requirements for verifying technical security controls in web applications.
You do not need every project to target the highest possible assurance level.
You do need to define what matters for this product:
- account access;
- authorization;
- secrets;
- input validation;
- logs;
- backups;
- payments;
- sensitive records.
Discovery deserves part of the budget
If the team cannot answer fundamental questions before implementation, the estimate contains hidden guesses.
Useful discovery should clarify:
- target users;
- workflows;
- edge cases;
- permissions;
- data;
- integrations;
- success metrics;
- first-release boundaries.
It may produce flows, prototypes, data models, acceptance criteria and architecture decisions.
That work can feel slower than coding immediately.
It is usually cheaper than discovering the product model after 70% of the code exists.
How to compare web-app quotes
Ask each provider:
What exact workflow is complete at launch?
Not “dashboard included.” What can the user accomplish from start to finish?
Who owns the source and infrastructure?
Repository, cloud account, database and domain should be explicit.
How are permissions enforced?
Not just what the UI hides.
What testing happens?
Especially around authentication, payments, data integrity and critical workflows.
How is production deployed?
Can another competent engineer reproduce it?
What happens after launch?
Bug warranty, support, monitoring and new features should not be mixed together.
Price the risk you are asking someone to own
A $9,000 internal tool that makes one team faster is a different responsibility from a $9,000 product that stores health records or moves customer money.
The second needs more assurance even if the screens look simpler.
That is why a useful estimate follows business consequences.
If you are planning a portal, dashboard, SaaS product or operational system and want to know what belongs in the first release, send me the workflow you want to digitise. I can help convert it into a buildable scope before development starts.
