What it usually looks like
- •Form submissions stopped arriving and nobody knows when that started,
- •The catalogue or price list is updated by hand because the import broke and there is nobody to fix it,
- •The layout falls apart on phones while looking fine on a desktop,
- •The site runs on an engine version that stopped receiving updates, and the host is already sending warnings,
- •The sources exist, but nobody can say whether that is the code currently running on the server.
What all five have in common is that the problem is not the task, it is that nobody can pick it up. The code is written and it runs, but the person who held it in their head is gone. And the first contractor you approach offers to start over — because that is easier for them than understanding someone else’s work.
We start with a review, not an edit
Before changing anything you have to know what is there. This is not a formality: an edit in inherited code is dangerous in exact proportion to how little you know about what depends on it. So the first step is to read the project and draw a line.
What we establish
- •Where everything lives: domain, DNS, hosting, mail, code, database — and whose name it is all in,
- •Whether the code in the sources matches what is actually running on the server,
- •What depends on the parts we will have to touch, so a fix does not break its neighbour,
- •Whether backups exist and actually restore, rather than merely being created,
- •Which tasks on your list can be solved inside the current code and which are stuck in the architecture.
What is cheap to fix and what is not
The cheapest things to fix are those broken in one place: a form that stopped sending mail, an import that tripped over a changed format, a layout that was never built for a narrow screen. Such tasks do not require touching anything else, and they are visible immediately.
The most expensive is what is broken the same way across the whole project: when one value is duplicated in ten places, when an edit in one section unpredictably changes another, when the engine cannot be updated because the theme was edited on top of its own files. Here the honest answer is sometimes indeed “replace it”, and we say so up front rather than after three months of going in circles.
What you get
- •Edits in your code, not on our platform that you would later need access to,
- •Access to everything we touched, and a change history showing who changed what and when,
- •A review: what is worth developing further and what is cheaper to replace, pointing at specific places,
- •The option to leave at any moment without buying anything back.
What we do not do
- •We do not name a price or a deadline before reading the code: until then any number is a guess,
- •We do not propose rewriting a project where the task is solved by an edit,
- •We do not take on a project with access to neither the code nor the server: blind edits are not possible,
- •We do not keep keys to your domain, hosting or repository.
What we work with
Sites on PHP and off-the-shelf engines, applications on Next.js and React, back ends in Python, PostgreSQL and MySQL databases, API integrations and controller firmware in C. These are the stacks our own products run on — from AI servers to form and ad protection — so in inherited code on them we are finding our way around, not learning the stack at your expense.
Frequently asked questions
The developer is gone and we have no access. Can you still help?
This is the usual situation and it is solvable while the site is still running: the domain and hosting are registered to the company or to someone reachable, so access is recovered through them rather than through the missing contractor. We start by finding out where everything actually lives — domain, DNS, hosting, mail, code, database. If part of it turns out to be registered under someone else’s name, we say so immediately: that is the first thing to get back, and editing anything before that is pointless.
Will you also tell us it all has to be rewritten?
Only where that is true, and with the reasoning. A rewrite is the most convenient answer for a contractor: it removes the need to understand someone else’s code and turns a small fix into a new project. So we read what exists first and split the work in two: what can be fixed inside the current code, and what is genuinely stuck in the architecture. The second part is usually smaller than it sounds at the first meeting.
What if the code really is bad?
Then we show you where, on specific lines, rather than talking about outdated technology in general. Bad code is not a reason to replace everything: more often one component needs replacing — the one that makes edits everywhere else risky. What to replace and what to keep is your decision, made with our review in hand rather than under deadline pressure.
What happens if a fix breaks something next to it?
On inherited code this is the main risk, and it is handled by how the work is done, not by promises. Before an edit we find everything that depends on the place being changed and fix the whole chain in one pass. Changes go in one at a time and each can be reverted on its own. If the project had no change history and no backups, we set both up before the first edit — that is cheaper than rebuilding a site from memory.
Do the code and the access stay with us?
Yes, and it is not a separate line item. Edits are made in your repository or in your code on your server, the credentials are yours, and the full change history stays with you. You can leave at any moment without buying anything back or asking anyone’s permission — precisely because the opposite situation is what brought you to this page.
Do you work one-off or ongoing?
Both. One-off when the task has an end: fix the forms, update the catalogue, make the layout work on phones. Ongoing when the site is alive and changing and someone has to keep it in their head. Starting one-off is sensible: it shows the state of the project to both sides, and the conversation about ongoing work then happens with numbers instead of impressions.