The pieces and their boundaries are settled before code.
Several institutions, one system, records kept apart.
One codebase, both stores: iOS and Android.
We take a running system over and improve it.
AI only where the problem actually calls for it.
Software Consulting
We read the code before touching it, leave the working parts where they are, keep changes to whatever carries the load, and stay inside the framework your maintaining team already knows. What you receive is a measured improvement rather than a report.
Software consulting means taking over a running codebase and improving it without a rewrite; the result is a measured change, not a report. The limit is drawn while the code is read: only what carries the page load is opened, inside the framework the maintaining team knows. KGM SsangYong's corporate site was taken over while live: images moved into one folder convention, catalogue reads came from a cache, and the working parts stayed shut.
We did not build KGM SsangYong’s corporate site. It was already live; the job was to make it lighter.
We read the codebase first. Two things stood out: vehicle images sat in a scattered store, and catalogue pages sent the same query to the database on every load. The files moved into a single naming and folder scheme, which made it visible without reading code which model uses which file. The catalogue reads got a cache in front of them, so one visitor’s result serves the next until the data changes. None of it was designed up front; it was diagnosed while reading, and the brand’s own team carries it from here.
Everything else stayed shut. On the model pages we worked through image sizes and the requests the page fires at the server one at a time, and the library set the site came with stayed exactly as it was. That set was not our choice. We stayed inside it anyway, because stepping outside would have handed the maintaining team a dependency it had never worked with. Who maintains software after launch is a decision we argue belongs before the launch, not after it.
Decisions taken before any code is written belong to this service too. Resterm’s heater selection software was built on the manufacturer’s own product structure: the user enters a heating requirement rather than a product code, the selection drops into a basket, and the basket connects to a project and to that project’s customer. It was clear before the first line that a general-purpose quoting tool with a catalogue added would not carry that chain.
What we actually do inside an inherited system is narrow and countable:
We read the inherited codebase through, then name what moves and what stays untouched, one item at a time. The scope of the change comes out of that reading rather than a template.
A library the maintaining team has never worked with would be a cost we left behind on our way out. KGM SsangYong's corporate site arrived with its framework and front-end libraries already chosen, and not one dependency was added to that set.
Only the slow places get opened; heavy spots are handled one at a time and the rest stays where it is. Where that limit falls is written down for you once the reading is done.
Scattered files move into a single naming and folder scheme. Which model uses which file becomes visible without reading code.
The same query repeated for every visitor can be run once and shared from there. On KGM SsangYong's catalogue pages that query no longer runs until the data changes.
Some decisions are made before the first line and are expensive to correct later. Resterm's software was built on the manufacturer's own product structure, because it was clear from the start that a general-purpose quoting tool would not carry it.
Every project goes through the same four stages: planning, architecture, modelling, development.
See our process
We took over a running Laravel site rather than building one. Vehicle image storage was rebuilt around one naming rule and the heaviest catalog queries moved behind a cache; everything that already worked was left where it was.
A selection and quoting tool for an electric heater manufacturer. The user states a heating requirement instead of a part number; the software runs the engineering calculation, and the heater it picks becomes a line on the quote.
The open source line in a proposal only tells you which parts carry no licence fee. Who tracks their updates, and who owns the code written on top, sits in other lines of the proposal.
One brief, several quotes that refuse to line up, and no document saying which quote priced which job. The three lines a brief tends to leave open, and the one sentence that closes each of them.
A decision is architectural when undoing it is expensive, and timing sets the price. Boundary sentences, derived records, inherited limits and the three calls we bind before the first line of code.
A system that 'talks to the accounting program' is a handover point between two owners, not a module. Which records stay with you, why one way beats two, and where a correction lands.
Backups are taken; in how many places does your record sit right now? In AlgoKlima, which we run ourselves, a record opened out of coverage sits on the technician's phone alone until signal returns.
The decision turns on the unit of record rather than the price. When the product's unit disagrees with yours, no settings screen closes the gap; it falls to a device, a print run or a second ledger.
Which page an AI answer draws on cannot be seen from outside. Your own sentence can be checked: read the meta description, FAQ answer and first line without the page, is each still true and complete?
If "who maintains this?" is still an open question on launch day, the decision was skipped, not deferred. How the maintainer choice shapes stack, handover, and build order.
Answers made of years, counts and adjectives will not tell companies apart. Questions whose answer is an address that opens today, a named boundary, or a place and an order, and how to check each.
Code and files sit on your disk, yet which file belongs to which record is known only to whoever read the code. The system runs; you cannot rebuild it. The handover list is the list of that gap.
It turns on one thing: whether the system already exists. If it does not, it gets built, and that belongs on the system architecture page. If it does, we read it first, bound the change, and keep the improvement inside the set your team already maintains. KGM SsangYong's corporate site is the example: the working parts were never opened, and only what carried the page load was touched. A few lines in the quote form about which side your system falls on is enough.
We will. What your team keeps is not having to learn a tool it did not choose; the set you maintain today is the set you maintain after we leave. KGM SsangYong's corporate site kept the set it arrived with, and maintenance stayed inside what the brand's own side could carry. Tell us in the quote form who maintains your system and we draw the boundary from there.
We can, and the reading is the same whether the work is finished or halfway. You get two lists back: what carries the page load, and what should not be touched. Nothing outside those two arrives as a recommendation, so no rewrite proposal lands on your desk. KGM SsangYong's codebase gave us exactly that pair: vehicle images in a scattered store, and a catalogue query repeating on every load.
By reading your codebase. You get no timeline and no tooling recommendation before that reading is done, because scope comes from the system itself rather than from a template. Resterm's heater selection software shows the same decision taken before code: the selection had to flow into a basket, the basket into a project, the project into that project's customer, and no general-purpose quoting tool would carry that chain. Write to us and we come back within 2 business days.