Inherited software troubleshooting
The software broke. The developer is gone.
Your business still relies on it, but nobody knows how to fix it—or even where it runs. I help piece together what you have before deciding what needs to change.
Start with what the business can access
An old invoice, hosting account or backup can be more useful than a vague technology description. I map the application, its data and the accounts the business controls. Missing source code or access changes what is possible.
An old application is not automatically a rewrite
A certificate, runtime update or changed external service may be the immediate cause. I look for a contained repair first, then separate ongoing maintenance needs from any larger replacement decision.
Make the next handoff less mysterious
As the system becomes clearer, I document where it runs, how changes reach it and what it depends on. That knowledge should stay with the business rather than disappear with another developer.
What I look for in an unfamiliar system
- Source repositories, deployed code, hosting and database access
- Deployment steps, configuration and backup history
- Runtime versions, unsupported dependencies and recent server changes
- External services and vendor accounts the application depends on
What if the former developer controls the accounts?
The business may need to recover access through the provider or former developer first. I can help identify what is missing, but I do not bypass authentication or access systems without authorization.
What does the software do for your business?
Start there. You do not need its source code or a technical inventory just to ask for help.