“Web application” describes how software is accessed, not the business model behind it. An internal operations tool, a customer portal and a subscription SaaS product may all run in a browser, yet they require different approaches to users, permissions, onboarding, support, data ownership and commercial risk.
Classifying the product correctly at the start helps a business ask better questions and compare supplier proposals on the same basis. It also prevents a modest internal tool from being over-engineered like a public SaaS platform, or a commercial product from being built with the assumptions of a small staff-only system.
The three main categories
| Type | Primary users | Main purpose | Typical commercial model |
|---|---|---|---|
| Internal tool | Employees, contractors and administrators | Run or improve an internal business process | Business investment rather than a product sold to users |
| Customer or partner portal | External users with an existing relationship to the organisation | Provide secure self-service, documents, requests or collaboration | Usually supports another service or contract |
| SaaS platform | Customers who subscribe to use the software itself | Deliver a repeatable software product to multiple organisations or users | Subscription, usage-based or tiered pricing |
Internal tools
An internal tool supports work carried out by the organisation's own people. Examples include case-management systems, operations dashboards, inventory tools, approval workflows, staff scheduling, data-quality consoles and administration panels.
The value usually comes from reducing manual work, improving consistency or making responsibility visible. The product does not need a public sales journey, subscription billing or polished self-service onboarding unless those are genuine operational requirements.
Priorities for internal tools
- Clear roles and permissions aligned with business responsibilities.
- Efficient handling of frequent tasks, including bulk actions where appropriate.
- Useful validation and error messages for staff who work quickly.
- Traceability for important changes and approvals.
- Integration with the systems that already hold customer, finance or operational data.
- Practical support and training for the people who depend on the tool.
Risks in internal tools
Internal tools are sometimes treated as low-risk because the public cannot see them. In reality, they may expose broad access to sensitive records and allow users to make high-impact changes. Superuser access, exports, bulk edits and overrides need particular care.
Another risk is designing the interface around management reporting rather than the day-to-day work of staff. A dashboard can look impressive while the actual process still depends on email and spreadsheets. Observe the people doing the work before deciding which screens matter.
Customer and partner portals
A portal gives external users controlled access to information or actions connected with an existing relationship. A customer may download documents, submit evidence, track a request, update details or send a secure message. A supplier or partner may receive work, upload results or manage shared records.
The portal is normally part of a wider service. Its success therefore depends on how well it connects the external journey with the organisation's internal process.
Priorities for customer and partner portals
- Users must see only the records and documents that belong to them or their organisation.
- Onboarding and identity checks must match the risk of the service.
- Statuses and messages should be understandable without internal terminology.
- Uploads, forms and requests need clear confirmation and recovery from errors.
- Staff need an operational view for answering questions and resolving exceptions.
- The organisation needs a plan for inactive accounts, access changes and data export.
Risks in customer and partner portals
A portal can fail even when the software works technically. Customers may still telephone because statuses are vague, documents are difficult to find or the portal does not handle common exceptions. The design should reduce uncertainty, not simply move an existing form online.
Portals also require careful boundaries between organisations. A permission error that exposes another customer's information is more serious than an inconvenient interface. Access rules should be expressed as testable scenarios, not assumed from the screen design.
SaaS platforms
A SaaS platform is a software product delivered as a continuing service. The provider operates the application for multiple customers and is responsible for a repeatable model of onboarding, billing, support, updates and service operation.
The central challenge is not merely building features. It is creating a product that can serve different customers without turning every new account into a separate development project.
Priorities for SaaS platforms
- A clearly defined customer and problem rather than a broad list of possible users.
- An MVP scope that proves the operating model as well as the interface.
- Separation of customer data and administration responsibilities.
- Onboarding, account management, subscription changes and cancellation.
- Support processes, product analytics and a controlled release model.
- A roadmap that balances common product needs with requests from individual customers.
Risks in SaaS platforms
A product may be described as SaaS when it is actually bespoke software hosted separately for each customer. That can be a valid business model, but it has different costs and scaling limits. The proposal should explain what is shared, what is configurable and what requires custom work.
Another mistake is postponing billing, onboarding, support and account closure because they are not part of the “core feature”. Those activities are part of the product and can determine whether it is commercially operable.
Hybrid products are normal
Many useful systems combine categories. A SaaS company may use an internal operations console to support customers. A customer portal may include paid add-on services. An internal tool may expose selected workflows to suppliers.
Do not force the whole project into one label. Instead, identify each user group and the relationship it has with the organisation. The components may share data and branding but still require different permissions, support expectations and acceptance criteria.
How the classification changes the brief
| Decision area | Internal tool | Portal | SaaS platform |
|---|---|---|---|
| Onboarding | Managed by an employer or administrator | Linked to an existing customer or partner relationship | Designed as a repeatable product journey |
| Permissions | Based on responsibilities and operational controls | Strong separation between external accounts and organisations | Separation between tenants plus product and account administration |
| Billing | Normally not part of the product | May support payments for the underlying service | Core subscription or usage lifecycle |
| Support | Internal help and operational continuity | Customer service linked to the wider relationship | Scalable product support with service expectations |
| Change management | Training and adoption by staff | Communication to customers and staff | Release management across many customers |
| Exit | Operational continuity and access to company data | Account closure, retention and customer records | Cancellation, export, tenant closure and provider continuity |
Questions to answer before choosing an approach
- Who receives the primary value: staff, existing customers or paying software subscribers?
- Is the process specific to one organisation or intended to be repeatable across many customers?
- Who creates accounts, controls access and handles departures?
- Must data be separated by customer organisation?
- Does the system need subscription billing, trials, plan changes or cancellation?
- How will users receive support and how quickly must incidents be handled?
- Which parts may vary by customer, and which must remain standard?
- What data and technical assets must be portable if the supplier relationship ends?
Common classification mistakes
Calling every staff screen an admin panel
An administrator who configures the system is different from an operational user who processes everyday work. Combining them into one broad “admin” role can create confusing interfaces and excessive access.
Designing a portal without the internal process
A customer-facing journey cannot be specified in isolation. Every submission, message or document needs an internal owner, status and exception path.
Building a SaaS product as a series of customer-specific versions
Early flexibility can become long-term fragmentation. Decide which differences are configuration and which would create a separate product branch.
Adding commercial complexity too early
A small internal tool does not need multi-tenancy, subscription management or public onboarding unless there is a credible requirement. Architecture should reflect the likely operating model, not a distant possibility presented as certainty.
Next step
Write one paragraph for each user group describing who they are, why they use the system, what records they can access and what outcome they need. That exercise usually reveals whether the project is an internal tool, a portal, a SaaS platform or a deliberate combination of the three.