If your business depends on a program whose developer can no longer be reached, whose source code is incomplete or which has no documentation at all, we take that system over, establish how it works on the basis of evidence, and bring it back to a state where it can live on.
Many manufacturing businesses in Türkiye still run on a custom program written fifteen or twenty years ago by a single developer. As long as the system works, no problem is visible; but when the developer retires, contact is lost or the relationship breaks down, the picture is always the same: the source code is missing or incomplete, nobody knows how any given calculation inside the program is performed, no new feature can be added, and even a small bug carries the risk of stopping production.
This is not a software development problem; it is an archaeology problem. Writing a new program is impossible without knowing the correct behaviour that the running system must be replaced with — and that behaviour is written down nowhere; it lives only inside the running code and the database. So the first step of the job is not writing code but collecting evidence: extracting the business logic from the compiled application, mapping the objects in the database, and clearly separating what is certain from what is inference.
At Pan Innovation House we have done this work end to end before. We analysed an entire compiled enterprise application line by line, reconstructed its menu and permission hierarchy, extracted its data access model, and labelled every finding in the report by evidence level: what was read directly from the code marked as certain, what came from the intersection of indirect clues as probable, and what lacked sufficient sources explicitly marked as unverified. The most dangerous thing when taking over a system is handing over guesses as if they were knowledge; that distinction sits at the centre of our method.
Businesses whose production, cutting, order or progress-payment tracking runs on a program written by one person who can no longer be reached. The system may still be running; but it cannot be changed or migrated, and there is nobody to step in when it fails.
Companies whose commercial relationship with their software firm has ended, or who are unhappy with the quality of service. During handover we verify that the source code has been delivered in full, and make the transition safe by demonstrating that we can stand the system up independently.
Businesses where a critical system is carried by a single employee or consultant. Transferring the knowledge to the organisation before this person leaves is far cheaper than trying to extract it afterwards; the handover file reduces this dependency in a measurable way.
Parties who want an independent view of the technical state of a company, division or software asset before buying it, together with family businesses passing to the second generation. We put in writing what is being taken over, what risk is being carried and what continuity depends on.
Analysing the compiled application, reconstructing the screen and menu hierarchy, establishing which screen touches which table and in what order the calculations are performed. The result is a readable map of business rules describing what the program does.
Rewriting stored procedures, functions and views whose source cannot be found, working from where they are called, the parameters they take and the results they produce. For each object the contract and the body are handled separately, and the result is validated by comparison against live data.
Identifying dependencies, licences and configuration; setting up an environment where the project can be compiled and run from scratch. No handover is real until this step is complete, because software you cannot change does not truly belong to you.
A report in which every finding is labelled with its source: certain knowledge read directly from the code, probable findings drawn from the intersection of multiple indirect clues, and areas that could not be verified for lack of sources are each shown separately. That way you know what you do not know as well as what you do.
Keeping the system running throughout the takeover: closing critical bugs, backup and restore drills, priority response to failures that stop production. The business does not stop while the analysis runs.
If the decision goes towards a rewrite, the old and new systems run side by side for a period; the transition is not considered complete until the outputs produced from the same inputs match exactly. Instead of a one-shot cut-over, we design a transition that can be rolled back.
First we stop the risk: we inventory what you have (installer files, fragments of source code, database backups, licences) and secure backup and restore. The output of this stage is an honest preliminary assessment of whether the job is genuinely feasible.
The application and the database are analysed line by line; screens, roles, tables and calculation flows are connected to one another. Every finding is labelled with its evidence level; a class or file name alone does not count as evidence, and inferences are grounded in the intersection of multiple independent clues.
Database objects and code fragments whose source cannot be found are rewritten and then validated against live data. Areas that cannot be verified are recorded in the report as gaps; they are not presented as closed.
An environment where the project compiles and runs is set up; installation steps, dependencies, configuration and known risks are put in writing. The handover file contains the minimum information someone other than you needs in order to keep this system going.
With the full picture in hand, we put the two options on the table with their numbers: keep the existing system alive, or rewrite it gradually. The decision is yours; the cost, duration and risk of both paths are compared in the same document.
In most cases, yes. If you have the compiled application and the database, most of what the program does can be extracted. But let us say it upfront: some information lives only in the source and cannot be recovered from the compiled form. That is why the output of the first stage is not a promise but an honest map showing what could be extracted and what could not.
No — and we recommend treating anyone who does with caution. Committing to an outcome without looking at the material is impossible. Our commitment concerns time and scope: at the end of a fixed period we deliver a report covering what we found, which parts of the system could be rebuilt and which paths are open from there. That report is valuable even if recovery proves impossible, because you then take the rewrite decision knowingly rather than blindly.
It depends on the size of the application, the complexity of the database and the material you have. That is why we structure the work as fixed-duration, fixed-scope packages; at the end of each period you see what came out and decide whether to continue. That way you never face an open-ended consultancy bill.
No. The analysis runs on a copy of the system and a backup of the database; the live environment is touched only with your approval and in pre-agreed maintenance windows. If a failure that stops production occurs during the takeover, priority response is in scope.
The decisive question is who owns the software. If the program was written for you, on your commission, taking it over usually means working on your own asset; but if the transfer of economic rights is not explicitly written into the contract, the situation can become contested. Before starting work we review your existing contract with you and, where needed, ask you to clarify it with a lawyer. We do not build work on top of legal uncertainty.
Four things: an evidence-graded analysis report describing what the program does, the rebuilt database objects, an environment where the project compiles and runs, and the handover file another team needs in order to carry on. All of it belongs to you; no dependency on us remains.
It is not right to take that decision before the analysis is done. A running system contains a large number of business rules accumulated over the years and written down nowhere; a new program written without seeing them usually ends up more incomplete than the old one. First we extract what is there, then we put the two options side by side in terms of cost and risk.
In a 30-minute discovery call we listen to what you need and tell you honestly whether custom development or an off-the-shelf product is the better answer.
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.
Details →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 →
