A custom software project should not be a relay race between requirements, design, code, testing and launch. Each stage should reduce uncertainty, produce useful evidence and leave the business able to make the next decision with more confidence.
01
A development process should reduce uncertainty, not only organise work
A seven-step diagram can make custom software development look reassuringly tidy. Requirements go in at one end, then planning, design, development, testing and deployment happen in order. A finished application appears at the other end. Real businesses are rarely that polite.
Imagine a specialist services company that wants a customer onboarding portal. New customers currently send forms, identity details and supporting documents by email. Staff copy the information into a spreadsheet, check it, request anything missing, create records in other systems and tell finance when the account can be opened.
The first conversation may produce a sensible feature list. The difficult rules appear when people see the proposed workflow. One customer type needs an extra approval. A document can expire during review. An external system only accepts certain data. Finance needs the approved values, not the first version supplied.
A useful custom software development process exposes those details while they are still cheap to change. It does not promise that every uncertainty will disappear before coding begins. It creates a controlled way to learn, build, test and decide what deserves more investment.
02
Start with the business outcome and the current operation
The first job is not to collect every feature somebody can imagine. It is to understand what the business wants to improve and how the work happens today.
For the onboarding portal, the outcome might be to make complete applications easier to submit, give staff one clear review queue and reduce repeated entry into finance and customer systems. That is more useful than a goal such as build a modern portal because it explains what the software must change.
Follow representative cases from beginning to end. Speak to the people who submit information, review it, answer questions, approve exceptions and support customers. Record the unofficial steps as well as the written procedure. The workaround everybody uses on a Friday afternoon often explains more than the process document written three years ago.
Discovery should also identify the data involved, user roles, integrations, legal or contractual constraints, expected volume and current measures. If the existing process takes eight days, nobody can later claim success from a new seven-day process without knowing that baseline.
03
Discovery should be allowed to stop the build
A serious discovery phase can conclude that custom software is not the best next step. The current product may be configurable. A missing integration may explain most of the repeated work. The process may need simplifying before it is automated. That is useful evidence, not a failed sale.
The GOV.UK Service Manual describes discovery as understanding users, constraints and the problem before committing to build. A commercial project can use the same principle without copying the full public-sector process. The amount of discovery should match the size and risk of the decision.
For the example portal, discovery might reveal that document review is the distinctive workflow, while identity checks, payments and accounting are better handled by proven specialist services. That finding creates a clearer boundary and avoids paying to rebuild ordinary capability.
Discovery is complete when the business can decide whether to stop, improve an existing tool, test an uncertain idea or fund a defined first release. A thick requirements document is not the objective. A better decision is.
04
Prototype the risky parts, not every possible screen
Some questions cannot be settled through conversation. People need to see the proposed sequence, try realistic examples and notice what feels missing. A prototype makes those assumptions visible before production code makes them expensive.
The onboarding prototype could cover three moments: a customer submitting evidence, a reviewer deciding whether the case is complete and the system asking for missing information. Sample records can expose confusing language, unclear ownership and exceptions that a list of fields will hide.
Technical uncertainty may need a different prototype. A short integration test can check whether an external service exposes the required data, whether its response is fast enough and what happens when it is unavailable. A data exercise can test whether the existing spreadsheet contains consistent references for migration.
A prototype is built to answer a question. It may be thrown away once the answer is known. Polishing every screen or quietly treating prototype code as the production foundation defeats the point. The result should be a decision about what to build, change or remove.
05
Shape one complete first release
Once the important assumptions have been tested, the first release needs a clear edge. The safest scope is one complete journey that reaches a useful business outcome, not the first layer of every future module.
For the portal, the first release could begin when a customer starts an application and end when an approved customer record reaches the existing finance system. It would include required information, document collection, review, requests for missing evidence, approval history and the final integration. Marketing automation and a replacement accounting package can stay outside the boundary.
Write down what the release includes, what it deliberately excludes, which user roles are involved and what each role must be able to complete. Record the acceptance rules using real examples. A statement such as staff can review an application is weaker than a scenario showing the documents, decisions, permissions and history that make a review complete.
The first release should also have measures. Completion rate, time to a first review, number of requests for missing information and manual entries into other systems may be useful. Choose measures that connect to the original problem, not numbers that are easy to display on a dashboard.
06
Build and review the system in working slices
Design, development and testing should not behave like separate departments passing a parcel along. A screen can look finished while the underlying permissions, data rules and failure paths remain unknown. A working slice connects those parts early enough for the business to review the real behaviour.
The first slice might let a customer create a draft application and let a reviewer open it. The next could validate required evidence and record an information request. Another could complete approval and send the agreed record to finance. Each slice adds a usable part of the journey and proves more of the architecture around it.
Regular reviews should use representative scenarios rather than a tour of whichever buttons were completed that week. Ask whether the right person can complete the task, whether the history explains what happened and whether an exception leaves the case recoverable. Feedback is more useful when it arrives before the team has built the same assumption into another ten screens.
A simple stage plan still helps, but every stage should produce evidence rather than only activity.
| Part of the process | Question it should answer | Useful evidence |
|---|---|---|
| Discovery | Is this the right problem and is software the right next move? | Current journey, constraints, baseline, options and a proceed or stop decision |
| Prototype | Do the proposed workflow and riskiest assumptions make sense? | Tested journeys, user feedback, integration findings and revised scope |
| First release | Can one complete path create a useful business result? | Working software, acceptance evidence, measures and known exclusions |
| Controlled rollout | Does it work with real users, data and operational pressure? | Migration checks, support feedback, error patterns and adoption evidence |
| Live operation | Can the business run, recover, maintain and improve it? | Monitoring, tested backups, ownership, update process and performance measures |
07
Testing belongs throughout delivery
Testing is not a cleaning stage performed after development is finally ready. A late test can find a defect, but it cannot cheaply repair a misunderstood workflow that shaped the entire system.
Developers can test calculations, permissions, integrations and important business rules as each slice is built. Automated checks make repeated behaviour easier to verify. Manual exploration can find awkward combinations and usability problems. Business users can confirm whether realistic cases produce the right operational result.
Security needs the same continuous treatment. Current National Cyber Security Centre guidance recommends secure design and development, controlled code and build environments, repeatable testing and a supported process for vulnerabilities and updates. A penetration test near launch may add useful assurance, but it cannot replace secure working practices through the project.
Recovery deserves testing too. If an integration fails halfway through approval, the case should not disappear between systems. If a release causes a serious problem, the team needs a rollback or safe correction route. If the database is lost, a backup only becomes evidence when somebody has restored it successfully.
08
Plan migration and organisational change before launch
The new portal cannot become useful if its data, users and responsibilities are still waiting in the old process. Migration and adoption therefore begin well before the launch date.
Profile the existing data. Decide which records will move, which will remain as a read-only archive and how duplicates, missing references and inconsistent categories will be handled. Run a rehearsal using a representative copy, then compare totals and sample important cases. A successful import is not enough if approvals or document links have moved to the wrong customer.
Map the cutover. Decide when new applications stop entering the old process, how work already in progress will finish and what would trigger a rollback. Assign the people who can make those decisions. Hope is not a deployment plan, even when it has a calendar invite.
Training should use the tasks people actually perform. Reviewers need to practise ordinary cases and exceptions. Managers need to understand queues and measures. Support staff need a route for reporting faults and distinguishing a software problem from an unclear business rule.
09
Launch to a controlled group before widening access
A controlled rollout lets the team observe the system with real users and real data without placing the whole operation on a new path at once. The GOV.UK beta guidance uses a similar principle by starting with a limited group, learning from their use and improving the service before widening access.
The commercial version may be one branch, one customer type or a small set of trained staff. Choose a group that represents the real process and contains enough variety to expose problems. Do not choose only the friendliest users and then act surprised when the rest of the business has questions.
Watch the original measures and the operational signals around them. Are customers completing applications? Where do they stop? Which validation message creates calls? Are staff maintaining a shadow spreadsheet? Are errors reaching somebody who can act on them?
Fix the problems that prevent a reliable journey before expanding the scope. New feature requests will appear immediately because people can finally see the system. Keep them separate from defects and launch blockers so enthusiasm does not turn the first release into an endless final week.
10
A live system begins a support lifecycle
Launch is a change in responsibility, not the end of the custom software development process. The application now holds real data, supports real decisions and depends on hosting, integrations, certificates, email delivery, packages and people who all change over time.
Agree who monitors availability and failures, who receives support requests and how serious incidents are escalated. Keep the software and its dependencies on supported versions. Test backups and recovery. Review user access when roles change. Plan security fixes and routine maintenance rather than waiting for a crisis to create the budget.
Use performance data and user feedback to improve the service. Current government service guidance recommends defining success from the start and using performance evidence to decide what needs attention. A private business does not need to copy government reporting, but it still benefits from knowing whether the software solves the problem it was funded to solve.
A roadmap should follow evidence from the live system. Some additions will create value. Others will recreate complexity that the first release deliberately removed. The owner of the service needs the authority to choose between them.
11
The business has work to do at every stage
A supplier cannot discover the operation alone. The business needs an accountable owner who can explain the goal, bring the right people into decisions and resolve disagreements. Staff need time to show real cases, review prototypes, prepare data and test working releases.
Decisions also need reasonable turnaround. A development team waiting two weeks for an approval can either stop or guess. Neither helps the budget. A regular review rhythm and a clear decision-maker keep uncertainty visible.
The business should challenge the supplier too. Ask what was learned, which risk was reduced, what remains unknown and why the next piece deserves to be built. Ask to see working software, test evidence, deployment arrangements and the support plan. Progress should be more than a percentage beside a task list.
Good collaboration does not mean the customer designs every database table or the developer decides every business rule. Each side contributes the knowledge it owns, and both use visible evidence to make the next decision.
12
The process ends with ownership, not dependency
A healthy custom software development process leaves the business with more than an application. It leaves a clear purpose, measured results, controlled access, usable data, source code, deployment knowledge, support arrangements and an honest record of what remains to improve.
The sequence matters, but the hand-offs matter less than the questions. Discovery proves the problem. Prototypes test uncertainty. Working slices prove behaviour. Controlled rollout proves the operation. Live support proves that the system can remain useful.
For the onboarding portal, success is not that every requested feature reached production. It is that customers can submit complete information, staff can make and explain decisions, approved data reaches the right systems and the business can operate and improve the service without relying on somebody remembering the old workaround.
That is the point of the process: commit more budget as the evidence becomes stronger, and leave every stage able to change the next decision.
Useful questions
Questions to ask during a custom software development project
- Is the technical direction clearly linked to a business goal?
- Do the people building the system understand the commercial priority?
- Are risk, cost, security and delivery trade-offs visible early enough?
- Can the current platform support the next stage of growth?
