Technology decisions become business decisions when they affect reliability, ownership, operating effort, supplier dependence or the movement of important data. A CRM may look straightforward until it must exchange records with finance software. A customer portal may work well in a demonstration but fail when files grow, notifications are delayed or an external service becomes unavailable. A SaaS product may gain customers while its monitoring, backups and data model remain designed for a much smaller operation.
This section is for UK business owners, operations managers and product teams who need to ask sensible questions without pretending to be infrastructure or security specialists. It explains the main decision areas, the evidence to request from a supplier and the point at which a general commercial discussion should be handed to an appropriately qualified technical, security or data-protection reviewer.
The aim is not to choose fashionable technology. It is to create a system that can exchange data predictably, recover from failure, remain understandable to a future supplier and support the workflows the business actually depends on.
| Decision area | Business question | Evidence to request |
|---|---|---|
| APIs and integrations | Which systems exchange which data, in what direction and under whose control? | A data-flow description, failure scenarios, ownership of credentials and a tested reconciliation process. |
| Cloud and hosting | Who operates the infrastructure, what is included and how difficult would it be to move? | An environment inventory, responsibility matrix, backup arrangements, support boundaries and an exit plan. |
| Identity and access | How are users, administrators and connected systems authenticated and authorised? | Role definitions, privileged-access controls, account lifecycle rules and review procedures. |
| Backups and recovery | What can the business afford to lose, and how quickly must service return? | Recovery objectives, backup coverage, restore instructions and evidence from recent recovery tests. |
| Monitoring and operations | How will the business know that the system or an integration has failed? | Defined service signals, alert ownership, escalation paths, logs and incident records. |
| Data management | Is the data accurate, portable, understandable and governed throughout its lifecycle? | Data ownership, field definitions, validation rules, migration evidence and export formats. |
| Performance and scale | What response times and volumes must the system support now and later? | Measurable performance criteria, representative tests, capacity assumptions and monitoring thresholds. |
| Files, search and communications | How will users store, find and receive the information needed to complete work? | File rules, search acceptance tests, delivery-failure handling and channel-specific responsibilities. |
Begin with dependencies, not products
A technology discussion often starts too late in the decision process. Teams compare cloud platforms, databases or integration tools before they have documented what the business process depends on. That reverses the order. The first task is to identify the important workflows, the systems involved and the consequences of delay, duplication or loss.
For each workflow, record the source of truth for the data, the people or systems allowed to change it, the expected timing and the exceptions that require manual attention. An integration that copies customer records once each night carries different operational risk from one that must confirm a payment before an order can proceed. Both may be described as “an API integration”, but they need different monitoring, recovery and acceptance criteria.
This dependency map also prevents suppliers from treating every technical component as an isolated line item. Hosting, backups, monitoring and support must be considered together because a recovery plan cannot work if the required credentials, configuration or third-party accounts are missing.
APIs and data exchange
An API is a structured way for software systems to exchange requests and data. From a business perspective, the important questions are not limited to the protocol used. You need to know what information moves, which system owns the master record, how duplicate or conflicting updates are handled and what happens when either side is unavailable.
The scope should distinguish between consuming an existing third-party API and designing a new interface that other systems will depend on. A new API usually requires decisions about authentication, permissions, versioning, documentation, rate limits, error responses and support. Those responsibilities should not disappear inside a single estimate line called “integration”.
Acceptance should include failed and delayed scenarios as well as successful transfers. Ask how the system detects a missed event, whether work can be replayed safely, how the teams reconcile differences and who investigates when each supplier claims the other system is responsible.
Cloud services and hosting
Hosting determines where the application runs, but the commercial decision is broader. It affects responsibility for operating systems, databases, updates, monitoring, capacity, backups and incident response. A managed service may reduce routine administration, while an unmanaged arrangement may offer greater control but require skills the business or supplier does not consistently possess.
Before choosing a provider, separate platform capability from the way the application will actually be configured. A strong provider does not compensate for weak access controls, missing backups or an architecture that depends on undocumented manual work. Equally, a portable design is not created simply by avoiding one named cloud vendor. Portability depends on data exports, infrastructure records, deployment instructions, standard components and the ability to recreate the environment elsewhere.
The business should retain visibility of the accounts, billing, domains, certificates and administrative access on which the service depends. The supplier can operate those assets, but the exit position should be understood before launch rather than reconstructed during a dispute.
Identity, access and security boundaries
Authentication confirms who or what is making a request. Authorisation determines what that identity may do. Business systems need both at several levels: ordinary users, managers, administrators, support staff, automated integrations and infrastructure operators.
Roles should be based on real responsibilities rather than job titles copied from an organisation chart. The design needs to cover approvals, exceptions, temporary access, staff departures and privileged actions that require additional evidence. Search results, exports, notifications and APIs must apply the same access rules as the main screens; hiding a button does not protect the underlying data.
Security-sensitive decisions should be reviewed by an appropriately qualified specialist. The editorial guides in this section help a buyer define scope and ask questions, but they do not replace threat modelling, configuration review, penetration testing or current legal and data-protection advice where those are required.
Backups and disaster recovery
A backup is a copy. Recovery is the tested process that turns available copies, configuration and knowledge into a working service. The plan therefore needs to cover more than the primary database. It may require uploaded files, application configuration, infrastructure definitions, encryption keys, third-party settings and the instructions needed to restore them in the correct order.
Recovery priorities should come from business impact. The acceptable amount of lost work and the acceptable duration of disruption should be agreed for each important system or workflow. These objectives then inform backup frequency, storage separation, replication and the level of investment in standby infrastructure.
Evidence matters. A supplier saying that backups run every night does not confirm that they contain everything required or that anyone can restore them. Ask for test records showing what was restored, how long it took, what failed and which improvements were made afterwards.
Monitoring and operational response
Monitoring should reveal whether users can complete important work, not merely whether a server responds. A portal may be technically online while logins fail. A CRM may load while its accounting integration silently stops. A reporting screen may open while the overnight import has not updated the data.
Define the signals that represent business health: availability, error rates, response times, queued work, failed integrations, delayed jobs and unusual resource consumption. Then define ownership. Every actionable alert needs a recipient, an escalation route and a clear expectation about what happens outside normal working hours.
Logs and metrics should support investigation without collecting unnecessary sensitive information. Retention, access and cost need deliberate limits. Monitoring data can grow quickly, and a dashboard that nobody understands or checks does not create operational assurance.
Data quality, migration and governance
Data decisions begin with meaning. Two systems may both contain a field called “status” while using different values and business rules. Migration and integration work must therefore map concepts, relationships and exceptions rather than simply align column names.
Before migration, profile the source data and decide how duplicates, incomplete records, unsupported values and historic information will be handled. Keep a record of transformation rules and reconciliation totals so that the business can explain what changed and verify that important records arrived correctly.
After launch, ownership remains necessary. Someone must be accountable for definitions, quality rules, access decisions and changes to important fields. Archiving and disposal also need to be separated from ordinary backup retention: an operational recovery copy serves a different purpose from a business record that must remain available or be removed under an approved policy.
Performance, capacity and scalability
“The application should be fast” is not an acceptance criterion. Performance should be described using representative actions and conditions: how long a common search may take, how many records a report processes, how many concurrent users are expected and how the system behaves during a traffic spike or dependency slowdown.
Test data needs to resemble the expected production volume. A screen that performs well with fifty records may become unusable with fifty thousand. Database indexes, caching and additional infrastructure can help, but each has trade-offs. The right answer depends on the workload, data pattern, recovery needs and operating budget.
Capacity planning should identify the signals that trigger action before users are affected. That may include storage growth, queue depth, database load, response-time percentiles or third-party rate limits. The supplier should explain both the likely next scaling step and the practical work required to carry it out.
Files, search and communications
Files need their own lifecycle. The business should define allowed formats, expected sizes, access rules, metadata, versioning, processing and removal. Large media files may require different storage and delivery patterns from ordinary documents. Upload behaviour should also account for failed transfers, duplicate submissions and the need to preserve an audit trail.
Search should be planned around user tasks. Decide which records and fields are searchable, how permissions affect results, when exact identifiers take priority and how ranking will be tested with real queries. Full-text search, filters and cross-system search solve different problems and should not be treated as interchangeable features.
Email, in-app messages, SMS and push notifications are operational channels. The design needs to state which event triggers a message, whether it is informational or requires action, how delivery failures are handled and where a durable record is kept. A message should not become the only evidence that a business action occurred.
Mobile and cross-platform delivery
A responsive web application is often the most efficient starting point for internal tools and occasional customer access. Progressive web capabilities can add installation, selected offline behaviour and web push where the target platforms support them. Native or cross-platform mobile apps become more attractive when the workflow depends on extensive offline use, specialised peripherals, sustained background work or a conventional app-store distribution model.
These boundaries change as browsers and operating systems evolve, so capability claims should be checked on the actual devices before a delivery approach is fixed. The acceptance plan should cover permissions, interrupted connectivity, synchronisation conflicts, older app versions and the relationship between the mobile client and the shared backend.
A practical decision sequence
- Map the business workflow, source systems, users and critical dependencies.
- Identify the data, files and messages that move through each step.
- Define permissions, failure scenarios and the evidence needed for acceptance.
- Agree recovery objectives, monitoring signals and operational ownership.
- Choose technology only after the required responsibilities and constraints are visible.
- Record accounts, credentials, configuration, licences, documentation and exit dependencies.
- Test with representative users, data volumes and failure conditions before launch.
Questions to put to a supplier
- Which systems, providers and accounts are essential to the service, and who controls each one?
- Where is the source of truth for each important category of data?
- How are failed integrations detected, replayed and reconciled?
- What is backed up, how has recovery been tested and who can perform it?
- Which business transactions are monitored rather than merely checking server uptime?
- What performance and capacity assumptions underpin the estimate?
- How are administrative access, credentials and staff departures managed?
- What documentation and export capability would a replacement supplier receive?
- Which claims require a current security, legal or data-protection review before the business acts?
The strongest technology plan is not the one with the most services or the newest architecture. It is the one that makes responsibilities, dependencies, evidence and exit options clear enough for the business to operate the system confidently after the original build team has moved on.