You have an application that is partly built. The original developer may be unavailable, progress may have stopped or the remaining work may be unclear.
Before another team promises a completion date, it needs to establish what exists and what can actually be used.
A finished-looking interface does not prove that the underlying workflow works. Equally, an untidy codebase or missing documentation does not establish that the entire application needs replacing.
The first task is to collect enough evidence to decide what should happen next.
Replace “Nearly Finished” With Observable Facts
A project described as “90% complete” may still have significant work outstanding.
That percentage might refer to approved screens, completed tasks or a developer’s personal estimate. Those measures do not necessarily describe readiness for users.
Start with questions such as:
A useful assessment turns general progress claims into a record of confirmed functionality, missing work and unresolved questions.
Our application technical assessment service explains how an initial review can be scoped.
1. Establish What the First Release Needs to Do
Before judging what remains, agree on the intended first release.
Otherwise, the incoming developer may assess the application against a different scope from the one your business expects.
Identify:
- The first users.
- The task they need to complete.
- Essential staff workflows.
- Required integrations.
- Access rules.
- Conditions that would prevent release.
Separate essential requirements from later improvements.
For a new product, our MVP development approach explains how to define a focused first release.
2. Check Whether the Available Code Can Run
Ask the incoming developer to establish whether the application can be set up in an authorised environment.
This can reveal missing dependencies, configuration problems or differences between the repository and the version being demonstrated.
Record:
- Whether setup was completed.
- Which instructions were used.
- What prevented progress.
- Which services or permissions were unavailable.
- Whether the application’s main parts could be inspected.
A failed setup is a blocker to investigate. It does not, by itself, prove that the application must be rebuilt.
Access and environment preparation should follow an agreed process. Our application handover checklist covers the information to collect.
3. Test a Complete User Journey
Do not assess the application only by opening individual screens.
Choose an important workflow and follow it from beginning to end.
For a customer request feature, that could mean:
Then check relevant exceptions:
- Required information is missing.
- The customer submits twice.
- A user attempts to access someone else’s record.
- A connected service fails.
- Staff reject the request.
- The customer returns later.
This helps distinguish a working feature from a collection of interfaces.
For account-based workflows, see our customer portal development service.
4. Identify Demonstration Data and Temporary Behaviour
Early builds may contain sample records, simulated responses or temporary workarounds.
Those can be useful during development, but their status needs to be visible.
Ask:
A demonstration is not inherently a problem. Treating it as completed production functionality can lead to an inaccurate continuation estimate.
5. Review Data and Permissions
An application may appear to work while allowing the wrong users to view or change information.
The review should examine relevant access rules and data behaviour.
Questions include:
Sensitive data and production environments need appropriate handling throughout the assessment.
Specialist security testing or compliance evaluation requires its own defined scope.
6. Check Integration Readiness
A feature may depend on another service that is not fully connected.
For each important integration, establish:
| Check | What to record |
|---|---|
| Access | Whether authorised credentials and accounts are available |
| Documentation | Which provider instructions apply |
| Functionality | What has been implemented and observed |
| Data | Whether requests and responses match requirements |
| Failure handling | What happens when the connection is unavailable |
| Testing | Which scenarios have been checked |
| Dependencies | Approvals, subscriptions or work still required |
For example, a checkout interface may exist while payment confirmation and order updates remain incomplete.
Our API development and integration service covers reviewing and building these connections.
7. Separate Missing Work From Broken Work
These categories need different planning.
| Finding | Meaning | Possible next step |
|---|---|---|
| Missing feature | Required behaviour has not been built | Define and estimate implementation |
| Defect | Existing behaviour fails an agreed requirement | Investigate and scope a correction |
| Missing dependency | Access, content or another service is unavailable | Assign an owner to resolve it |
| Unclear requirement | Expected behaviour has not been decided | Obtain a business decision |
| Unverified behaviour | Available evidence is insufficient | Define a test or investigation |
| Improvement request | Additional functionality is being proposed | Review separately from completion scope |
This prevents every unresolved item from becoming a general claim that “development is incomplete.”
It also helps your business identify decisions and inputs it must provide.
8. Review Tests and Release Readiness
A working demonstration is different from an application ready to release.
Review the available evidence for:
Missing tests do not automatically justify replacing the application. They may identify checks that need adding before changes or release.
Ask which behaviours have been verified, where they were tested and what remains untested.
9. Ask What Can Be Preserved
A takeover should identify useful work as well as problems.
Examples may include:
The incoming team should explain how proposed changes relate to the actual requirement.
If replacement is recommended, ask which constraints make repair or staged improvement unsuitable and what transition work replacement would introduce.
Our software project takeover page explains how we approach continuation without assuming a rebuild.
10. Define the Smallest Useful Next Stage
Once the main findings are understood, choose a stage that resolves an important uncertainty or delivers a reviewable result.
That might be:
- Establishing a reproducible build.
- Completing one core workflow.
- Repairing a failing integration.
- Adding essential permission checks.
- Preparing a release candidate for acceptance testing.
The stage should identify:
A smaller stage is useful when it produces evidence for the next decision.
An Example Readiness Record
The table below illustrates how findings could be recorded. It is not a report from a client project.
| Area | Observation | Next action |
|---|---|---|
| Sign-in | Tested successfully with an authorised test account | Check remaining account scenarios |
| Customer submission | Saves a record in the test environment | Test validation and repeat submissions |
| Staff review | Interface exists; update behaviour not verified | Investigate the connected service |
| Notifications | Simulated response used | Scope provider integration |
| Deployment | Instructions incomplete | Reproduce a test build and document steps |
This record gives the business more useful information than a single completion percentage.
What the Initial Assessment Should Deliver
Before commissioning the assessment, agree on its outputs.
A decision-ready report can include:
If an important question cannot be answered, the report should say what would be needed to resolve it. See how to Evaluate the assessment report before approving continuation work.
Read our guide to writing a developer brief for structuring the resulting implementation scope.
Budget for Continuation and Ongoing Ownership
Completing the immediate work is only part of taking responsibility for an application.
Account for onboarding, testing, documentation and release preparation where required.
Also decide who will handle future problems, updates and development requests.
Our developer cost guide explains how to compare complete engagement costs. Our application maintenance service covers ongoing support arrangements.
Discuss Your Unfinished Application
DOT IT Services helps businesses review existing software and plan a practical continuation stage. Tell us what the application should do, what currently works and which access or documentation is available.
We will discuss whether an assessment is needed before implementation can be scoped.
Written by DOT IT Services.