Projects from our work: the client's starting point, the steps, the problems that were not obvious, and the results with numbers from logs and measurements. Each card ends with the related situations and the first step.
Web portals · 4 hours
After the move from PHP 7.4 to PHP 8.2, the same page loaded normally one moment and failed after 30 seconds the next. We rebuilt both versions side by side and found the cause: about 20 parallel AJAX calls of one user waited for the lock on the session file, one after another. Fixed with one line per script, without rewriting the application.
A WooCommerce shop with 52 products loaded slowly or not at all. The cause was a paid network of bots sending tens of thousands of requests an hour, each from a different home address, and every single bot behaved perfectly. Our engineers stopped the traffic at the edge of the network, and when the bots changed tactics a month later, the second rule took the load off within two minutes.
An Adobe ColdFusion application ran without complaint at low traffic and returned errors and slowed down at peak hours. We reproduced the problem on a real database, measured the exact point at which the JVM heap runs out, and fixed the memory configuration, with the same load test before and after as the proof.
We prepared a production installation of Adobe ColdFusion 2025 on Debian 12, behind an Apache 2.4 that already serves several other sites. The installation itself takes 34 seconds. The attention went into the connector and the configuration details that are easy to miss: an error 503 caused by IPv6, mappings that reach into every virtual host, and a profile that quietly adds a debugger.
A mail server for four company domains signed nothing, published no DMARC policy and was rejected by Microsoft. Our engineers audited it, piloted the change on one domain and rolled it out in batches. The result: all three checks pass at Gmail, the Microsoft block was lifted, and the users noticed nothing.
Services up, configuration valid, no errors in the system status. Yet phishing landed in the inboxes while partners' newsletters went to spam. Our engineers measured which detection mechanisms actually fired, repaired the causes, and three months later found and fixed a regression that only showed up hour by hour.
A shop database without indexes worked as long as the tables were small. At 500 000 orders and 1.75 million order items every filter and every join came down to a full scan. We measured exactly what the missing indexes cost, added the right ones, and documented the traps that make an index useless even though it exists.
Wedding guests scan a QR code, open one secret address and upload photos and videos straight from the phone: no app, no account, no login. Files of up to 5 GB land on the client's own disk, and the couple watches the gallery fill up during the party. One evening, no second chance, and phones from six years back.
Each card starts with a generic description of the client and the system, because full trust comes before marketing. What the cards do show are the numbers: from logs, from the measurements we made before and after a change, and where a problem was reproduced in our own environment, the card says so.
Every card always has the same structure: the starting point, the solution, the measured results, how we worked step by step, the challenges we overcame, and what we take from it. The section on the challenges is the one to read first: it lists the things that looked like a solution and were not.
If your situation resembles one of these, the related situations at the end of each card lead to the first step. The types of systems our engineers have looked after beyond these projects are on the page Experience; the course of a project, from the intro call to the written result, on How we work.
Our engineers have worked on these types of system:
Selected projects are described in detail on the projects page, among them ColdFusion in production and under load, email deliverability, a shop flooded by bots and SQL indexes in a shop database.
You will receive a first reply within one working day. When we begin work depends on our current workload and on the scope. We give you a binding answer in the intro call. If it is urgent, the 48-hour emergency assessment starts as soon as we have access to the system.
We arrange a substitute on request. We also write the documentation on request, and the repository is normally held on your side, so the code stays in your hands. How we work together is described on the page How we work.
You tell us the goal and the current state, and we say openly whether and how we can help. Reply within one working day, no obligation.
Reachable: Monday to Friday, 9:00 to 17:00 Central European Time; support and emergencies around the clock (24/7)