Software maintenance after launch belongs to the team that built the system, to a team that inherits it, or to staff the business already employs. The choice changes how the code gets set up, so it is settled in the repository while the system is being built. In AlgoCar stock moves the moment a part lands on a work order, and if that link breaks nothing fails loudly until month end.
The question asked on launch day was already answered
In AlgoKlima, a technician opens a record while standing outside network coverage. The record is written to the phone’s local queue first, and the app never waits for a connection. When the connection returns, the queue drains in creation order. Where a record is first written is a setup decision, and it is the kind of decision most teams make once and then stop thinking about.
There is a second half to it that gets less attention. Keeping that queue working has to be somebody’s job after launch. Add a field to the record structure and the queue has to carry the new shape. Change a rule in the office panel and the queue has to respect it. Neither adjustment happens by itself. So the question of who that somebody is was settled the day the queue was built — even if nobody wrote the answer down anywhere.
AlgoCar has the same property in a different shape. Parts consumption is deducted from stock the moment it is written to a work order; the warehouse movement is not entered a second time on a separate screen. That is one record triggering another. If the link between them breaks, nothing fails loudly. No screen turns red. Stock counts quietly start lying, and the discrepancy surfaces at month end, when the warehouse and the work orders disagree about what was used. Keeping that link intact is somebody’s responsibility for as long as the product lives.
What both examples share is that maintenance is not a phase that starts when something breaks. It runs while the system works, because in a working system maintenance means making sure current behaviour survives the next change.
Algoriel has 5 products of its own. AlgoKlima and AlgoCar run in production; the rest we are still building. The maintenance cost of those two is one we pay ourselves, on software we wrote.
The maintenance question is a specific case of the cost of undoing an architectural decision: ask it late and the decisions that determine the answer have already been made for you.
What maintenance actually covers
Describing maintenance as bug fixing takes a small slice of the work and calls it the whole. On the SsangYong corporate site, catalog reads are answered from a Redis cache and MySQL steps in only when data changes. Keeping that arrangement intact is maintenance in the most literal sense. Add a new model to the catalog and the cache will happily keep serving what it already has. When the cache gets invalidated is a rule, and that rule has to be reconsidered every time a feature touches catalog data.
The same site has a second example that involves no runtime behaviour at all. Vehicle images were moved into a single naming and folder scheme. On the day that work finished, nothing measurable improved. The value shows up on every model added afterwards: as long as the scheme is followed, which file belongs to which model is visible without reading code. The moment it is not followed, adding a model turns back into a file hunt. Holding a scheme in place is maintenance, and this part of maintenance is not code — it is a convention that nothing compiles and no test enforces.
A third face of it lives in AlgoKlima. Changes arriving from the field and from the office merge into one record through conflict resolution. Add a field or a screen to the product and two things have to move together: the record shape the queue carries, and the conflict rule that decides which version wins. Update one and leave the other and a field record will silently overwrite an office edit. “Keeping offline sync working” is precisely the discipline of moving those two together.
There is a case where almost none of this applies. On a static brochure page whose data never changes, there is no cache to invalidate, no storage scheme to drift, and no pair of conflicting edits to reconcile. Maintenance load scales with moving parts, not with system size. This is why the maintenance question does not weigh the same on every project. What makes it heavy is the number of records that trigger each other.
Three real answers, three cost structures
The answer splits three ways, and each way is expensive somewhere different. The original team pays nothing to read the code; the links between moving parts already sit in the heads of the people who put them there. A takeover team has to read first, and reading is not a one-time charge — it recurs for every new area it touches. The business’s own staff pay neither exactly; their cost is learning, because they have to know every tool in the stack rather than every line in it. Which of those three costs a business can actually absorb is what decides the answer.
The practical consequence shows up at handover. If the original team stays, very little has to be written down, because the knowledge is where the work is. If a takeover team is coming, the same knowledge has to exist somewhere outside the code: which rule lives where, which process starts with which record. If in-house staff take it on, a list of tools belongs next to that document, because what they have to learn is not only the system but the ground it stands on.
Our own portfolio maps onto all three, and the SsangYong case carries two answers at once. We were the takeover team, and long-term maintenance was always going to sit with the brand’s own side. Those two facts squeezed the same decision from opposite directions.
| Who maintains it | How much of the code they must know | When it makes sense | Where it stands in our portfolio |
|---|---|---|---|
| The original team | No reading cost; the links between moving parts — the offline queue, the conflict rule — are already in the writers’ heads | The system will keep changing as it lives, and it contains parts that run continuously | AlgoKlima — in production; the team that wrote the field app’s sync queue still operates it |
| The original team | Must know which end of the work order, stock and invoice chain triggers what; the chain grows without snapping while it stays with one team | Records are chained together, and changing one end has to be visible at the other | AlgoCar — in production; parts consumption comes off the work order, and the chain stays under our maintenance |
| A takeover team, with long-term maintenance passing to in-house staff | Has to read from zero, which is why work stays inside what has been read and what carries the page load; the framework and front-end set the brand’s own team works in stays as it is | The team that built it has left the table, the system still stands, and permanent maintenance will sit with the business | SsangYong corporate site — we took it over; the code was read first, working sections stayed in place, the framework and front-end set did not change |
| The original team, with maintenance planned before launch | The ground is already operated daily; a new product adds no new learning load | The maintenance question is meant to be answered at setup rather than after it | AlgoRandevu — in development; we are building it on the same Laravel and Inertia ground as AlgoKlima and AlgoCar |
There is a fourth option that looks like an answer and is not: nobody maintains it. Leaving the decision open does not stop any of the mechanisms above. The cache keeps going stale, the storage scheme keeps drifting, the queue format keeps aging alongside the product. The only difference is that on the day those things break, who repairs them is still undecided — and whoever ends up doing it starts by reading code they have never seen.
When the original team stays: maintenance inside our own products
In AlgoKlima, where the office panel and the field app hang off the same core, the panel is built with Laravel and Inertia and the field app with React Native (Expo), both reading and writing the same MySQL core. Maintaining that means carrying two surfaces at once. Change a record structure in the core and you have changed something in the panel screen and something in the field app’s local queue. The team that wrote it knows that link without looking it up, and that is exactly why maintaining it is cheap for us. The link is not in a document. It is in the hands of the people who decided it.
The same product holds warranty, maintenance and fault records under the device rather than under the customer card. Several units at one address keep separate files, and a unit that changes hands keeps its history. The value of that data model decision accumulates over years, and the accumulation only continues if the decision is deliberately preserved in every new feature. Attaching a record to the customer is always the easier move in the moment. Not taking the easier move, repeatedly, is what day-to-day maintenance actually looks like.
In AlgoCar, where the work order, the parts consumed and the invoice advance along one chain, service history is attached to the plate and chassis record, so a vehicle that is sold takes its history with it. Every new record type added to that chain touches all of its links. Adding a field is never just a screen decision; it also settles whether the value is read from stock or from the invoice. A team that built the chain does not rediscover that question each time it comes up.
The arrangement has a cost for the business, and we are the side that benefits from it. When the original team maintains a system, the business is tied to that team by continuity. If the team becomes unavailable, or the relationship ends, the business is left holding a system whose reading cost it has never paid. The SsangYong project chose the opposite arrangement for exactly this reason. The original-team answer is right for our own products because we are both the writer and the operator; that is a property of our situation, not a general rule.
The takeover team reads before it writes
The KGM SsangYong corporate site, a Laravel codebase we inherited rather than started, came to us already live. The first task was not writing. It was reading. The codebase was read first, and the sections that worked were left exactly as they were.
A takeover team’s first deliverable is not code. It is a map: what works, why it works, and which behaviour depends on which piece of code. Every line written before that map exists is a guess. Guesses are not billed immediately either — the cost lands later, on the day somebody notices that the section you changed was quietly feeding something else.
Work stayed where the page weight was. On model pages, image sizes and the requests made through jQuery were reworked; the heavy sections were taken one at a time. A takeover team does not touch everything, because every part it touches widens the area it is obliged to understand. That restraint is not timidity. It is arithmetic: changing an unread section means adding the reading of that section to the job.
The second deliverable of a takeover is the set of traces it leaves for whoever comes next. The image storage scheme was set up so that which model uses which file is visible without opening any code. That knowledge now sits outside anyone’s memory. A takeover done well makes the next takeover cheaper.
“Leave working things alone” was available to us because the system genuinely worked. If an inherited system has no working sections left, the job is not a takeover — it is a rebuild, and it should be priced and planned as one. Reading inherited code before touching anything that already works is the order we follow in software consulting work: the map first, the intervention second.
In-house maintenance decides the stack
On the SsangYong corporate site the work stayed inside Laravel, Tailwind and jQuery, and apart from the cache layer nothing entered the stack. That was not a matter of technical taste. Long-term maintenance would sit with the brand’s own side, and every tool added to the framework would have become something that team was obliged to learn. Keeping jQuery in place was judged by maintainability rather than by modernity.
The choice cost us something concrete. A ready-made dependency would have shortened the work of rewriting the requests we were already touching. But the time it would have saved sat on our side of the table, and the time it would have added sat on the brand’s side — the side that carries the system far longer than we do. At that point the stack stops being a preference and becomes the maintenance decision itself, written into the repository. Choosing tools by who already knows them is how the maintenance answer gets encoded.
We apply the same rule to ourselves in our own products. AlgoRandevu is being built on the same Laravel and Inertia ground as AlgoKlima and AlgoCar. The team that will maintain it — this time us — already operates that ground daily. A new product adds no new learning load, and the panel’s screen logic stays recognisable because it comes from the same family.
Alongside the stack choice there is a second lever: moving part of the maintenance burden out of code and into configuration. In AlgoRandevu, appointment length and the spacing between consecutive slots are left as product settings instead of being hard-coded per industry. When a rule changes, a setting changes rather than a file. That directly reduces how much code the person doing the maintenance has to read before they can act.
The rule has a boundary. If the tool set an in-house team knows cannot carry what the problem requires, familiarity alone will not save the project. A field app does not work offline because it was written with a familiar tool. At that point either the tool set is deliberately widened and the learning cost is accepted, or the maintenance answer changes to something else. How the maintainer decision shapes the stack is one of the first things we put on the table in system architecture work, well before anyone opens an editor.
Planning maintenance before launch: the three products we are building
AlgoRandevu, where the definition of an appointment is not hard-coded to one industry, is in development now. The goal is to avoid shipping a separate version per industry: as long as the appointment definition stays configurable inside the product, a clinic, a studio and a workshop all feed from one code body. Branching in maintenance is being prevented while the product is still being set up, because in a branched codebase every fix arrives with a second question attached — how many versions does this apply to.
In Secretum we are keeping the character record as a MongoDB document. As a character gains new attributes, the document structure flexes rather than forcing a schema rebuild on every addition. Image work goes into a Redis queue, the produced file is written to S3, and the feed does not regenerate it — so the cost of any given image is paid once. For live updates we are building a single Reverb broadcast on the Laravel side, which both the Vue 3 web interface and the React Native (Expo) client listen to. Reducing the broadcast path to one is a maintenance decision made in advance: it removes the possibility of two clients drifting apart in behaviour later. The product is in development.
In QRVizit the separation is being established from the start: the address behind the printed QR code is fixed once, while the page it points to changes from the panel. Updates go to the record, not to the cards. Page content is cached in Redis so that repeated scans of the same code do not all fall through to MySQL, where the records themselves live. The panel and the visitor-facing page sit in one Laravel application, so a content change never requires updating a second service. What this product sells is itself a maintenance promise, which is why the mechanisms that carry the promise are being built before launch rather than after.
What the three have in common is that the maintenance question is buried inside architectural decisions rather than sitting beside them. Setting or code, one broadcast or two, flexible document or fixed schema — each of those is an answer to who will maintain this and how. On launch day none of these questions get asked, because they have already been answered in the repository. And because they are not asked, maintenance starts as planned work.
