We quote the rest of someone else's project after reviewing the code and the access, because only then is it clear how much work is left. The review's own date comes in its quote, and before we change a line of code we go through a list where the order matters.
What we check before quoting
| What | Why |
|---|---|
| Passwords, keys and tokens | we rotate every one the previous vendor may have known; GitHub names revoking a leaked secret as the first step, since nobody can remove it from other people's clones |
| Domain, server and external services | moved to your company, not to us; a .pl domain is controlled by its registrant, so one registered to the vendor needs the vendor's part |
| A clean install | we build and run the project on a fresh machine using only the repository, without the previous team's knowledge |
| Code and dependencies | structure, tests, outdated and vulnerable libraries, and whether they can be updated safely |
| Backup and monitoring | we test the data backup by restoring it and switch monitoring on before the first change, to see the starting point |
The report and the decision
The review report says what to keep, fix or rewrite, with the reasons. We rewrite only modules that break with every change or stand on a library nobody maintains, and finish the rest in stages on a test version. The quote gives the stages, a date for each and the risks named plainly, and what to rewrite is always your call. The code we add is yours once it is accepted and paid for. If you need only a diagnosis, start with a code audit.
The review, the plan and the final documentation are on our project takeover page.
Was this post helpful?
