Maintenance, upgrades and recovery for web, mobile, SaaS and e-commerce applications built by others

Yes. Adopting applications built by freelancers, agencies and in-house developers who have since moved on is most of what this service does. The original developer’s cooperation is usually not needed. Access to code, server and database is enough. Where the code itself is missing, the live server usually holds a deployable working copy, and the audit starts from that copy, whatever state the files are in.

Yes. The audit first compares what exists with the original proposal, because the two often differ by whole modules that were promised but never built. You receive a statement of which parts are usable, which need rework and which are missing, with a re-scoped plan to reach production. Sometimes rebuilding a module beats repairing it. That comparison is shown to you.

Yes. The verdict arrives with the audit. If the architecture cannot support what the business now needs, or every change breaks something else, continued maintenance can cost more over time than a planned rebuild. The audit lays out three options, which are to maintain, to rewrite the worst modules or to rebuild, and weighs the trade-offs of each.

It depends on the application. Typically we need the source code or a copy from the live server, hosting and database logins, domain control and, for a mobile app, developer store accounts. Payment, SMS and WhatsApp keys are needed too. From your team we need one person authorised to grant access, a list of the problems that hurt most and someone to confirm each fix works. Missing accounts, and any still held by a previous vendor, are recovered and reissued in your name during the first stage. Nobody depends on the old vendor’s goodwill.

Work starts from whatever you can legally access, which is usually the running application on its own server and the live database behind it. The server usually holds deployable code. An inventory is prepared of every account, key and asset that should be in your name, so a handover request to the previous vendor can name each one specifically. If something cannot be recovered, you are told what has to be rebuilt, in writing, before you commit to any cost, so the decision stays yours.

In two stages. Nobody can price maintenance before seeing the code. The audit is priced on the size and condition of the application: modules, screens, stack, integrations, and whether the code and environment exist or must be recovered. Work after the audit is priced against the backlog you approve, or as reserved monthly capacity under a retainer, with scope written before anything starts. Any figure is confirmed after scoping.

It depends on what the audit measures. Those factors are the amount of code and access that exists, the size of the application, and how far the framework and libraries have fallen behind. Others include whether a staging environment can be built, which payment, SMS or courier integrations must be re-tested, and whether the database or server has to move. Emergency fixes need access and a repro case. Stabilisation follows the schedule agreed afterwards.

Yes, under a support arrangement agreed in writing. Severity levels, the channel for raising an issue and the working hours covered are all defined, so an outage and a cosmetic glitch never share one queue. We promise only what can be staffed. A narrower SLA that is always met is preferred over round-the-clock cover that nobody can sustain through nights, holiday weeks and staff leave. Without a retainer, urgent work waits for capacity.

Yes, with care. Both happen on a copy first. Upgrades go in steps rather than one jump, and regression tests cover login, order placement, checkout, billing and the reports management relies on. A server move or database migration starts with a trial run on staging, where record counts and key reports are compared against the existing system. The switch-over happens in a low-traffic window. The old environment stays intact until you confirm the new one behaves, and every release keeps a documented rollback path that has been rehearsed on staging.

An NDA is signed before the audit begins. Access is granted through named accounts that you own and can revoke at any time, never through shared logins passed around in chat. Credentials handed over during the takeover are rotated once the handover is complete, and masked or limited data is used wherever the task allows. Production data stays on your infrastructure. The handover pack lists who can reach what.

Yes. Code lives in a repository under your organisation. Servers and domains are registered in your name, and mobile apps are published from your own Google Play and App Store developer accounts. Where assets are inherited under someone else’s account, moving them into your name is part of the takeover, and the old owner is then removed. Another team can step in at any point. No permission from us is needed.

Yes to both. Office staff get short walkthroughs of the admin screens and the support process, so they know what to log and who answers. A developer joining or already on your side gets a handover covering the architecture, environment setup, deployment process and known weak points. We can also act as a second pair of hands while your own engineer gradually takes over the application, module by module. Nobody is left alone with it.

Sometimes. The audit says which case you are in. Switching makes sense if the software does something standard, such as accounting, basic CRM or plain invoicing, and a ready-made tool now covers it properly. It rarely makes sense once the software holds years of transaction history, connects to processes an off-the-shelf tool cannot replicate, or follows a workflow unique to you. Migration and retraining usually cost more. Repair is never assumed to be right.