Professional technology environment representing Web Applications & Portals
02 · Software Development

Web Applications & Portals

Secure, usable web experiences for customers, teams and partners.

Registered activity62012 — Business and domestic software development
Service categorySoftware Development
Indicative duration5–12 weeks
Starting pricefrom £2,200
Client typesBusiness, organisations & private clients
Delivery areaUnited Kingdom & European Union

Create one secure digital front door for the tasks customers, teams or partners repeatedly need to complete.

Web applications and portals provide a structured digital route for customers, employees or partners to complete repeatable tasks without relying on email, telephone calls or disconnected forms. The work covers the visible user journey and the operational system behind it: authentication, permissions, records, status, notifications, administration and the way submitted information reaches the people responsible for action.

A successful portal does more than publish information. It reduces uncertainty for the user and prevents the organisation from creating a second manual process behind the interface. The scope therefore considers both sides of the service: what an external user can request or view, and how staff validate, respond, escalate and report on that activity.

When this service is usually considered.

The examples below help frame suitability. The actual requirement, risks and intended outcome are confirmed during the initial review.

  1. 01

    Customers repeatedly contact staff to submit routine requests or ask for progress updates.

  2. 02

    External users send documents and information through inconsistent email threads.

  3. 03

    Staff and customers use separate records, creating synchronisation and status problems.

  4. 04

    An existing website describes the service but does not allow users to complete meaningful tasks.

  5. 05

    Mobile users abandon a process because forms, accounts or dashboards are difficult to use on smaller screens.

What the engagement may include.

Every item is selected and bounded in the written proposal. Inclusion here describes capability, not an automatic promise that all activities fit the starting price.

01

User journeys and information architecture

Detailed routes for registration, sign-in, requests, account activity, status checks and recovery, based on the users and tasks in scope.

02

Secure account and access model

Appropriate authentication, role separation, session behaviour and privacy controls for customers, staff and partner users.

03

Forms and self-service workflows

Structured data capture, validation, document references, confirmations and clear next steps rather than untracked free-form messages.

04

Staff administration workspace

A controlled internal view for reviewing submissions, managing status, responding to users and maintaining agreed content or settings.

05

Notifications and service updates

Agreed email or in-application messages triggered by meaningful events without exposing confidential information.

06

Responsive delivery and quality checks

Interfaces designed and checked for modern desktop, tablet and mobile browsers, with accessibility and performance considered in scope.

Useful artefacts, decisions and working results.

The output is designed to support operation, delivery or a clearly defined next decision—not to create presentation volume without practical value.

01

Journey maps and functional specification

Mapped user journeys, role definitions and functional requirements for the external and internal sides of the service.

02

Interface system and responsive page flows

Responsive interface flows and a technical plan for accounts, records, workflow and any agreed connections.

03

Web application or portal implementation

A working application or portal implementing the accepted priority journeys and administration functions.

04

Quality checks, launch plan and support notes

Release checks, operating guidance, known limitations and a documented route for later enhancement.

Common use cases.

These examples show how the service can be applied. They are illustrative and do not represent claims of completed client engagements.

Use case 01

Customer account portal

Give customers one place to view details, submit requests, check progress and retrieve documents relevant to their relationship.

Use case 02

Partner or supplier workspace

Provide controlled access to shared cases, jobs, files or actions without exposing the organisation's full internal system.

Use case 03

Booking and membership services

Support availability, reservations, account records, renewals and communications around a recurring customer relationship.

Use case 04

Employee service portal

Structure internal requests, policies, approvals and status updates for staff working across locations or departments.

How NORYVIA approaches Web Applications.

The method is adapted to the service rather than repeating one generic project formula across every requirement.

01

Design the complete service journey

The user interface and the staff handling process are treated as one service so a convenient front end does not create hidden manual work.

02

Make status understandable

Users should know what has been received, what is happening next and when human contact is required.

03

Protect access by role

