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.
Project takeover
On handover day we ask for one thing, read-only access to the repository. What comes back is a written list: which parts were opened, which stay as they are, and what joined the stack.
Project takeover means taking on a live system another team wrote, without rewriting it. What gets opened, what stays as it is and what joins the stack are decided while the code is read, and the boundary comes from whoever maintains the system. On KGM SsangYong's corporate site the brand's own team set that boundary: the framework and the front end stayed put, and the single addition was a cache layer.
Handover day starts with one request from our side: read-only access to the repository. The system stays live that day, because we do not shut it down or rebuild it, we read it. When the reading is done you get a list with names on it: the parts that open, the parts left alone, the part added. The boundary of that list is set by the team that will maintain the system. How the reading itself is done, and where a change stops, belongs to the software consulting page; this page is about the handover day.
KGM SsangYong’s corporate site reached us while it was live. The list had one addition on it, a cache layer, and the application framework and the front end stayed exactly as we found them. The condition that the set would not change came from the brand’s team, the one that maintains the site, and we worked inside it. After the handover the team’s routine changed: the next model went in without a search through files.
The brand’s online store is maintained on one set together with the corporate site, so the takeover did not split maintenance between two teams.
Your system gets the same list. Every addition stands under its own name, and none of it waits inside the code as a surprise for whoever opens it next.
The usual worry at a handover is that the new team will move the system onto whatever stack it knows best. We do have a stack we know best: the web applications we build from scratch all share one set. That preference ends where your system begins. Getting to know the set your system came with is work we do, not work your team does.
What you hand over on day one, and what comes back:
Your system keeps running throughout the handover; nothing is shut down to be rebuilt. KGM SsangYong's corporate site was live on the day we took it over and stayed open to visitors.
The first job is reading the codebase through, so where things live comes from reading rather than guesswork. Any talk of timelines or tooling waits until that reading is finished.
Each part that joins the stack stands on the handover list under its own name, and a part the list does not name is not in the stack. KGM SsangYong's list carried one addition, a cache layer.
The first rule of a takeover belongs to whoever keeps the system running from here. We do not arrive with a proposal to move an inherited system onto a different framework, because that learning cost would stay with you.
A takeover proves itself on your maintaining team's next routine job rather than on the delivery date. After the KGM SsangYong handover, adding a new model no longer meant hunting through files.
When one organisation runs several systems on the same set, its maintenance knowledge is not split in two. A takeover does not open a second area of expertise for your team.
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.
Buyers pick a SsangYong model, configure it by trim and color, watch the price form from that choice and pay without leaving the flow. The configurator and the checkout are two steps of one flow.
Laravel in a proposal is a statement about the shape of your code, not about your business: the name cannot say which part of the system was built for the way you work.
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.
The proposal lists a domain name as its own line. Is that the website, or the address? Read what the registration is, why hosting is a separate item, and why a second system needs no second name.
We have no office, so we do not provide on-site support either. The work runs remotely and we scope it on that basis.
We will. You do not have to track down the original authors, because the code is read on its own and where things live comes out of that reading. Thin documentation is not a blocker either; the working system is what we measure against. KGM SsangYong's corporate site was not built by us, and we started by reading it.
Not while the working parts still work. What you pay for is a bounded change rather than a second build, and the live system keeps running while it happens. KGM SsangYong's site kept both its framework and its front end, and the stack grew by one part, a cache layer. Where the line falls in your system is something you read on the list once the code has been read.
It stays where it is. The framework we take over is the one your team can keep maintaining, so nobody on your side inherits the cost of learning a new tool. KGM SsangYong's brand team said from the start that the set could not change, and the handover was done on that condition. Write in the quote form which team maintains your system and that tells us which set we stay inside.
Not as long as the second system stays on the same set. Your maintenance knowledge is not split in two, because the people who know the corporate site know the store as well. KGM SsangYong's online store is built on the same set as the corporate site, and the handover opened no second one. How many systems you run, and which of them share a set, comes out during the reading.
A list with names on it. Which parts were opened, which were left untouched and what was added to the stack is written there, so nobody has to guess. KGM SsangYong's maintaining team saw the difference on its first routine job after the handover: adding a new model no longer meant searching through files. If your own team will not be maintaining the system, that same list goes to whoever will.