Start with evidence you can reproduce
A codebase assessment should answer whether a new team can operate and change the product safely. A tidy repository is useful evidence, but it does not establish ownership of the production accounts, recoverability of the database or understanding of the business rules. Ask for a controlled walkthrough from a user action to its stored result. Record what was observed, what was reported and what remains inaccessible.
Trace one business-critical journey
For a fictional booking product, follow a booking from submission through payment confirmation to cancellation. Check duplicate callbacks, permission checks, failed notifications and reconciliation. Then build the application from a clean checkout, deploy to an isolated environment and restore a sanitized backup. A successful demo on a departing developer’s laptop does not prove a new operator can recover the service.
Keep an evidence ledger for the assessment
For every finding, record the affected workflow, the observed behaviour, the source of the observation and the next check. Distinguish a failed test from a claim made in an interview and from a component you could not access. For the booking product, “email is unreliable” is too vague. Record which notification failed, whether the booking remained stored and whether anyone could see or retry the failed delivery. That finding connects a technical issue to customer impact without pretending to know its frequency from a single example.
Investigate the first change before promising a roadmap
Choose a small correction with visible value and limited consequences. Trace its code, data, permissions and external calls, then identify the test that would catch a regression. Determine how to deploy it to a safe environment and how to reverse it without losing new records. If the team cannot answer those questions, restoring release capability may be the first deliverable. This is more informative than estimating a large feature backlog against an unverified development setup. Keep the original operator involved where they can explain undocumented behaviour, while recording the explanation for future use.
Agree what access limitations mean
An inaccessible production account or missing backup is a finding, not evidence that the corresponding system is healthy or broken. State the limitation and the decision it prevents. Request only the access needed for the assessment, through authorised accounts with an agreed lifetime. Use protected or synthetic data for demonstrations and avoid copying customer records into the report. Before accepting a takeover, review unresolved risks with the business owner and identify who will obtain the missing evidence. The handover decision should include operating responsibility from the first day, not just permission to start editing code.
Separate urgent risks from preferences
Missing account ownership, an untested recovery path and exploitable access controls deserve different treatment from inconsistent naming. Compare a short stabilization engagement with a broader modernization effort. Stabilization preserves continuity and reveals facts quickly; modernization can remove structural constraints but adds migration work. Do not label unfamiliar technology as broken merely because the incoming team prefers another stack.
Turn the assessment into a handover decision
Ask Orvun Labs to connect software-rescue findings to a first safe delivery, with evidence and explicit exclusions. The useful output is a risk register, access map and verified runbook, not a single unexplained quality score.
- Who owns the repository, domain, hosting, billing and recovery accounts?
- Can a fresh machine build, deploy and restore without personal credentials?
- Which dependencies or business rules have no current maintainer?
- What small change demonstrates the new team can test, release and reverse a change?