Suppose you operate a logistics warehouse inland from Koper. The program handling goods-in, shelf locations and dispatch was written years ago by a contractor who now has a job elsewhere and replies to messages within a few days at best. It works, and everyone is afraid to change it. The server runs a PHP release that gets no security patches, files for customs procedures are assembled by hand, and the board would like GLS and DPD integration, a customer portal and a tablet app for forklift drivers. Before investing on that scale, it pays to know what you are building on. A systems and architecture review delivers that answer in a form the board can follow: what is sound, what is dangerous, what will hold back growth and roughly what each fix will cost. We work solely with view-only access and on copies; your live environment stays untouched.
Each part of the review ends with a severity grade and an approximate price to resolve it, so risks can be weighed against each other.
Are the repository, domain, server and subscriptions held by the company? Does the developer contract transfer rights in the code? Which open source libraries are included, and do their licences permit the way you use them? Without clarity here any later plan stands on shaky ground.
We attempt a clean install in a separate environment, following only the existing instructions. Every missing step, forgotten setting or secret key that exists nowhere in writing is noted. It is the most direct test of whether somebody else could take the system on.
Where the business logic lives, how tightly the parts are tangled together, and whether one piece can be swapped without bringing down the rest. This decides whether modernisation can be gradual or has to be all or nothing.
Data integrity, missing indexes, tables that keep growing with no archiving. Alongside this we check where personal data sits, how it is protected and whether you can technically meet GDPR requests from individuals to see or delete their data.
Password storage, server-side permission checks, exposure of the admin interface, dependencies with published vulnerabilities. We do not attack anything, but the findings show where a later penetration test would earn its fee.
For the language, framework, database engine and operating system we note when vendor support ends or ended, and how hard moving on will be. You can see which fixes come with a deadline.
Who finds out if the program stalls overnight, whether backups are ever restored, what happens when Minimax, the e-invoice provider, Bankart or a courier API is slow to answer, and whether half-finished transactions get recorded anywhere.
Timing depends on the size of the application and how many outside systems it talks to. An estimate is agreed before work begins.
A short conversation about why you want the review, and a list of view-only accounts that you create yourself. We never need passwords sent by email.
We try to start the code from the repository in an isolated environment using only current documentation, logging every obstacle.
Code, schema, server settings and logs, plus brief video chats with those who use or maintain the system. Anything urgent is reported immediately.
Findings ordered by severity, each with an indicative price and a suggested sequence. We go through the document together on a call.
“The code is bad” helps nobody. Every finding in our report has three parts: what we found, what it could mean for your business, and roughly what it costs to sort out. Where a full rebuild is not justified we say so plainly, because steadily reinforcing a working system is often cheaper and less risky than starting again.
As insurance for both sides. The review is not hunting for a culprit; it documents the state of things that the developer will need anyway before any upgrade. It often helps him justify fixes he has been proposing for a while.
Start by checking the contract, with a legal adviser if needed, and ask for access. Until then we can do a limited review of the server, the database schema and the application's behaviour from the outside.
Yes, we review the back end, the API and how the mobile app or external system talks to it. For the look and feel of the app itself, a separate usability test is the better fit.
No. We read code and configuration, whereas a pen test actively attacks the system. The review tells you where such a test should aim, and is often a sensible step beforehand.
Following the introductory call you get a quotation with estimated hours at €50 per hour plus VAT, or a fixed fee if the scope is sufficiently clear.
Describe the application and why you want it reviewed. You will receive a report with risks ranked by severity and cost.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.
