We find the cause of systems that lock up at end-of-day close, month-end reports that never open, and screens that stall when a few users log in at once — by measuring. Not with guesswork, but with query plans and profiling data, measuring before and after with the same rig.
System slowness is one of those problems that is noticed late and, once noticed, can rarely be reduced to a single cause. The program runs fast when first installed; as the data grows, the user count rises and new screens are added over the years, it grows heavier — first at certain hours, then constantly. The typical picture is this: a system that runs acceptably during the day locks up at end-of-day close, the month-end report keeps everyone waiting, and when a few users open the same screen at the same time, everything stops at once. These look like separate failures; they usually share the same root. This page covers slowness in the server, the database and the application's data access layer; browser-side loading speed and Core Web Vitals are a separate topic, covered on the PWA and web performance page.
The most common fix at this point is to upgrade the server. More cores, more memory, faster disks. Hardware helps in a system that has genuinely hit its capacity. But if the bottleneck is a bad query plan, a missing or badly designed index, repeated round-trips to the database inside a loop to fetch a single record, one long transaction making everyone else wait, or heavy reporting running on top of the live production database, a more powerful server carries the same work a little longer without removing the cause. Only measurement can tell which one it is; intervention without measurement is not improvement, it is guesswork.
At Pan Innovation House we approach this work with a method, not a promise. First we measure the current state, establishing by measurement which operation takes how long and where the time is being lost; we rank the bottlenecks by size of impact, apply each fix one at a time and measure again with the same rig. The work begins with a fixed-duration, fixed-scope diagnostic study; scope and duration are set down in writing before we start. Remediation is a separate item, and you decide on it only once the diagnosis is in your hands and you know how much work is involved.
Measurement is done with the same rig before and after: the same scenario, the same data volume and, as far as possible, the same load. Findings are split into two groups in the report: those verified by measurement, and those that only point in a direction and are not yet verified. An unverified finding is not used to justify a fix; it is measured first. If the source of the problem lies inside a program whose source code you do not have, its internals are examined only where you can show that you hold the rights to the software or have written permission from the rights holder.
Businesses producing carpet, textiles, food, plastics and machinery in Gaziantep and the surrounding organised industrial zones (OSB). Logo, Mikro, Netsis, Canias or SAP is installed; the system has grown over the years and now chokes at end-of-day close, during stocktaking or under heavy order entry. The diagnosis can be run without changing the ERP, in the layer alongside it and on the data side.
Firms whose cutting, order, progress-payment or production tracking runs on a custom program written years ago. The program works, but it keeps getting slower and nobody knows what is inside it. In that case, a performance diagnosis also means working out how the system operates.
Businesses where the report needed for a decision takes a long time to open — and slows other users down while it opens. The issue is usually not the report itself but the reporting load running on top of the operational database.
Systems used by several people at once — dealer portals, order screens, field applications — where everyone starts waiting as the user count grows. Deadlocks, blocking and connection pool exhaustion are the most common causes of this picture.
We measure the system's real load: which queries consume the most total time, which are called most often, which operation performs the most reads. Instead of individually reported screens, we produce a measured workload list and show, with measurements, where the time is being lost. This stage is run read-only; no change is made to the system.
We examine the execution plans of the critical queries, exposing the difference between scans and seeks, the deviation between estimated and actual row counts, and the cost of sorts and joins. Index recommendations are not added casually; each index's cost on the write side, its overlap with existing indexes and whether it is actually used are assessed separately. Every change on the database side is first presented as a written proposal; items that could affect your ERP vendor's support cover are flagged under a separate heading.
We work out who is making whom wait: long-running transactions, locks held too widely, unnecessarily strict isolation levels and deadlocks. The cause of systems that look fast with one user but stall as the user count grows is usually hidden here, and it can only be seen by measuring under concurrent load. This measurement is done in a copy environment or in a window agreed with you, not on the live system.
On the application side we identify problems such as repeated database round-trips inside loops (N+1), fetching columns and rows that are not needed, loading whole tables into memory without paging, misconfigured connection pools and connections that are never closed. This layer can bring the slowness back no matter how well the database is tuned.
Heavy reports running on the live production database slow the reports down and lock up operations at the same time. We design the structure that moves the reporting load to a separate read replica, summarised tables or a dedicated reporting layer. This structure does not replace the ERP; it is built alongside it, and we agree together how often each metric is refreshed.
We build a repeatable measurement rig so that before and after can be compared under the same conditions. After the fixes, we leave thresholds and monitoring recommendations so the gains do not erode over time, and we put in writing how to catch new development taking performance backwards.
First we pin down, in your own words, what is slow: which screen, which report, at what time of day, with how many users. Then we make those complaints measurable. A repeatable measurement rig is set up, baseline values are recorded, and which measurement runs when is agreed with you in advance. This record is the reference point we compare against at the end of the work; without it, no improvement can be demonstrated.
The system is profiled under its real load. Query plans, wait statistics, lock and blocking records and the application's data access calls are examined together. The diagnostic stage is run read-only; no change is made to the ERP itself at this stage. The aim is to find the source, not the symptom: the same slowness sometimes comes from a missing index, sometimes from a query inside a loop, sometimes from a single long transaction making everyone wait. Every finding is recorded together with the measurement it rests on; guesses are not presented as certainties.
The output of the fixed-duration, fixed-scope study is a written diagnostic report: the measured baseline, the bottlenecks found, the estimated impact of each and the size of the work needed to fix it. Findings are ranked on the axes of impact and cost; which can be solved without touching the ERP at all, which require changes on the database side and which of those need your ERP vendor's approval are listed separately. At this point, whether to proceed to remediation is your decision.
Approved fixes are applied one by one, not in a batch. If five changes are made at once, you cannot know which one worked and which one broke something else. Every intervention is tried in a copy environment first, goes through a review step before release, and goes live only with your approval and in a pre-agreed maintenance window; the rollback path is kept open at every step.
After each fix, measurement is repeated with exactly the same rig as in step one. Before and after values are reported side by side; a change that fails to deliver the expected gain is not presented as a win, and is rolled back if necessary. The work closes with thresholds, monitoring recommendations and the maintenance scope. The diagnostic report and the description of the measurement rig are delivered to you. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
No. Quoting a speed-up figure without looking at your system is selling guesswork instead of measurement. The cause of the slowness cannot be known without looking at the system; in some cases a single index transforms a table, in others the problem sits in how the application accesses data and deeper work is needed. Our commitment is about method, not outcome: we measure the baseline, show the bottlenecks with their evidence, and re-measure the effect of every change with the same rig.
This page does not rest on a published performance case study. Before work starts we agree with you in writing what we will measure, how, and under which conditions; before and after are measured with the same rig. We can show this approach on a working example during discovery; we do not name clients without their consent. What we offer is a diagnostic method, not a guaranteed outcome.
We do not replace your existing ERP; whether Logo, Mikro, Netsis, Canias or SAP (ERP packages widely used in Türkiye) is installed, it stays in place. The custom layer connects to your ERP through the routes its vendor supports (API, service layer or an approved import); it does not write directly into the ERP's database tables. The route depends on the version and licence and is agreed in writing during discovery. The diagnostic stage is read-only: workload, query plans and wait statistics are read, and no change is made to the ERP itself. If the remediation stage requires a change on the database side (an index, for example), we first state in writing whether it could affect your ERP vendor's support cover, and list the items requiring vendor approval under a separate heading. The decision is yours.
Hardware helps in a system that has genuinely hit capacity. But if the bottleneck is a bad query plan, a missing index, repeated queries inside a loop or locks waiting on each other, a more powerful server carries the same work a little longer and does not remove the cause. Whether the bottleneck lies in the CPU, the disk or in waiting is assessed with wait statistics, not guesswork. If, at the end of the measurement, hardware genuinely is needed, we say so in the report.
The diagnosis runs by observing the live system and working on a copy environment. The measurement methods used on the live system are chosen from the low-overhead ones, and which measurement runs when is agreed with you in advance. If concurrent load testing is needed, it is done in a copy environment or in a window agreed with you, not on the live system. The live environment is touched only with your approval; a rollback path is prepared for every fix in advance.
If you wish, yes — but it is not compulsory. The diagnostic report is written clearly enough for your own team or your current software vendor to apply: which query, which plan, which recommendation, on what grounds. The diagnosis is a fixed-duration, fixed-scope study; scope and duration are set down in writing before it starts. Remediation is a separate item and, because the size of the work is known by then, it is priced realistically. Taking the report and continuing with your own team is an acceptable outcome for us too.
This is a common situation and it directly affects scope. Without source code, a great deal can still be seen from the workload on the database side and the queries the application sends; which screen produces which query and where it chokes can largely be worked out. But if the fix has to be made inside the application, the program first needs to be taken over. That is a separate piece of work, and the diagnostic report states this explicitly.
A measured baseline; a written diagnostic report listing the bottlenecks with the measurements behind them, in order of impact; a proposed fix and estimated work size for each finding; a separate list of items requiring your ERP vendor's approval; and a description of the measurement rig so you can repeat the exercise. If we proceed to remediation, a record of every change reported with its before-and-after measurements. The source code we write and your data are handed over to you as defined in the contract; third-party and open-source components remain subject to their own licences.
We listen to what you need and tell you whether custom development or an off-the-shelf product fits better. The first 30-minute call is free; the scope of an on-site discovery, and its fee if any, is agreed in writing during that call.
We protect your critical business flows with automated tests: written acceptance criteria, end-to-end scenarios, a regression suite and automated pre-release runs. What an update broke should be learnt from the tests, not from a customer.
Details →We run security audits on delivered or inherited applications: authorisation and data access flaws, authentication weaknesses, injection risks, secrets and key management, dependency vulnerabilities. We also work on the side of closing the findings.
Details →We assess your existing software estate independently: an architecture map, a technical debt inventory with prioritisation, dependency and vendor lock-in risk, the team's way of working and a realistic roadmap. It is a piece of work that sets direction without writing code.
Details →We turn a working piece of software written for a single client into a sellable product: separating the core from the client-specific layer, a configuration engine, multi-tenant data isolation, installation and release management, and subscription infrastructure.
Details →We make it visible from one place where demand and supply diverge, which supplier is holding to its promised date and where the goods are waiting right now. The aim is not to install a new ERP; it is to gather the off-chain information your current system does not know and tie the planning decision to data.
Details →We bring together in a single chain where a request came from, which quotes were obtained, who approved what, and whether the invoice that arrives matches the order. Procurement runs in the system rather than in people's memories; every step can be read back afterwards along with its reasoning. Your existing ERP stays where it is.
Details →
