Have a web application developed – performance budget, security and a fixed go-live

A bespoke web app runs repeatable business workflows: data entry, approvals, validation, calculations and audit trails.

Unlike a marketing website, it needs roles, authentication, a data model, server-side rules and often integrations with ERP, CRM or identity providers. Typical products are SaaS platforms, customer portals and internal line-of-business applications.

SaaS adds tenant isolation, provisioning, billing and self-service; internal systems prioritise process reliability and traceable permissions. Portals expose selected data and actions without duplicating the system of record. A corporate website, by contrast, focuses on editorial content, discovery and campaigns.

This distinction changes architecture, testing, privacy and operations. Offline or push features are added only when they solve a documented need. Roles, integrations, security requirements and acceptance criteria are agreed before implementation.

A PWA makes sense for field teams, warehouse staff or shop-floor workers who must continue on unreliable networks, or where installation and push support a defined workflow.

We then design cache limits, write queues, synchronisation and conflict handling deliberately. The team also defines which records may remain on a device, when cached data expires and what happens when two users edit the same item offline.

Device loss, logout and revoked permissions belong in that model. Without a real offline or installability need, a responsive browser app is usually simpler to operate.

Service workers and local storage are reviewed against privacy and security policies, while business rules remain in testable backend services.

In a browser application, the UI lives in the tab while services and databases hold authoritative business rules.

Integrations must be versioned, observable and safe to retry. For every ERP or CRM connection we plan API contracts, error paths, monitoring and ownership. Offline queues still need consistent reconciliation when connectivity returns.

Reproducible deployments and contract tests reduce the risk that a web-app release disrupts connected systems.

An RFI should require scope, role model, API contracts, test evidence, security controls, deployment, monitoring, source-code handover and operational ownership.

The browser UI is only the visible layer; domain logic, storage and integration sit underneath. SaaS requests should also cover tenant isolation, provisioning, billing and support. Portal requests need identity integration, invitation flows and auditable permission changes.

PWA features belong in scope only when offline work, push or installation solve a documented need. Data migration, test environments, load assumptions, accessibility and exit assistance should appear as reviewable items.

A shared risk list and measurable acceptance criteria let procurement and business teams assess the same assumptions and compare suppliers on delivery evidence rather than screenshots alone.

After go-live, a productive web app needs monitoring, patching and clear ownership.

MFA, role-based access, audit trails and traceable deployments are planned before launch. PWA caching and local storage receive explicit policy limits so offline features do not expand the attack surface unchecked.

We set up alerting, backups and optional maintenance, and document who responds to security events, failed integrations and expiring certificates. Recovery and escalation are tested against realistic scenarios.

This keeps operations independent of individual knowledge and gives later releases the same quality and security gates as the first launch.