What is a web application?
A web application is software that runs through the browser and lets people create data and carry out transactions. The user signs in with their own account, the screens they see depend on their role, what they do is written to a database, and it usually goes on to someone else for approval or across to another system.
What separates it from a desktop program is that nothing is installed on the user's machine. The application runs on a server, updates happen in one place and everyone works on the same version. Access from outside the office is possible within whatever permission rules you set.
The difference between a website and a web application
A website focuses on presenting the company, its services or its products, and on publishing information. The visitor is mostly a reader; beyond filling in a contact form they create no record in any system.
In a web application the user signs in, creates data, carries out transactions, approves work or runs the daily operation. Its value lies not in how the page looks but in the process it runs.
This is not a technical detail. It is the first decision, and it shapes the entire scope of the project. If you are looking for a corporate site, our corporate website design and development page is the right starting point; if you need a system that runs a process, our web application development page is.
| Website | Web application | |
|---|---|---|
| Primary purpose | Publishing information, presenting the company | Running a process, capturing transactions |
| User | Usually an anonymous visitor | A signed-in user with a defined role |
| Data | Pages held in a content system | Transaction records and their relationships |
| Permissions | Usually not required | Role and permission based access |
| Integration | Usually forms and analytics | Data flow with ERP, CRM and other systems |
| Measure of success | Visibility and conversion | The operation running correctly and traceably |
Enterprise web application examples
The examples below are the processes most often moved into a web application. What they have in common is that in most companies they run today on spreadsheets and email.
- Purchase request and approval: a request is raised, checked against budget and passed to the authorised manager
- Expense and leave approvals: documents are attached, the approval chain runs, the outcome is visible on the same screen
- Dealer and B2B ordering portal: dealers order from their own price list and see their balance and shipment status
- Customer portal: order tracking, document access and raising requests
- Internal portal: announcements, documents, forms and self-service tasks
- Work order and operations screens: who the job is assigned to, what stage it is at and when it closed
- Data capture applications: audit, inspection and count forms validated and collected in one place
- Management and reporting dashboards: scattered data brought into one role-filtered screen
Sign-in, roles and permissions
The first technical thing that separates a web application from a website is authentication. The user signs in with their own account and everything they do in the system is tied to it. That is the basis of both permissions and traceability.
Role design is as much a process question as a security one: who sees which screen, who can create which document and above what amount approval is required are the business rules of the application. In companies with a corporate identity platform, sign-in can also be wired to existing accounts.
Databases and creating transactions
Every record created in the application is stored in a database and linked to the others. A purchase request is tied to the person who raised it, the budget line, the supplier and the order that follows. Because of those links, "which request did this order come from?" is answered on one screen.
The audit trail is part of the same structure. When it is visible who created a record, when, and which stages it passed through, disputes are settled from the record rather than from memory.
API and ERP integration
Most enterprise web applications do not stand alone. They read item and stock data from the ERP, write the resulting order back as a document and show the account balance from there. Without that flow the same data is kept in two places and drifts apart over time.
For companies running SAP Business One we connect the application through the service interfaces shipped with the product. That way data is exchanged without bypassing the ERP's own business rules.
Mobile use and security
A web application designed to be mobile-friendly can be used from a phone or tablet. For approving, checking status and viewing lists that is usually enough. Where the camera, barcode scanning, location or offline working are needed, a mobile application takes over.
On security, authentication, permission separation, input validation, session management and audit logging are handled from the start of the design. In portals opened to outside users those requirements go further than in an internal application.
When do you need a web application?
If several of the following are true for you, what you need is most likely a web application rather than a website.
- A critical process runs on spreadsheets that only one person can update
- Approvals happen over email and cannot be found again afterwards
- The same information is keyed into more than one system by hand
- Nobody can see from the system who did what, and when
- Dealers or customers phone in to check on things
- Producing a report means merging several files
Conclusion
A website explains; a web application runs. Naming what you need correctly means you discuss the right scope from the quotation stage onwards.
If you are considering moving processes into a web application, we can work out together which steps run in the system and which systems it needs to talk to.
Frequently asked questions
Does a web application need to be installed on users' machines?
No. It runs on a server and users reach it through the browser. Updates happen in one place and everyone works on the same version.
Can it be built inside our existing website?
Setting it up as a separate application is usually the better route. A public site and a business application behind a login have different security, backup and update requirements. The two can still link to each other.
Does a web application replace our ERP?
No, it generally complements it. Side processes that do not belong in the ERP but depend on ERP data run in the web application, and the outcome is written back to the ERP as a document.
Is access from outside the company safe?
For applications opened to the outside, authentication, permission separation, data isolation and audit logging are designed in from the start. These requirements are treated as a separate item in the scope.