When a previous developer has disappeared, the codebase is unstable or users no longer trust the system, the first step should be a technical rescue audit rather than another open-ended rebuild.
The final scope is shaped around your systems, users, data, risk profile and business outcome rather than a fixed feature package.
A rescue audit separates working business logic and valuable data from the parts creating risk. This prevents the organisation from discarding usable investment or rebuilding the same problems in a new codebase.
New functionality should wait until critical deployment, security, data and reliability issues are understood. Once the platform is stable, the roadmap can move from recovery into modernisation and improvement.
Yes, provided the organisation can supply lawful access to the source code, database, hosting and relevant credentials. The first step is an audit to determine what can be supported safely.
Not necessarily. Many projects can be stabilised in phases. A rescue audit should identify which components are usable, which need refactoring and which genuinely require replacement.
Source-code access, hosting details, database backups, deployment information, known incidents, user pain points and any architecture or vendor documentation are the most useful starting materials.
We will help define a practical first step, the integration boundaries and the delivery approach.
Read our rescue approach