Custom-built website support
The developer vanished, there's no documentation, nobody dares touch it. We read the code and take the project on.
What's included
- Inherited code audit
- Documentation rebuilt
- Git and repeatable deploys
- Runtime and dependency upgrades
- Secrets moved out of code
- Backups and monitoring
- Ongoing development work
A custom-built system is always a story about one specific person. Someone wrote software that fit the business perfectly, it ran beautifully for years, and then they left: changed jobs, moved away, fell out with management, stopped answering the phone. What remains is code nobody has read, no documentation, and an unwritten rule that says don't touch it. Meanwhile the business depends on that system every single day.
The trouble is that not touching it isn't a strategy. Sooner or later the host retires the old language runtime, a certificate expires, a new integration becomes necessary, or the law changes. Then you have to understand the system urgently, in a panic, and expensively. Far better to understand it calmly and in pieces, ahead of time — which is what supporting a bespoke project actually means.
How we work
- Code and infrastructure audit. The mandatory first step. We read the code, examine the database schema, check versions and dependencies, and find where keys and passwords live. The output is a clear picture: what's inside, where it's fragile, and what to fix first.
- Backups before anything else. Before changing a line, we set up code and database backups with restore testing. For bespoke software this is critical — there is no second copy of this system anywhere in the world.
- Git and predictable deploys. We create a repository if there wasn't one. Changes stop being uploaded to production over FTP in the moment, and rolling back becomes a single command.
- Urgent security hygiene. Credentials and keys move out of the codebase, obvious holes get closed, and the runtime and dependencies move to supported versions.
- Documentation as we go. We write a short description: how to run it locally, how it deploys, where things live. Not a novel — one page that lets the next engineer function.
- Maintenance and development. After that it's the normal routine: monitoring, backups, and your requests handled within a monthly allowance of hours.
What you get
Most of all, an end to depending on one person. The project stops being a black box: there's a written description, a repository, and people who understand it. Disaster recovery stops being an act of faith in a backup nobody has ever tested.
Beyond that, you regain the ability to develop the system instead of merely fearing it. New integrations become ordinary work. The audit can also be bought on its own, without a retainer — if you just need to understand what you've inherited, start with a website audit. General maintenance terms are on the technical support page.
Timeline
This is a deep code review rather than the one-day website audit — reading someone else's system takes longer than running a site through a checklist. It takes anywhere from three days to two weeks depending on how much code there is and how readable it turns out to be. Only afterwards can we quote maintenance honestly — anything earlier is guesswork. Urgent security work follows immediately, usually inside a week. Then the project settles into a normal monthly rhythm.
A typical scenario
Picture an internal accounting system written by a former employee eight years ago. It works, but it runs on a language version the host has announced it is retiring. The sensible sequence is an audit and a full snapshot first, then standing up an exact replica environment, then upgrading the code against the new runtime in pieces, walking the critical paths after each step. Hardcoded database credentials get cleaned out along the way. Production moves last, once everything has already been proven on the copy.