The most common question I get before a custom web application project is: what is this going to cost? The range is genuinely wide, and the honest answer requires understanding what’s actually driving the number. Here’s how I think through it.

The Baseline

My custom software projects start at $9,500. That covers a focused, well-scoped application with a defined workflow, one or two user roles, no external integrations, and straightforward data requirements. Think: an internal tool that replaces a spreadsheet process, or a simple client portal with a specific workflow baked in.

That’s the floor for a serious custom build. Below that, you’re looking at lightweight automation (Zapier, Make), a WordPress plugin, or a configuration of existing tools — not a custom application.

What Drives the Cost Up

Number of User Roles and Permissions

Every distinct type of user — admin, manager, employee, client, auditor — adds complexity. Different roles see different data, can take different actions, and need different interfaces. A single-role internal tool is straightforward. A multi-role platform with complex permissions takes significantly more time to build and test correctly.

Business Logic Complexity

Simple CRUD — create, read, update, delete records — is inexpensive. Complex business logic — conditional workflows, calculations, rules that vary by context, multi-step approval chains — takes time to build and test. The harder part is usually documenting what the logic should be, not implementing it once it’s clear.

External Integrations

Every API connection to an external system adds scope. Some integrations are clean and well-documented; some involve poorly documented APIs, rate limits, authentication complexity, or webhook handling that adds meaningful time. A system that connects to three external services costs more than one that stands alone. See the API integration services page for more on what that work involves.

Reporting Requirements

Simple reporting — list views, basic filters — is usually included in a standard build. Complex analytics, custom dashboards, date-range comparisons, or data exports in specific formats are a meaningful addition. The data model has to be designed to support the reporting you need, and the reporting layer has to be built.

Design Fidelity

Functional UI built efficiently costs less than a polished, pixel-precise interface with custom design work. Most internal tools don’t need the latter. Client-facing applications often do. Custom design adds scope and may involve a separate designer depending on how the project is structured.

Mobile Requirements

A web application that needs to work well on mobile is different from one that only needs to run in a desktop browser. A true native mobile app is a separate product. Responsive web apps are in between — they add scope but less than a native build.

The Number That Surprises People

The largest cost driver I see underestimated is the time it takes to get from ‘mostly working’ to ‘production-ready.’ Testing edge cases, handling errors gracefully, making the application work correctly when the network is slow or the external API is down, documenting the system, and doing the security hardening — that’s often 30-40% of total project time. Quotes that don’t account for this produce applications that work fine in a demo and badly in real use.

Phase-by-Phase Breakdown

Understanding where time goes helps make the estimate feel less arbitrary. A typical project breaks down roughly like this:

  • Discovery and scoping (10-15%): Documenting requirements, designing the data model, mapping user flows, and producing a specification detailed enough to build from. This phase is where most project failures are actually seeded — vague scope produces cost overruns and mismatched expectations downstream.
  • Core application build (40-50%): Database setup, authentication, core business logic, and primary user flows. This is where most of the visible work happens.
  • Integrations (10-20%): Connecting to external systems via API. Highly variable — a well-documented, OAuth-based integration is fast; a poorly documented or legacy system can take as long as a feature.
  • Reporting and exports (5-15%): Building query logic, dashboards, and any scheduled or on-demand exports.
  • Production hardening (20-30%): Error handling, edge case testing, security review, performance testing, documentation, and deployment. The phase most often squeezed and most often regretted.

These percentages shift depending on what the application does. An integration-heavy project may put 35% of budget into API work. An analytics-first tool may invert the reporting and core build numbers. But the production hardening percentage almost never goes below 20% on applications I’d put my name on.

What Maintenance Costs After Launch

Custom applications don’t maintain themselves. Dependencies update, hosting providers change configurations, external APIs modify their contracts, and browsers evolve. Budgeting nothing for post-launch maintenance is a common mistake, particularly for applications that connect to external systems. A lightweight maintenance arrangement — a few hours per month to keep dependencies current and catch issues — is usually far cheaper than emergency fixes when something breaks in production six months after launch. I typically recommend budgeting 10-15% of the initial build cost annually for ongoing maintenance on any application in active use.

Questions That Sharpen the Estimate Before You Get One

A rough cost range is easy to give. A useful estimate — one you can actually plan against — requires specifics. The questions that move an estimate from a range to a number:

  • What does the data model look like? How many entities, what are the relationships, are there fields with complex validation logic?
  • What integrations are required at launch vs. post-launch? Integrations that can be deferred reduce initial scope. Be honest about what’s truly needed on day one.
  • What’s the expected user volume at launch and in year two? A system that needs to handle 10 concurrent users is engineered differently from one that needs to handle 10,000.
  • Is there existing code or data to migrate? Migrations are often underestimated. Cleaning and importing legacy data is real work that belongs in the estimate.
  • Who owns the hosting and infrastructure decisions? If the client has existing infrastructure (AWS, Azure, on-premise), there are constraints and costs that come with it. If not, the project includes infrastructure setup.

Answering these before the first scoping conversation typically cuts the estimate range in half and speeds the scoping process considerably.

How to Get a Useful Estimate

The more specific your requirements, the more accurate the estimate. Useful requirements describe the workflow, the user types, the data that needs to be stored, the external systems to connect, and the outputs (reports, notifications, exports) the system needs to produce. Vague requirements produce estimates with wide ranges that don’t help you plan.

A one-hour strategy call at $500 is often useful before full scoping — it’s enough time to evaluate whether a custom build is the right direction or whether something existing covers the need. The question of whether to build at all is covered in more detail in build vs. buy.

The full picture of how a custom software project runs — from scoping through delivery — is on the software development page. If you have a specific project in mind and want a rough estimate, that starts with a conversation rather than a form.