Custom software and customer portals: turn a business process into a usable first release

Choose the route matching your current question

If the form of the solution remains uncertain, begin with the product-versus-custom comparison. Examine whether the work truly needs a new application or whether a focused addition is sufficient. If the task is already clear, use the scope guide to connect people, information, exceptions and the intended first result. The starting point depends on what the organisation actually needs to decide next.

For an existing proposal, take a more specific route. The cost guide helps compare the work behind amounts. The acceptance guide identifies evidence needed at delivery. In a customer portal, roles and state meaning often determine daily usefulness. An unresolved question about access or confirmation need not disappear into a large design before it can be investigated. Give it a concrete case and an accountable person to clarify it.

Investigate the problem with people doing the work

Ask users to describe a real working situation and prepare suitable examples. What arrives, which decision follows and what should somebody else be able to do afterwards? Look for points where work leaves the existing application and continues in email or a spreadsheet. This may indicate a missing capability, but can also reveal an unclear agreement or incomplete information that new software alone would not resolve.

The GOV.UK Service Manual places user needs and constraints before an implementation decision. That thinking can help a business application too: confirm the problem and main dependency before fixing the full build. Choose a proportionate discovery result of your own. A bounded trial, process description or demonstrated export may be enough to assess a focused next step without prematurely designing every detail of an eventual platform.

GOV.UK Service Manual: How the discovery phase works ↗

Compare solutions against a complete task

Use the same ordinary situation and important exception for every candidate. A screen showing enquiries is not yet a complete planning process. Investigate responsibility, missing information and how a decision is retained. Options become comparable only when you understand how the same task is finished with each and which activities remain manual outside the proposed application. The interface alone cannot establish equivalence.

A fictional service agency may already have suitable administration while struggling with customer additions. A separate portal could be examined without replacing all internal software. The initial task becomes: one customer supplies information for an open enquiry and an employee retrieves and reviews it. That is a concrete starting point for comparison, design and budgeting, rather than treating a broad request for modern software as sufficient scope.

Bound a first release that is genuinely usable

A small release is not simply fewer screens. It should support a bounded task end to end, including a necessary next step when information is missing or a dependency fails. State included behaviour and deliberate exclusions. For an exclusion, explain how the organisation continues meanwhile. A narrow build scope should not create a daily process nobody can actually perform with the tools and responsibility available.

Turn unconfirmed technical capabilities into separate investigation questions. If an existing supplier has not demonstrated the required data access, keep that uncertainty visible in planning. The team can choose more discovery, a temporary route or different scope. An initial version is stronger when it rests on confirmed assumptions rather than a broad expectation that every relevant application will eventually be made to work together somehow.

Make roles and progress understandable together

A portal needs both access boundaries and meaningful progress. Users should understand which organisation or record they are working with and which operations are allowed. States should explain what demonstrably happened, what remains pending and who acts next. A polished presentation without that relationship can leave customers dependent on telephone explanations even though the same information appears to be available online.

Investigate a refused operation and an uncertain confirmation alongside the ordinary route. Can a customer address another organisation’s record? What happens if a proposal changes after earlier approval? These belong to design of the initial task. The roles and states guides examine them separately so a simple interface does not silently remove business boundaries or conceal unresolved responsibility from the process it is supposed to support.

Prepare data loading as a reviewed step

New software often receives existing customers, enquiries and documents. Decide which selection the first task needs and who can confirm its meaning. Create field mapping, preserve source references and perform a small trial import. Examine not just whether loading succeeded but whether staff can understand relationships and use the results for the task the new application is intended to support.

The import guide covers that dataset and its substantive assessment. A complete transition between actively used systems additionally requires decisions about coexistence and where changes are written. Keep those subjects recognisably separate. A project can then define a simple loading assignment without suggesting it has already arranged the entire organisational and technical system transition. Clear boundaries make both investigation and quotations easier to understand and compare.

Compare costs and recurring work

A budget should identify the result being built and the work required to use it. Examine setup, data preparation, integration, testing, instruction and maintenance. Use real proposals and terms. A low development amount may involve more manual review, while an extensive design can contain capabilities with no demonstrated value for the initial task. Compare the whole working arrangement rather than build expenditure in isolation.

Expose usage assumptions and choose a bounded pilot to examine them. Measure how staff retrieve enquiries and how much recovery effort remains, for example. Keep freed capacity distinct from expenditure actually reduced. The goal is an explainable investment decision rather than an apparently precise payback figure resting mainly on unverified volumes, a favourable illustration or an unstated expectation about what customers and staff will do in future.

Assess delivery with recognisable cases

Prepare the important cases before a demonstration. Include a normal task, missing information, appropriate refusal and a relevant recovery path. An accountable person should explain why the outcome is useful to the organisation. Trial material helps the developer understand behaviour that matters and helps the customer distinguish a discrepancy from a new request arising while people review the initial version.

Record findings against a recognisable release. Describe outstanding items, consequences and any temporary working method. A successful trial supports the cases examined rather than every future possibility. Keeping the meaning of evidence clear makes acceptance useful for the first introduction and provides a starting point for controlled further development. It also helps a later participant understand which decisions were deliberate and which matters remain unresolved.

Make the next development step transferable

At new delivery, arrange availability of source, accounts, records and relevant instructions. Agree who operates the application and how requests are assessed. Ask an authorised second person to perform a bounded task with the available information. This reveals which explanations actually matter for continuing use or making a focused modification, instead of assuming transferability from the number of files delivered.

Use this cluster’s preparation tool to collect the task, user, data, boundaries and acceptance criteria for your own project. Unknown details remain open questions. Its downloadable draft supports a conversation about a suitable initial assignment. Retain reasons behind decisions too, so future extension can build on an understandable process instead of repeatedly reconstructing the assumptions and discussions that shaped the first release.

Explore each decision

Turn the explanation into a project decision

Record your assumptions, unknowns and acceptance checks in the matching tool. Use the service guides to discuss delivery and scope.

• Custom software development ↗
• Customer portal development ↗

Questions about this topic