A custom software development implementation readiness checklist should answer whether an organization is ready to learn through delivery, not whether every requirement has been frozen. Readiness means the problem and user groups are understood, a service owner can make decisions, constraints and risks are visible, a multidisciplinary team is funded, and the organization can operate the resulting system. Starting with an attractive feature list but no authority, data access or support model produces motion without dependable progress.
Use this checklist before committing to a major build or supplier statement of work. The custom software delivery plan explains the planning approach, while the implementation FAQ addresses common procurement questions. Treat uncertain answers as discovery work, not as reasons to invent confidence.
1. Confirm there is a problem worth solving with software
Name the people affected, the task they need to complete, the current process, failure consequence and evidence. Observe real work and artifacts. Quantify volume, delay, error, support effort and opportunity where possible, but retain qualitative context. GOV.UK’s discovery guidance recommends understanding users, constraints and the wider problem before committing to build. A spreadsheet, process change or configured platform may solve the need more economically than custom software.
Write a one-sentence intended outcome and the evidence that would change the investment decision. Identify the riskiest assumption: user adoption, data quality, policy permission, technical feasibility or operating economics. Run a small research or prototype test before detailed estimation. Define who may stop or redirect the initiative. Continuing only because budget was approved is not product governance.
| Readiness question | Useful evidence | Warning sign |
|---|---|---|
| Who has the problem? | Observed users and coherent segments | Only executive opinion |
| What is the consequence? | Delay, error, risk, cost or missed outcome | Generic modernization language |
| Why software? | Options compared with constraints | Chosen vendor or technology before discovery |
| How will success be known? | Baseline and measurable outcome | Delivery date is the only metric |
| Who decides? | Named service owner with authority | Committee without accountable owner |
2. Define the whole service and the first delivery boundary
Map the journey across digital and non-digital channels, internal teams, suppliers, policy decisions and support. Custom software is one component of a service. Include assisted paths, exceptions, approvals, communication, billing, reporting and closure. Define what is inside the first release and what remains manual or external. Make exclusions visible to business sponsors and users. A narrow vertical slice through the complete service is more informative than several disconnected interface screens.
Write acceptance criteria around outcomes and boundaries: supported users, data classes, volumes, integrations, devices, hours, recovery, accessibility and known limitations. Identify claims that create obligations, such as real time, automated compliance, secure, global or always available. Replace them with measurable definitions. The GOV.UK Service Standard is public-sector guidance, but its emphasis on users, whole problems, accessibility, multidisciplinary teams, security, measurement and reliable operation is a useful general quality lens.
3. Inspect data, integration and migration reality
Identify authoritative records, owners, identifiers, quality, sensitivity, retention and access. Obtain representative samples through an approved process. Do not estimate migration from a column list alone; profile duplicates, missing relationships, free text, attachments, encoding and historical rules. Define reconciliation and rollback. Decide which legacy history genuinely needs migration and what can remain read-only or archived. Assign who resolves ambiguous records.
For every integration, record owner, purpose, interface, authentication, authorization, limits, latency, availability, versioning, sandbox, error contract and support. Test at least one representative call early. Identify manual file exchanges and browser automation, which are still integrations with reliability and security risk. Define how duplicate, late and partial events behave. Keep a dependency register and confirm supplier change windows and test access before committing to dates.
| Area | Ready evidence | Stop condition |
|---|---|---|
| Data authority | Owner and source of truth named | Teams disagree on authoritative record |
| Migration | Profile, mapping and reconciliation plan | No representative data access |
| Integration | Test path, limits and error behavior | Critical supplier interface unknown |
| Identity | User, role and recovery model | Shared accounts required |
| Operations | Monitoring, backup and support boundary | No team accepts live ownership |
4. Fund the team, decisions and delivery controls
A custom product needs product management, user research, service design, engineering, quality, security, accessibility, data and operations skills in proportions appropriate to the work. Named people need time, not advisory titles. The service owner controls outcome, scope and risk acceptance; technical leaders own architecture and engineering quality; operational owners prepare support and recovery. Define supplier and internal responsibilities, including access, repositories, environments and intellectual property.
Establish repositories, issue tracking, decision records, environments, automated build and deployment, code review and artifact protection before volume grows. Break work into demonstrable slices and review with users frequently. Keep architecture decisions linked to constraints and revisit triggers. Estimate ranges with assumptions, dependencies and confidence. Track outcome and risk alongside budget and schedule. A fixed date may be real, but then scope and operating risk must be managed honestly.
5. Make security, privacy and accessibility release criteria
Threat-model the service boundary, data, privileged actions, integrations, administration and support. Select a secure-development baseline. NIST’s SSDF addresses preparation, software protection, secure production and vulnerability response. OWASP ASVS turns many web-security expectations into verifiable requirements. Define identity assurance, server-side authorization, tenant isolation, secrets, logging, dependency management, incident contact and vulnerability handling before production.
Accessibility must shape design and implementation. Identify user access needs, procurement obligations and target standard. Use semantic controls and a governed design system, then test complete journeys with keyboard, screen reader, zoom, reflow and realistic errors. WCAG 2.2 applies to responsive page variations and complete processes. Include external identity, payment and document steps in the assessment. Assign remediation ownership and prevent repeated defects through components, tests and review.
6. Design operation, support and recovery before launch
Define service hours, users, support channels, severity, escalation, monitoring, on-call needs, backup, restore, recovery objectives, status communication and supplier contacts. Build health signals around customer journeys and dependencies, not server uptime alone. Provide runbooks for representative failures and test access. Operations should rehearse a failed deployment, identity outage, dependency timeout, data correction and restore. Direct database edits must not be the normal recovery mechanism.
Plan data retention, export, account closure and supplier exit. Retain authoritative source, infrastructure definitions, configuration and decision history in controlled accounts. Define ownership after the project team changes. Budget for maintenance, vulnerability response, platform updates, support and incremental improvement. A successful launch without a funded operating team creates an unsupported liability.
7. Use a pilot and evidence-based go-live decision
Select a representative cohort and time-bound the pilot. Measure task completion, outcome, error, support demand and performance against a baseline, combining metrics with research as GOV.UK’s measurement guidance recommends. Include difficult cases and different access needs. Track manual help outside the product. Define counter-evidence and stop conditions before launch so weak results cannot be reinterpreted as success.
Go-live acceptance should bring product, users, operations, security, accessibility, data and business ownership together. Inspect working evidence: completed journeys, denied unauthorized actions, reconciled migration, monitored dependencies, support handling, restore result and rollback or suspension. Record residual risks with consequence, compensating control, owner and expiry. Release progressively and review early production cohorts before expanding.
8. Complete commercial and supplier readiness
Define the commercial model around outcomes, team capacity, assumptions and change. Fixed-price delivery can work for a stable bounded component; uncertain service transformation needs discovery and incremental decisions. State what customer participation, data and supplier access are assumed. Separate licenses, cloud consumption, third-party APIs, support and transition from build fees. Require transparent rates or mechanisms for scope change so pressure does not turn into hidden quality reduction.
Contracts should address repositories, source, infrastructure definitions, documentation, test evidence, design assets, data handling, subcontractors, incidents and vulnerability response. The organization should own production accounts and domains or have a documented transfer path. Define acceptance by working evidence, not delivery of files. Include warranty or defect handling, service levels where relevant, data return, deletion and practical exit assistance.
Assess supplier continuity and key-person risk. Know which skills remain internal, who can deploy or recover without one individual, and how credentials are revoked. Schedule knowledge transfer throughout delivery through paired work, reviews and operational exercises. A final handover presentation cannot replace practiced access. Preserve architecture and product decisions in shared systems the organization controls.
Key takeaways
- Prove the user and business problem before selecting the solution.
- Define a whole service and deliver one narrow end-to-end slice.
- Profile real data and test critical integrations before committing to dates.
- Fund accountable product, engineering, assurance and operations capability.
- Make security, accessibility, recovery and measurable outcomes part of acceptance.
Frequently asked questions
Do requirements need to be complete before development starts?
No. Outcomes, constraints, critical rules and the first boundary must be clear enough to test. Detail should evolve through research and delivery. Freeze only interfaces or obligations that genuinely require stability.
How much contingency should a project include?
There is no universal percentage. Fund discovery and risk reduction first, estimate in ranges, and keep explicit capacity for data, integration and operational uncertainty. Reforecast as evidence improves rather than hiding uncertainty inside one number.
Can a vendor own the whole implementation?
A vendor can deliver and operate defined work, but the organization must retain service ownership, risk decisions, data authority and enough capability to verify outcomes and exit. Make access, evidence, repositories and transition explicit in the agreement.
Conclusion
Custom software is ready to implement when the organization can connect a real problem to an owned service, inspect its technical reality and learn through safe increments. Evidence about data, integrations, users, controls and operation matters more than a long specification. This readiness creates room for discovery without turning customers or operators into the place where avoidable risk is discovered.