Practical software notes · Industrial Hypertext
What to do when your original software developer is gone
If the software still matters to the business, start by recovering access and understanding how it runs. That gives the next developer a sound basis for support and new features.
Find out what the business controls
Confirm who holds the source code, hosting account, database access and domain registration. Find the backups and any deployment instructions, and identify external services such as payment, email or accounting integrations.
Some accounts may still belong to the previous developer or agency. Record the gaps and arrange an orderly handover where possible. The one-page handover worksheet gives you a place to capture those details.
Identify the workflow that matters most
Talk to the staff who use the system. Ask what it handles, which tasks would be disrupted by a failure and what manual workarounds have developed around it.
A quoting rule, monthly report or integration may be more important than the most visible screen. Record examples of expected behaviour so a new developer can verify changes against the way the business works.
Check your starting position
These questions help make the first discussion useful:
- Can your business access the code, hosting and database?
- Do you have a backup and know how it would be restored?
- Can someone explain how a change reaches production?
- Do you know which workflow or integration must keep working?
- Have you identified the first fix or feature you need?
Missing answers are useful findings. They help determine whether the first scope should recover access, document the setup or address a specific application issue.
Bring in a developer with a contained first scope
A new developer should review the production setup and important dependencies before making changes. The first engagement can combine that review with one fix or overdue feature and the checks needed around it.
Read how to take over a business-critical system for a fuller handover approach. You can also discuss takeover and ongoing support directly.
Make a longer-term decision from evidence
Once the current system is understood, assess which parts to retain, improve or replace. Existing business rules, integrations and data all affect that decision.
Staged modernisation can keep useful work moving while larger changes are planned. If the main issue is a manual workflow around the system, review the process as well as the code.
Need help applying this to your system?
Tell us what you want built or improved, the system involved and what must keep working. We can help scope a practical first step.
Discuss your project