Architecture and load
Whether the design choices have reasons behind them, where the bottlenecks sit, what happens when order volume triples during a sales push or the seasonal reductions.
Software that has been running for six years ends up resembling a house extended three times without drawings: it stands up, yet nobody knows any more which wall carries what. We lift the bonnet on an application we did not write, with read-only access, and answer three plain questions: will it hold the load that is coming, could another team take it over, what would putting it back in order cost? Example: a regional haulier whose round-planning tool was built by a contractor who can no longer be reached.
We judge against criteria stated in advance, not against personal taste: behaviour under load, ease of upkeep, security, survival when one person leaves.
Whether the design choices have reasons behind them, where the bottlenecks sit, what happens when order volume triples during a sales push or the seasonal reductions.
Readability, automated test coverage, duplicated blocks, the path a fix travels before reaching production, whether documentation exists that a newcomer could actually use.
Abandoned libraries, components carrying published vulnerabilities, versions of PHP, Node.js or a framework that the publisher no longer supports.
Links to Sage, Cegid or Pennylane, the electronic invoicing platform, Stripe or PayPlug gateways, Colissimo or Chronopost tracking. Mostly we watch what happens when the remote interface returns an error or stops answering.
Where the servers run, where customer files sit, what the processing agreements provide for, and whether the configuration would stand up next to the record of processing if the CNIL came knocking.
Can anyone besides the author take the application on, or does the whole thing live in one developer's memory and in a repository under a personal account.
Findings ordered by severity, the business consequence spelled out for each, an order of magnitude for the cost of repair, and a joint reading over video.
Duration follows the size of the application and the number of integrations; it is stated before we begin. We work with read-only access throughout.
An acquisition, a change of contractor or a plain assessment of risk. The purpose decides which areas get close attention and how detailed the report becomes.
Code repository, documentation, hosting console, logs, open tickets. We also speak to the team over video, since part of the knowledge was never written down.
Each criterion is weighed separately and every finding comes with what it means in practice for the business.
A report handed over and then read together, ranked from the most serious to the most minor, with a price attached to each repair.
The worst finding is almost never ugly code. Inelegant software can serve a company for ten years. When a single developer understands the machinery, though, and nothing is documented, the business negotiates from a weak position at every contract renewal. We record that reliance separately, apart from the technical quality of everything else.
A good deal: how the application behaves, response times, the published configuration, the database structure if you have access to it, error logs, contracts and invoices. The report will be shorter and will state plainly what could not be checked. Not holding the sources is itself a finding; it is worth rereading what your contract says about ownership of the code.
Yes. In that setting we look at what bears on the valuation: the technical side of the open source licences embedded in it, with the legal reading left to your solicitor, accumulated debt, reliance on a handful of people, and running costs once the deal closes. The timetable follows the one set by your adviser.
We describe a state and a set of risks; we do not grade people. In practice teams often gain from it, because arguments they have repeated for two years are finally heard once they arrive from outside.
A mid-sized application usually needs one to three weeks depending on the number of integrations. We work at EUR 95/hour excl. VAT, or for a fixed price quoted after a first online conversation, once the scope is known.
We write that down, with the reasoning and two figures: gradual repair or a rewrite. The decision is yours, it is simply firmer when it rests on amounts rather than on an impression.
Describe the application and the reason for the review. You receive a report where risks are ordered from the most serious to the least.
Message received
An answer follows inside one working day. Report an outage that is stopping people working and it moves ahead of everything else.
Nothing here under that name. Check the spelling, or simply choose the nearest large city instead. Since every engagement runs remotely, whichever you pick changes nothing about what we do for you.