Web Applications
A web application is warranted when a business process needs to live online and no existing platform models it properly. That is a real category, and it is also what a lot of unnecessary software gets justified as.
When a custom application is justified
When the process is genuinely specific to how you operate and it is costing real time or losing real orders. Usually one of these:
- Configuration. A product with interacting options where valid combinations follow rules only your engineers know.
- Quoting. Pricing that depends on specification, quantity, materials and lead time rather than a fixed list.
- Customer portals. Order history, documentation, drawings, certificates and reordering for existing accounts.
- Internal tools. A process currently running on a shared spreadsheet that several people edit at once.
The common thread is that the process already exists and is already painful. 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 catalogue 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.
We would rather tell you that at the start than take the project.
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 genuinely 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 cannot just know. Surfacing those early is the difference between an estimate and a guess.
Integration
It 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 is the most common way custom software becomes a liability. We would rather agree that arrangement at the start than have it discovered when something stops working.
Where this fits
Inside web development. Interface and flow are UI and UX design. Where the requirement turns out to be a catalogue 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. We would rather scope a narrow first version precisely than quote a number 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 is worth asking honestly. 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 it may be sufficient, and we will say so.
See where you stand
We will review your current search visibility and show you what buyers find when they look for what you do.
Contact Us