An import has stopped working, a form returns an error or you need to change a single feature. If the task has clear boundaries and a result we can check, we agree the scope of the repair. A separate assessment of the whole application is not automatically necessary.
Your business needs the system, but development has stalled or each fix causes more problems. We review the available materials and how the application works so we can plan the first stage and ongoing work.
Your hosting provider requires a different PHP version, or dependencies are blocking an upgrade. We check application compatibility, identify the changes needed and establish which workflows must be tested before switching environments.
In an application built by another provider, we repaired the import of large CSV files and improved the interface and mobile usability. Only after learning how the client worked did we rebuild the book catalogue in Laravel. Fixing the immediate problem and rebuilding the application were separate stages.
After taking over the project, we found that the application's condition called for replacing the old code. We rebuilt the service from scratch in Laravel, retaining and developing the owner's visual direction. The work also covered listing data, search, reviews, messaging and moderation.
We start by establishing how your business uses the system and which function needs to be restored or developed. We check where the code is held, whether it matches the running version and who controls the repository, hosting and connected services. We record missing materials as limitations on further work.
Within the agreed scope, we examine the framework and libraries, configuration, database, integrations and background jobs. We check whether the project can run in a test environment and whether we can reproduce the key user workflows. This helps us decide which changes to make first.
For example, an import fix might have been applied directly to the server without being committed to the repository. In that situation, checking out the repository alone will not reproduce the current behaviour. Before further development, we compare the available versions and agree which one will be the basis for testing and deployment.
Our guide to changing the developer of an existing application explains how to organise the handover in more detail.
For a defined repair, we deliver the fix in the agreed environment, the results of checking it and the information needed for deployment or further work. We set the acceptance criteria before starting.
If an assessment is needed first, its agreed deliverables may include:
An application's age alone does not determine whether to replace it. We base that decision on specific constraints in the code, data and environment. Our article on modernising an existing system or building from scratch compares these options.
A free call of up to 20 minutes helps us establish the problem, the goal and the materials needed for the next step. It does not include code analysis or a technical report.
If the available information is not enough to define the work reliably, we propose a separate paid assessment. Before it starts, we confirm the scope, deliverables, deadline and cost. Pricing depends on the condition of the code, the completeness of the materials, integrations and the importance of the affected workflow to your business.
You can also use the assessment materials with another provider, subject to confidentiality. If we subsequently carry out the work arising from the assessment, the fee you have paid for it counts towards the total project cost.
We check the support status of your PHP version and whether the framework and libraries are compatible with the target version. Before making the change, we agree how to back up, test and return to the previous release. Acceptance checks should cover important workflows, integrations and background jobs; opening the homepage alone does not confirm that the whole application works.
If your enquiry concerns a critical PHP vulnerability, the urgent environment patch needs to be arranged with the administrator or hosting provider. Rewriting the application does not replace that patch. Our guide to updating PHP and assessing an older application explains the distinction. This service does not include round-the-clock incident response.
A broader security audit, data migration and subsequent application maintenance each require their own agreed scope. They are not automatically included in taking over a project.
Share the application's address, describe the problem and tell us the first result you want. If you know the technology or have an important deadline, include it. We will respond with questions or a proposed next step.
Do not send passwords, API keys, database copies or customer data. If access is needed for the work, we will agree how to transfer it once the scope is settled.
Prefer another way to get in touch? Email or call us.
