This digital solutions FAQ is for leaders deciding whether to improve a service with software, data, automation or connected channels. A digital solution is not automatically a new application. It may be a redesigned workflow supported by existing systems, an integration that removes re-entry, a self-service journey with assisted support, or a custom product. The right answer depends on user need, operating change, information, risk and whole-life ownership. These questions turn a broad ambition into decisions a multidisciplinary team can test.
For a detailed sequence, use the digital solutions delivery plan and digital solutions implementation checklist. Larger organizations can compare the enterprise digital solutions checklist. The answers below assume the organization will remain accountable for the service even when suppliers build or operate parts of it.
What counts as a digital solution?
A digital solution combines a user or employee journey, operational process, information, technology and support model to achieve an outcome. It can include web or mobile interfaces, APIs, workflow automation, analytics, identity and integration with physical or human channels. Defining it as a service prevents the team from optimizing a screen while leaving manual verification, call-center work or inaccessible exceptions unresolved. The boundary should include what happens before, during and after the digital interaction.
The UK Service Standard is a useful public reference because it joins user needs, whole-problem design, accessibility, multidisciplinary teams, security, success measures and operation. Commercial organizations can adapt those principles without copying government governance. Begin by observing real work and measuring the current journey. A technology choice should follow evidence that a specific constraint is worth changing.
Should we build, buy, configure or integrate?
Compare options against differentiating workflow, time to value, fit, data control, integration, accessibility, security, scale, operating skills and exit. Buy or configure when a mature product covers the process and adapting the organization is acceptable. Integrate when existing systems already hold the right capabilities but handoffs are poor. Build when the workflow creates material advantage or constraints cannot be met responsibly by available products. Hybrid choices are common, but every added boundary creates ownership and failure work.
| Option | Strong fit | Evidence before commitment | Hidden cost to test |
|---|---|---|---|
| Buy | Standard capability with mature market | Scenario demo using representative data | Licensing, limits, migration and exit |
| Configure | Stable process with bounded variation | Prototype of roles and exceptions | Upgrade-safe customization |
| Integrate | Capabilities exist but journeys fragment | API, event and failure-path proof | Reconciliation and vendor change |
| Build | Distinct workflow or hard constraints | Discovery and architecture spike | Long-term product ownership |
| Retain | Change value does not justify disruption | Measured baseline and risk acceptance | Growing manual and legacy burden |
What should discovery produce?
Discovery should identify users, needs, current alternatives, policy and business rules, data, systems, exceptions, risks and baseline performance. It should test the riskiest assumptions through research, prototypes or technical spikes. Useful outputs are an outcome statement, service map, prioritized risks, option decision, first thin release, quality scenarios, operating implications and a range forecast. A large backlog is not proof of understanding; unresolved assumptions should remain visible.
Include people who use assisted channels, abandon the current process or handle exceptions. Observe operational staff, not only sponsors. Map where records become authoritative and where duplicate entry or informal spreadsheets compensate for system limits. End discovery with a fund, reshape, buy or stop decision. When proceeding, preserve links between evidence and planned work so later scope changes can be evaluated against the original problem.
How should cost and timeline be estimated?
Estimate ranges from a thin architecture and delivery plan, then update with evidence. Include research, design, engineering, data work, integration, migration, assurance, environments, licenses, cloud, training, support, compliance and client decisions. Timeline depends on uncertainty and external dependencies more than screen count. Use scenarios for expected, constrained and adverse conditions. Publish assumptions and confidence, and keep contingency controlled by risk rather than distributing it invisibly across every task.
Fund increments that produce usable evidence. A first vertical release should pass through identity, rules, data, integration, telemetry and support for a narrow journey. Review actual throughput, rework and risk before forecasting later releases. Avoid interpreting agile delivery as an absence of commitments: teams can commit to outcome, budget guardrails, quality and review dates while keeping uncertain solution details adaptable.
Which quality requirements matter from the start?
Define performance, reliability, security, accessibility, privacy, maintainability, compatibility and recoverability according to context. ISO/IEC 25010:2023 provides a current product quality model for checking coverage. Turn selected characteristics into measurable scenarios: users, conditions, stimulus, response and threshold. “Fast and secure” is not testable; a stated journey percentile at expected load and a defined authorization rule are.
Accessibility belongs in research, component design, content, testing and support. W3C WCAG 2.2 supplies testable web-content criteria, but automated tools cover only part of the experience. Test keyboard operation, focus, zoom, reflow, screen readers, errors and time limits with representative users where feasible. Provide a supported alternative route without making disabled users prove they deserve it.
How are security and privacy built into delivery?
Classify information, map trust boundaries, identify abuse cases and choose controls before detailed build. Protect repositories, build identities, dependencies, secrets, test data and deployment authority. NIST’s SSDF can be mapped to local evidence across organizational preparation, software protection, secure production and vulnerability response. Apply least privilege and verify authorization server-side. Threat and privacy reviews should recur when design or data use changes.
Collect only information needed for a defined purpose, document retention and deletion, and test rights or correction workflows where applicable. Keep sensitive values out of logs and analytics labels. Agree incident detection, escalation, evidence and communication with suppliers. Security acceptance includes normal controls, abuse paths, dependency risk, remediation and recovery; a late penetration test cannot compensate for an architecture that grants excessive access.
| Release gate | Question | Evidence | Stop condition |
|---|---|---|---|
| Outcome | Does the slice solve a measured need? | User research and journey measure | No accountable outcome owner |
| Quality | Are critical scenarios met? | Automated and targeted manual tests | Material threshold failure |
| Data | Are migration and reconciliation controlled? | Trial migration and totals | Unexplained loss or duplication |
| Operation | Can teams detect and recover? | Telemetry, runbook and exercise | No tested support or rollback |
| Ownership | Can the organization sustain it? | Repository, skills, budget and decisions | Supplier-only critical access |
What happens after launch?
Launch begins a learning phase. Instrument task success, abandonment, errors, latency, support demand, incidents and unit cost without excessive surveillance. Compare segments and channels so a good average does not hide exclusion. Define service objectives and escalation. Keep a persistent team or clear capacity for vulnerabilities, platform updates, user research and improvement. GOV.UK guidance on sustainable service operation correctly treats continuous improvement as lifecycle work rather than optional maintenance.
Review outcome, reliability, security, accessibility, cost and technical health together. Remove unused features and telemetry. Rehearse restore and supplier transition. Maintain API contracts, architecture decisions and runbooks as part of delivery. A solution is sustainable when named people can change, support, recover and eventually retire it without reconstructing intent from old tickets.
Example: redesign an employee approval service
An organization replacing email approvals should begin by observing requesters, approvers, finance staff and auditors. The service map may reveal that delay comes from missing evidence and unclear delegation, not the email interface. The first digital slice can validate required fields, route one request type, show status and preserve a decision record. It should also provide an assisted route for staff who cannot use the primary interface. Integration with finance can initially be a controlled export if the API risk would delay useful learning.
Acceptance combines task completion, decision time, accessibility, authorization, audit history and support. After a limited release, the team compares incomplete submissions, approval duration, overrides and help requests with baseline. If users create side spreadsheets because they cannot correct a request, that behavior is product evidence, not resistance to change. The next increment should fix correction and exception handling before automating more categories.
Whole-life ownership is assigned at the same time. Product owns policy and outcome, operations owns the working process, engineering owns service health, and finance confirms reconciliation. The team budgets platform upgrades, vulnerability work and user research after launch. This small service example shows why a digital solution includes decisions, people and operation: a polished form without delegation, correction and records would digitize the visible step while preserving the original failure.
Before wider rollout, test policy changes, approver absence, duplicate submission, notification failure and downstream rejection. Publish a service status route and train support from real pilot questions. Remove the old email path only after active cases are reconciled and records retained correctly. This transition work protects trust: users should know which channel is authoritative, how to recover an incomplete request and where a disputed decision can be reviewed.
Key takeaways
- Define a digital solution as a whole service, including people and exceptions.
- Choose build, buy, configure or integrate through representative evidence.
- Estimate and fund vertical increments with explicit quality and operating cost.
- Design accessibility, security, privacy and recovery before release.
- Maintain product ownership and continuous improvement after launch.
Frequently asked questions
Can an MVP omit security or accessibility?
No. Reduce feature scope while preserving essential duties for the context. An MVP must be safe and usable enough to test a value hypothesis without creating avoidable harm or debt that invalidates the evidence.
Can a vendor own the digital solution end to end?
A vendor can perform substantial delivery and operation, but the organization needs an accountable service owner, access to evidence, control of key decisions and a transition route. Business, legal and customer accountability cannot simply be outsourced.
Conclusion
A useful digital solution starts with a service outcome and remains accountable through discovery, option choice, quality, secure delivery and operation. Ask what problem is changing, what evidence supports the approach, how failure is handled and who owns the lifecycle. Those questions keep technology in service of people and measurable work.