A web application is warranted when a business process needs to live online and no existing platform models it properly. That's a real category, and it's also what a lot of unnecessary software gets justified as.
When a Custom Application Is Justified
When the process is specific to how you operate and it's costing real time or losing real orders. Usually one of these:
- ConfigurationA product with interacting options where valid combinations follow rules only your engineers know.
- QuotingPricing that depends on specification, quantity, materials and lead time rather than a fixed list.
- Customer PortalsOrder history, documentation, drawings, certificates and reordering for existing accounts.
- Internal ToolsA process currently running on a shared spreadsheet that several people edit at once.
Building software for a process nobody performs yet is how projects fail.
When It Is Not
When an existing platform does most of it. A catalog is a store. A form is a form. A document library is a page with files on it.
"Off the shelf does 80% of what we need" is usually an argument for taking the 80% and living with the rest, not for building 100% from scratch. The missing 20% costs more than the 80% did, and then it needs maintaining forever.
How the Process Runs
| Stage | What happens |
|---|---|
| Define the process | Document how the work is done now, including the exceptions people handle by hand. The exceptions are where projects overrun |
| Cut the scope | Identify the smallest version that is useful in production |
| Model the data | Decide the structure and where the source of truth lives, before any interface work |
| Build it narrow | Ship the core workflow, use it with real data, and let that direct what comes next |
| Extend deliberately | Add from evidence of use rather than from the original wish list |
The step that gets skipped is documenting the exceptions. Every business process has cases handled by somebody who just knows what to do, and software can't just know. Surfacing those early is what makes the estimate reliable.
Integration
Integration is usually the hard part. Connecting to an ERP, an accounting system or a CRM means dealing with whatever interface that system offers, which is sometimes a modern API and sometimes a scheduled file drop.
The question to settle first is which system is authoritative for each piece of data. Two systems that both think they own stock levels will disagree, and reconciling that afterwards is far harder than deciding it upfront.
Should It Be Public or Behind a Login?
Both have consequences worth deciding deliberately. A public configurator can be found in search and used by prospects you never spoke to. A login protects pricing and account data but is invisible to everything outside it.
A common workable split is a public tool that produces a specification or an indicative figure, with account pricing and ordering behind authentication.
Who Maintains It Afterwards?
Somebody has to, explicitly. An application has dependencies that need updating, integrations that break when the other end changes, and users who find edge cases.
Budgeting for the build and not for the years after it's the most common way custom software becomes a liability. That arrangement should be agreed before the build starts.
Where This Fits
Inside web development. Interface and flow are UI and UX design. Where the requirement turns out to be a catalog after all, e-commerce is the cheaper answer.
Frequently Asked Questions
Can You Give a Fixed Price?
For a well-defined first phase, yes. For an open-ended build, a fixed price is either padded heavily or becomes an argument later. A narrow first version scoped exactly is better than a number quoted for something neither side has defined.
Who Owns the Code?
You do, in your repository. No dependency on us continuing, and any competent developer can take it over.
Could This Be a Spreadsheet Instead?
Sometimes, and it's worth asking. A spreadsheet breaks down when several people edit simultaneously, when the rules get too complex to trust, or when customers need access. Short of that, a spreadsheet may be enough.