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.
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.
Visit the site →The KGM SsangYong corporate site was already live when it reached us. On a job like this the first decision is not a technical one: you decide what you are not going to touch. We read the existing code, then went into the places that were carrying the page weight and stopped there. The framework and the front-end set stayed as they were, because the brand’s own team maintains the site from here, and adding a tool they do not use would have tied that maintenance to us. There is a cost to working this way, and it is worth naming. Instead of a clean rewrite, the work is a set of smaller moves inside a shape somebody else drew.
We go through how the work runs today and what you expect from the software; the scope comes out of that.
We decide what the system is made of and where its information is kept.
We draw the screens and the flow before any code, and start building once you have approved them.
We write and hand over the software so another team could carry it on.
Images moved into one naming and folder convention, so you can tell which model a file belongs to without opening the code.
Catalog queries are served from Redis; MySQL only runs when the underlying data changes, not once per visitor per page load.
We went through image sizes and the jQuery requests on model pages, taking the heaviest sections one at a time.
Work stayed inside Laravel, Tailwind and jQuery. The one thing added to the stack was the cache layer; the framework and front end the maintaining team knows were left as they were.
| Challenge | Result |
|---|---|
| The site was already live, so the brief was maintenance rather than a rebuild | The intervention stayed where the page weight was and went nowhere else |
| Vehicle images sat in an inconsistent layout, with no clear rule about where a file belonged | Vehicle images follow one layout, so adding a model is no longer a hunt |
| Every catalog page view sent the same query to MySQL and paid for it again | Catalog reads come from cache instead of querying MySQL on every visit |
| The framework and front-end set had to stay: the brand's own team maintains this site | Maintenance stays within the framework the brand's own team already runs |
Our own workshop software, built around the car on the ramp. A work order, the parts it consumes and the invoice it produces run as one chain, and the accounting side hangs off that same record. Maintenance history lives on the plate and chassis, so it travels with the car.
Our own product for HVAC, boiler and appliance service companies. The customer and device records the office works from are the same ones the technician carries into the field. A job can be opened and closed in a basement with no signal, and service history stays tied to the device.
Our own product, still in development and not yet live. How long an appointment runs, what it is booked against and how bookings stack all differ by trade, so we are keeping those rules configurable inside the product instead of fixing them in code.
Tell us how the work runs today and we will look at which step could move into software.
