Custom web applications: delivery and operation

When does a custom web ap­pli­ca­tion make business sense?

Custom software makes sense when standard systems force manual workarounds, restrict integrations or cannot support a process that drives sales, customer service, production or reporting. The decision should be based on measurable value, lifecycle cost and operational risk, not simply on the fact that software can be built.

Make the business decision before the technical decision

The project should have a business owner, a technical owner, a description of users and data, an availability target and a budget for development and maintenance. The biggest problems appear when a company commissions an application once and has no process for updates, monitoring, backup or incident handling after acceptance.

• Define the business objective, process outcome and metric that will demonstrate application value.
• Identify the data categories and the legal, contractual and sector requirements that apply to them.
• Set the expected availability and the maximum acceptable service interruption.
• Name the owners of decisions, risks, budget, changes and ongoing maintenance.
• Compare total lifecycle cost with buying and adapting a standard product.

Scope, requirements and success criteria

Scope must describe the process and outcome rather than only a list of screens. Functional requirements should be linked to user roles, business rules, integrations, exceptions and acceptance methods. Non-functional requirements need a separate place because they determine security and stability after launch.

• Describe the main user journeys, exceptions and operations that require approval.
• Set requirements for performance, availability, scaling and mobile device support.
• Define digital accessibility, supported browsers and the interface standard.
• Define the minimum useful first release (MVP), later enhancements and items outside the project scope.
• Give every requirement a clear acceptance criterion and an acceptance owner.

Architecture and separation of environments

Architecture should follow process criticality, data volume, integrations and the skills of the maintenance team. Even a small application requires separate development, test and production environments, protection for passwords, API keys and access tokens, versioned configuration and a reliable way to recreate the environment.

• Separate development, test and production and restrict data movement between them.
• Use synthetic or effectively anonymised data in tests. Personal data requires an established legal basis, risk assessment, safeguards and internal authorisation; do not assume general consent is sufficient.
• Document components, runtime versions, dependencies, domains, certificates and integration points.
• Keep passwords, API keys and access tokens outside source code and grant access according to role and least privilege.
• Plan scaling and high availability only where the business impact analysis justifies them.

Application se­cu­rity from design to production

Security covers business logic, code, server configuration, databases, APIs, transactional email, TLS certificates and the administration panel. Threat modelling, code review, dependency updates and testing should be part of delivery, not a one-off task just before release.

Identity, roles and privileged access

Every user should have an individual account, a role aligned with their duties and only the permissions they need. Administrative access must be separated from daily accounts, protected by MFA and logged. The access model also needs to cover service and integration accounts.

• Define business roles and a matrix of operations allowed for each role.
• Require MFA for administrators, suppliers, repositories and the hosting platform.
• Prohibit shared administrator accounts used by both the company and the supplier.
• Establish a process to grant, change, periodically review and revoke access.
• Log sign-ins, failed attempts, role changes and operations involving higher-risk data.

Data, privacy and API integrations

Before implementation, the company must know what data the application collects, where it stores it, who receives it and when it is deleted. Integrations need owners, limits, error handling and key rotation. Privacy obligations must become concrete system functions and operating evidence.

• Create a map of data, processing grounds, recipients, locations and retention periods.
• Limit collection to information required for a defined business purpose.
• Encrypt transmission and protect sensitive data in storage and backups where required.
• Validate API input and output and handle limits, errors and unavailable dependencies.
• Document keys, service accounts, webhooks and responsibility for every external service.

Source code, dependencies and solution ownership

The company must know where the repository is, who may approve changes and which licences cover the components in use. Access to source code alone is insufficient without build instructions, configuration, database migration procedures and a maintained dependency process.

• Give the company administrative access to the repository and change history from the start.
• Define copyright, licences and rules for open-source and subcontractor code.
• Require peer review and protect the main branch against uncontrolled changes.
• Scan dependencies and container images and assign an owner for updating vulnerable components.
• Prepare repeatable build, configuration and launch instructions that do not depend on one person.

Testing and acceptance criteria

Acceptance should confirm the process, security, performance, recoverability and maintenance readiness. The company accepts not only screens and features, but also documentation, logs, configuration, operating procedures and a list of known limitations.

• Run unit, integration, user-journey and regression tests for critical functions.
• Test authentication, authorisation, APIs, sessions, file uploads and business logic.
• Check performance and behaviour when integrations, databases, email or storage are unavailable.
• Prove restoration of the application and data in a separate environment before production acceptance.
• Record results, exceptions, accepted risks and conditions for resolving post-launch defects.

