Architecture
Whether design decisions are justified, where the bottlenecks sit and how the shop copes if visitor numbers triple on Black Friday.
Judgement rests on stated criteria, never on personal preference: will it scale, can it be looked after without pain, is it safe, and would it survive one person leaving?
Whether design decisions are justified, where the bottlenecks sit and how the shop copes if visitor numbers triple on Black Friday.
Readability, automated test coverage, duplicated logic, the way changes reach production, and whether anything has been written down for newcomers.
Stale or unmaintained packages, components carrying published vulnerabilities, and PHP, Node.js or framework versions that are out of support.
Links to the ERP, KSeF, payment gateways and carriers. We check the behaviour when an external API returns an error or goes silent.
The location of servers and customer records, and whether the configuration is in line with GDPR and the processing agreements you have signed.
Is there anyone besides the original author able to maintain it, or is everything locked in one developer's memory or a repository under a private account?
Risks and recommendations described so that directors without a technical background can use them in decisions.
Duration depends on the size of the system and is agreed before we start. Our access to the repository and environments is read-only.
Acquisition, change of contractor or risk assessment. The purpose tells us which areas deserve the closest look and how detailed the report gets.
Code repository, documentation, hosting console, logs. We also talk to the team on Teams, because some knowledge never made it into a file.
Each criterion is scored, and every finding is noted alongside what it means for the business.
A write-up ordering risks from most to least severe with an estimated repair bill, presented in an online meeting.
Messy code is rarely the worst discovery. Reliance on a single developer usually is. Inelegant software can keep working for years. Yet when just one programmer grasps how it works and nothing is written down, the business is effectively held hostage. We score this exposure on its own, apart from code quality.
Yes, that is one of the usual reasons for a review. You get an honest account of what was handed over, its condition and the price of taking it on. With the report in hand you can bargain on evidence with both the outgoing and the incoming contractor.
Yes. In a transaction we focus on what affects valuation: the technical side of code ownership and open source licences (the legal view stays with your lawyer), technical debt, reliance on key people and running costs after completion. We deliver the report to a deadline agreed with your transaction adviser.
The goal is to describe state and exposure, not to find someone to blame, and no individual gets rated. Teams frequently gain from it, as arguments they have pushed for ages are at last backed by an outsider.
Then the report says exactly that, with justification and costings for both paths: gradual repair or a rewrite. You make the call, ideally on numbers rather than instinct.
Tell us about the software and the reason behind the review. The report you get back lists risks starting with the most serious.
Your enquiry has reached us
You will hear back within one working day, and if you have reported an outage that is holding up work, it goes to the front of the queue.
No match for that name. Try a different spelling or pick a bigger town nearby - all our support is delivered online, so your choice has no effect on the service.