Webvelopment
Connected solutions

Technical discovery before a costly commitment

Before you commit to a build, we can investigate the questions that could change it: what the existing code allows, how data moves between systems and which operating rules the software needs to respect.

Let’s talk

Reduce the uncertainty that changes estimates

Two colleagues planning content together on a whiteboard.
Illustrative photography · Walls.io / Unsplash

A software brief can sound clear until someone asks how a record gets corrected, which system holds the latest information or what happens when an integration fails. Those answers can change the work considerably. Asking for a fixed build price before understanding them can hide uncertainty inside an apparently precise number.

We use technical discovery to investigate those questions before you commit to the larger project. It can help with a custom application, a difficult integration, a legacy handover or a website migration with substantial dependencies. Start with the decision you need to make: improve the current system, replace part of it or invest in a new build.

Ask questions that change the plan

Begin with the task and the people doing it. Who enters the information? Who checks it? Can they correct a mistake themselves, and does that correction need to reach another system? These questions help us find the assumptions that could change the scope, schedule or operating cost.

Depending on the problem, we can:

  • Talk to the people doing the work and map the current workflow, including exceptions.
  • Review authorised source code, infrastructure or documentation for the relevant part of the system.
  • Map where data is held and who controls each system.
  • Check an integration using approved access.
  • Build a prototype or run a small technical experiment to answer a specific question.
  • Agree priorities for a first release, with assumptions and checks for whether it does the required job.

Bring the current brief, relevant documentation and an example of the task that is difficult today. If access is needed, we agree what can be inspected and how data will be handled. Access to an existing system does not authorise production changes; experiments need an agreed environment and clear limits.

Make the outcome usable

You should be able to use the findings to choose your next step. That means seeing what we checked, what the evidence supports and which questions remain open. A requirement needed for daily work should be distinguishable from a preference, and a dependency on a supplier should be easy to spot.

Where an estimate is appropriate, it should explain what work it includes and which assumptions could change it. The conclusion might be to improve the existing platform, use an off-the-shelf tool or proceed with a custom build. Each is a valid outcome when the findings support it.

Move into delivery with fewer surprises

Once the main uncertainty is understood, you can choose a small implementation, plan stages of work or defer the project. Custom software development and API integrations can then start with a clearer idea of what the first piece of delivery needs to prove.

Bring us the uncertain part of your project. Tell us what you are trying to decide, what you already know and which unanswered question is holding things up.

Make an uncertainty testable

For example, suppose staff correct a customer’s details in one application, but a proposed integration needs to pass those corrections to a second system. Before estimating the integration, we need to understand what happens to the corrected record.

With approved documentation and access, an investigation could trace one example record: how the two systems identify it, which fields may change and what should happen if the second system rejects the correction. A small test in the agreed environment could then examine the uncertain step. The result would show what was observed, what still needs checking and whether the proposed approach needs to change.

This is an illustrative investigation, not a completed feasibility check. Its value is the focused question: can a correction reach the right record, with a workable way to handle a failure?

Make the investigation produce a choice

Before starting, agree which finding would lead to which next step. In the correction example, the evidence might support a direct integration, reveal a need for staff to review failed updates or leave an essential question for the supplier. Those outcomes imply different amounts of work.

We should also be clear about what the investigation cannot establish with the available access. If a key behaviour cannot be checked, it stays an open question in the proposal rather than quietly becoming an assumed requirement.

Explore the delivery disciplines · Discuss this business change.

Technical discovery questions

A few useful answers before you decide.

What should the discovery statement of work contain?
Name the decision you need to make, the questions to investigate and the work included. List the available inputs, who can provide authorised access and what you will receive, such as findings, a prototype or an estimate. State what will not be inspected. A targeted investigation into one integration does not establish the condition of the entire application.
Can discovery examine an existing supplier's work?
Yes, through access and material your business is authorised to provide. Clarify ownership and restrictions first. We may need setup instructions or context from the current operator to understand an unfamiliar system. Missing information remains a limitation of the findings; it does not give permission to bypass a supplier, alter production or copy sensitive records.
What makes a prototype worth producing?
It should answer a question that affects the plan. For a user task, that could mean checking whether staff can spot and correct an error before submitting it. Agree what reviewers will try and what you need to learn. A polished screen alone does not establish production behaviour or a working integration, and a discovery prototype is not a finished product.
Can the conclusion be to retain the existing system?
Yes. Configuration changes or a targeted improvement may address the problem. Staged replacement or deferral may also make sense. We should be able to explain why a rebuild is needed, using what the investigation found, before asking you to commit to one.
How does discovery support an estimate?
It helps separate understood work from work that still depends on an answer. For example, an integration estimate may depend on whether a supplier supports the required record correction. The estimate should name that dependency and any exclusions. Discovery can improve its basis, but a short investigation will not uncover every historical data problem or future request.
Who should receive the findings?
Share them with the people deciding whether to fund the work and those who will build, operate or use the system. They need enough context to understand the findings and see who needs to answer any remaining questions. Professional legal, product and specialist decisions still belong with the appropriate responsible reviewers.

Plan the scope and estimate

Digital Project Discovery & Technical Scoping Estimator. These tools separate known labour from work and supplier costs that need a custom quote.

Keep exploring

Keep the right things connected.

Development

Custom Software Development

Plan custom software around the tasks your staff and customers need to complete, with clear rules, permissions, integrations and handover.

Connected solutions

Digital transformation, one workable process at a time

Replace disconnected manual work with a prioritised digital roadmap, tested workflows and software that fits the way your business operates.

Let’s move things forward

Start a conversation

Tell us what you are working towards. We’ll help you find a practical next step.

Let’s talk