Deployment, change control and rollback

Deployment should be repeatable and have an approved failure-response procedure. Rolling back code does not automatically reverse data migrations or external operations. Check version compatibility, the recovery point and possible loss of new writes; a forward fix may be needed instead of rollback.

• Version source code, configuration and database migrations and tag every production release.
• Require approval for changes that materially affect security, data or business continuity.
• Back up data before schema changes and test critical integrations for backward compatibility.
• Define stop conditions, a rollback procedure and the person authorised to make the decision.
• After deployment, verify key transactions, logs, performance, alerts and certificate validity.

Hosting and maintenance architecture

The environment must be controllable and reproducible. Server resources, operating-system updates, firewalls, certificates, databases, configuration backups and an administration owner all matter. Cloud, on-premises or data centre hosting should be selected according to risk and capability, not fashion.

Backup and disaster recovery

Backups should cover the database, files, configuration, keys and the knowledge required to restart the service. A successful backup job is not proof of recoverability. Agreed RPO and RTO targets and regular tests in an isolated environment are required.

• Set RPO as the acceptable period of recent data loss and RTO as the target service-restoration time, based on business impact.
• Separate backups from production and protect them from deletion with the same credentials.
• Encrypt backups and control access, retention, location and job results.
• Test full recovery of the application, database, configuration and integrations on an agreed schedule.
• Record recovery time, issues, decisions and corrective actions after every test.

Monitoring, logs and incident handling

Monitor availability, errors, response time, certificates, resources, databases and suspicious operations. Every alert needs a threshold, priority, owner and escalation route. Logs should support diagnosis and incident investigation without recording unnecessary sensitive data.

Updates, vulnerabilities and maintenance SLA

An application starts ageing immediately after launch: libraries, systems, browsers, integrations and attack techniques change. The maintenance agreement should define priorities, response and restoration times, service windows, updates and the method for reporting and verifying defects.

• Maintain a component inventory and regularly assess vulnerability notices.
• Set deadlines for critical, high and routine fixes and for exceptions requiring risk acceptance.
• Distinguish response time, workaround time and the target time for permanent remediation.
• Define on-call coverage, reporting channels, priorities, service windows and user communication.
• Measure availability, recurring defects, repair time and update backlog instead of ticket volume alone.

Supplier contract, rights and exit plan

The contract should protect continuity when the supplier changes. The company needs rights to code and documentation, access to accounts, clear subcontracting rules and a handover process that prevents dependence on a single person or platform.

• Define ownership of source code, documentation, domains, cloud accounts, certificates and data.
• Require disclosure of subcontractors, data locations and rules for secure service access.
• Assign responsibility for updates, vulnerabilities, backup, monitoring and negligent failures.
• Ensure export of data, repositories, instructions and configuration plus a transition period for a new team.
• Test the exit plan before a crisis and revoke the previous supplier's access when cooperation ends.

Roles and stages before application launch

A clear role model connects business decisions with delivery and operation. The business owner approves outcomes and risk, the product owner orders the scope, the supplier owns delivery quality, the administrator owns the environment and the security reviewer provides independent control.

• Before delivery: confirm the process, data, owners, scope, architecture, risks and acceptance criteria.
• During delivery: establish separate environments, access, repositories, tests, backup, monitoring and change control before using production data.
• Before launch: complete acceptance, recovery and agreed security tests, and hand the application over to the support team. Confirm the launch date from test results and fulfilment of the acceptance criteria.
• In the responsibility matrix, name one approver for every decision and one escalation route.
• After launch, schedule recurring reviews of risk, access, suppliers, dependencies and recoverability.

Operating evidence and management review

Documentation should reflect reality and allow work to continue without the system author. Management needs a concise view of process coverage, availability, open risks, maintenance cost and decisions that require budget or formal acceptance.

• Maintain an architecture diagram, data map, dependency inventory and current owner list.
• Keep evidence of tests, deployments, backups, recoveries, access reviews and vulnerability reviews.
• Record exceptions with a risk owner, deadline, justification and compensating control.
• Report availability, RPO and RTO, response time, overdue patches and incidents affecting the business.
• Set the next review date and triggers for reassessment after a process, supplier or integration change.

Related Virtline areas

A secure web application connects software delivery with infrastructure, data protection and daily operation. These services help close the most common gaps before publication and after launch.