Code review: know what your software is really worth.

You have been paying for custom software for years, but do you know what it looks like under the hood? We read the code, run the application and write down what we find: how secure it is, how reliable, whether it will last for years to come and whether you are with the right partner. Independent, with evidence for every finding and in language your management team understands.

  • ✓Independent verdict, no sales pitch
  • ✓Security, reliability and future-readiness
  • ✓Every finding backed up and prioritised
  • ✓A report for management and developers
Stijn Hoksbergen and René Vrieling of Empathree working on their laptops

When should you have your software reviewed?

Usually there is a moment when something starts to nag. Your business runs on a system, but you cannot judge for yourself whether it was built well.

You doubt your supplier

Invoices keep rising, changes take long and you never get a clear answer about the technical state of things.

Your business depends on it

Orders, stock, invoices or customer data run through this system. If it falls over or leaks, you have a serious problem.

A big decision is coming

Keep building, switch to another partner or start over? You would rather decide that on facts than on gut feeling.

You do not know how secure it is

Nobody has ever taken a critical look at the security. With GDPR and NIS2 you want to be sure.

The software is years old

The framework may no longer receive updates and packages are outdated. You want to know how far behind it is.

You are taking software over

In an acquisition, investment or supplier change, you want to know exactly what you are getting.

What we examine

We look at the code itself and we run the application. For each area we answer one clear question.

Security

Can someone get in who should not?

We look for holes such as pages without login, SQL injection, files that can be read from outside, passwords in the code and permissions that are not properly enforced.

Reliability

Does the system do what it should?

Bugs in the business logic: duplicate or wrong numbers, bookings that crash, data that is silently truncated. Plus performance, so you know whether it slows down as you grow.

Quality and tests

Can you change it safely?

Are there automated tests, does a check run on every change and is the code readable for another developer? That decides how expensive every change will be.

Versions and dependencies

How far behind is it?

We put every version in use next to the latest release: framework, programming language and third-party packages. Including known vulnerabilities and unsupported packages.

Future-readiness

Will this last for years?

Is the architecture logically structured, can you connect AI and integrations to it and can it be updated with reasonable effort? Or will you get stuck in a few years?

Supplier and ownership

Are you with the right partner?

Who owns the code, the hosting and the access? How dependent are you on one person or agency? And does what you pay match what was delivered?

What you get

A report you can read without being a programmer, with all the technical evidence behind it for anyone who wants to verify it.

  • ✓A management summary: the overall risk and what the problems mean for your business
  • ✓All findings with severity (critical, high, medium, low), the location in the code and how we established it
  • ✓A risk matrix of likelihood and impact, so you see what needs to happen first
  • ✓A version check of framework, language and packages against the latest releases
  • ✓Advice on the route: keep building, have it fixed, switch partner or replace
  • ✓A walkthrough in a meeting, also with your current supplier if you like
Example from a recent review
ERP system of a manufacturing company
Overall riskHigh
3
Critical
4
High
7
Medium
7
Low
Fix these first
CriticalModule routes are reachable without logging in
CriticalServer files containing passwords can be read from outside
HighSQL injection through a filter in the warehouse overview

Anonymised. Besides these security findings we found 44 functional bugs and a framework that is no longer supported.

How a code review works

There is little you need to do. We need access to the code and, if possible, a test environment.

1
Introduction and scope

We discuss what the system does, what worries you and which parts we examine. You get a fixed price up front.

2
Access and confidentiality

We sign a non-disclosure agreement and get read access to the repository. Your supplier does not need to notice anything, unless you want them to.

3
Investigation

Reading the code by hand, supported by scans and analysis tools, and running the application to see what happens in practice.

4
Report and meeting

You receive the report and we go through it together. Then you decide what to do with it.

Why an independent review

Your current supplier will rarely judge their own work critically. We have no stake in the outcome.

✓

An objective verdict

We say what we see, also when the software is well built. Then you know you can carry on with confidence.

✓

No mandatory follow-up

The report is yours. You can take it to your current partner, to us or to a third party.

✓

Evidence for every finding

Every finding has a file name, a line and an explanation. Your supplier can check everything themselves.

✓

Made by builders

We build custom software every day, in Laravel and Angular among others. We know how it should be done and where it usually goes wrong.

Frequently asked questions

Want to know where your software stands?

Tell us briefly which system it is and what you are unsure about. We will get back to you with a proposal for the scope and a fixed price.