"We need a web application" is a starting point, not a specification — the phrase covers wildly different projects with wildly different costs and timelines. Before scoping anything, it helps to know which of a handful of common application shapes your business actually needs, because a booking engine and an internal reporting dashboard share almost nothing in terms of what gets built.

The Common Application Types

  • Booking and scheduling systems — real-time availability, calendar logic, automated confirmations. Common for clinics, salons, rental businesses, consultants.
  • Inventory and order management — stock tracking, low-stock alerts, order processing, often integrated with a storefront or a physical point-of-sale system.
  • Member or client portals — logins, role-based access, private dashboards showing account-specific data (a school's parent portal, a cooperative's member area, a client's project-status dashboard).
  • Internal operations tools — staff dashboards, reporting, workflow tracking, generally not public-facing, built to replace a spreadsheet-and-email process that has outgrown manual coordination.
  • Marketplace or multi-vendor platforms — the most complex category, involving separate seller and buyer experiences, payment splitting, and moderation, genuinely a different scale of project from the others.

Why This Distinction Changes the Quote

A booking system with a single calendar and email confirmations is a Dynamic-tier project, typically days of work. A multi-vendor marketplace with payment splitting, seller onboarding and dispute handling is a fundamentally larger undertaking, often weeks. Both get described by a client as "we need a web app," which is exactly why a serious development quote requires a real scoping conversation rather than a number given sight-unseen — the phrase alone doesn't distinguish a three-day build from a three-month one.

The Questions That Actually Scope a Project

  1. Who uses it, and do they need to log in? A public tool with no accounts is simpler than one requiring authentication and role-based permissions.
  2. Does it need to talk to another system? Payment gateways, SMS providers, existing databases — every integration adds real scope.
  3. What happens when something goes wrong? A booking conflict, a failed payment, a duplicate order — edge-case handling is often the majority of real engineering effort, invisible in a feature list but not in the actual build.
  4. How will it be used day-to-day, and by how many people at once? A tool for three internal staff has different performance requirements than one serving thousands of public users simultaneously.

Build vs Buy: Worth Asking First

Before committing to a custom build, it's worth checking whether an existing tool (a booking plugin, an off-the-shelf inventory system) covers 80% of the need at a fraction of the cost, reserving custom development for the specific 20% that's genuinely unique to the business. Custom development earns its cost when the business logic is actually distinctive — a generic booking calendar rarely justifies a from-scratch build when mature plugins already exist; a booking system with Nepal-specific logic (multiple branch locations, staff-specific availability, SMS confirmations via a local gateway) often does.

What This Looks Like at WebsNP

Custom web application projects here start with a real discovery conversation — what the system needs to do, who uses it, what it integrates with — before any price is quoted, because a project scoped this way (Web Portal or Custom Web Application tier, typically NPR 80,000-200,000+ depending on complexity, 7+ days) gets built once, correctly, rather than repeatedly re-scoped mid-project because the actual requirements weren't nailed down at the start.