Customer, partner and staff permissions are separated deliberately, with sensitive actions and records limited to appropriate users.

04

Test on the devices people use

Critical journeys are reviewed across realistic screen sizes, input methods and connection conditions rather than desktop alone.

Six stages with visible decisions.

Activities can overlap where appropriate, but each stage has a clear purpose and produces evidence for the next one.

01

Audience discovery

Identify user groups, priority tasks, current contact routes and the operational team handling each request.

02

Journey and scope definition

Agree account behaviour, pages, forms, statuses, integrations, exclusions and acceptance criteria.

03

Interface and system design

Develop responsive flows, data structure, permissions and staff administration behaviour.

04

Application build

Implement the agreed journeys and back-office functions in reviewable releases.

05

Usability and acceptance

Check critical tasks, devices, validation, access levels and operational handling with the client team.

06

Launch and handover

Release the portal, provide administration guidance and record support or improvement priorities.

The disciplines brought into the work.

The precise technical or advisory depth depends on the accepted scope, available evidence and client environment.

01

User experience

  • Responsive account journeys
  • Accessible forms and validation
  • Status and activity views
  • Search and document access
  • Recovery and support routes
02

Access and workflow

  • Authentication and session controls
  • Customer, partner and staff roles
  • Submission review and approval
  • Notifications and reminders
  • Administration and configuration
03

Platform delivery

  • API and service connections
  • Privacy-aware logging
  • Performance and browser checks
  • Staged release environments
  • Operational handover documentation

Information and access needed from the client.

Good delivery depends on timely, authorised access to relevant people and evidence. Missing inputs are surfaced as assumptions or constraints rather than quietly filled with guesses.

  1. 01

    The user groups and priority tasks the portal must support.

  2. 02

    Examples of current forms, emails, documents and status communications.

  3. 03

    The staff process that begins after a user submits or changes information.

  4. 04

    Identity, privacy, accessibility and integration requirements.

  5. 05

    Content and policy material supplied in an approved form.

A defined starting point—not a blank cheque.

The displayed price is an indicative starting guide for a bounded initial engagement. Before work begins, a written proposal confirms the selected activities, deliverables, assumptions, client responsibilities, exclusions, timetable, payment schedule and any third-party costs.

Indicative engagement shapes

Focused request or account portalTypically 5–8 weeks
Multi-journey customer platformTypically 8–14 weeks
Portal with substantial integrationsPlanned as phased delivery

Factors that may change scope, price or duration

  1. 01

    Number and complexity of user journeys, roles and account states.

  2. 02

    Authentication, identity verification or payment-provider requirements.

  3. 03

    Staff administration, workflow, reporting and configuration depth.

  4. 04

    Content migration, document handling and external system connections.

  5. 05

    Accessibility, performance, testing and release requirements.

What is not automatically included.

Boundaries protect both parties from assumptions. A separate requirement can still be assessed and included where it is suitable and confirmed in writing.

01

Native mobile applications

The standard scope covers responsive browser-based delivery. Dedicated iOS or Android applications require a separate scope.

02

Third-party identity or payment responsibility

External providers remain responsible for their service, terms, availability and charges.

03

Unapproved content production

The client remains responsible for providing accurate, lawful and approved service content unless content work is expressly included.

Questions about Web Applications.

Project-specific answers depend on the current environment, intended outcome and evidence available during review.

Yes where suitable access, documentation and interfaces are available. Each connection is reviewed for ownership, security, error handling and ongoing supplier dependency before it is included.

The application is designed responsively for agreed modern browsers and critical journeys are checked at relevant screen sizes. A separate native application is not included automatically.

It can be considered, but file type, size, purpose, malware protection, retention and staff access must be defined before upload functionality is accepted into scope.

Yes. The first release can establish accounts, records and workflow foundations, with later journeys added as separate, controlled releases.

Start a conversation about Web Applications.

Use the structured questionnaire to explain the current situation. NORYVIA will review suitability and respond with questions or a proposed next step.