Software does not end on the day it is delivered; that is where it really begins. With an annual maintenance contract, monthly development capacity and emergency response, we take on keeping the system standing. We maintain software we wrote ourselves and programs taken over from others. Being in the same city means this: when a job cannot be solved over screen sharing, we come to Başpınar or Şehitkamil and sit down at the server.
Maintenance is not one single thing. Keeping the system standing, continuing to develop it, and stepping in when production stops are three different jobs, and rolling them into one line usually leaves both sides unhappy. We separate the three and work out with you at discovery how much of each you need. How often we come, which jobs are included and which are not — the answers sit written inside the contract.
The regular work that keeps the system running: bug fixes, monitoring server and database health, regularly testing that backups are taken and can actually be restored, security updates, and mandatory adaptations driven by regulation or counterparties. What is inside and outside the scope is written out clause by clause — so that no argument comes later.
We reserve a set number of working days per month for new features and improvements. You do not wait through a separate quote and approval cycle for every request; the work list is prioritised together at the start of the month, and the order can change during it. Whether unused capacity carries over is also written explicitly into the contract. This model suits businesses with a constant stream of small development needs.
A separate route for failures that stop production or invoicing. Who calls, which number they call, and within what time the first response and the on-site intervention are expected are defined up front. These times are not a standard promise recited to everyone; they are set to your shift pattern — a weaving plant running night shifts and an office working business hours do not have the same needs.
To see the failure before the user does, we monitor the system: disk and memory levels, whether the integration flows are running, error logs, creeping transaction times. Because taking a backup is not enough, we run restore drills at regular intervals. An integration that stopped silently and went unnoticed for days is a picture we often see where there is no maintenance.
Even if we did not build the software, we can maintain it; the condition is understanding it first. If the source code is not in your hands, we extract the business rules from the running system on an evidence basis, reconstruct lost database objects from the places they are called, and work to stand up an environment that compiles and runs. We have done this before; the report marks separately what could and could not be recovered — we never hand over guesses as knowledge.
Every change we make is recorded together with its reason; the version history, configuration and known risks stay with you in writing. The aim is that someone else could carry this system on after us. A maintenance service that made you dependent on us would be reproducing the very problem it is meant to solve.
We answer the question of what you actually have: which programs are running, whether the source code exists, where the server sits, how backups are taken, whose name the licences are in, which integrations are live. For this work we come to the factory and go into the server room too. At the end you get an honest picture; for some systems we will also say the right answer is not maintenance but takeover or replacement.
Before any contract talk, we close the most urgent risks: if backups are not running, they start; a taken backup is tested by restoring it; anything with a high chance of stopping production is moved to the front. When you take over a system, the first job is not improving it — it is keeping it from falling over.
What is included, what is billed separately, who calls whom through which channel, and what counts as an emergency all go into writing. One copy of this document sits with the production manager and one with accounting — because at the moment of failure, the person reaching for the contract is rarely the person who signed it.
Monitoring and alerting are put in place, then a monthly rhythm begins: prioritising the work list at the start of the month, development during it, and a written account at the end of what was done. A maintenance service that does not explain what it does stays invisible for as long as it is paid — and gets cut at the first budget squeeze.
Every three months we sit down and discuss the past period with measured data: how many incidents occurred, from which root causes, which jobs keep coming back. A recurring fault is not a maintenance matter but a design matter; the work that emerges here goes into the next period's development list.
Yes, but we look first. Promising maintenance without understanding a system would not be honest. The first stage is inventory and a health check: the source code, database, server and integrations are examined. At the end you get an honest answer; sometimes that answer is 'we can maintain this', and sometimes it is 'this system needs a takeover project before anyone takes on its maintenance'. Those are different jobs and are priced separately.
In most cases, yes. If the compiled application and the database are in your hands, most of what the program does can be recovered. We have done it before: we worked out the daily calculation formula of an enterprise application with evidence, but the monthly calculation layer remained missing and we marked it clearly as missing in the report. Some knowledge lives only in source code and cannot be brought back; what you get from us is not a promise but a map showing what is known and what is not.
We have no sign on the wall quoting the same time to everyone, because the needs are not the same. The times are written into the contract around your operating pattern: the first-response time for a production-stopping failure, the situations requiring on-site intervention and the out-of-hours coverage are each defined separately. This is where being in the same city shows its concrete value: coming to Başpınar or Şehitkamil for a job that has to be looked at on site is not the same thing as waiting for a team from another city.
It means we reserve a set number of working days each month for your development list. You do not go through a separate quote, approval and invoice loop for every small request; the list is prioritised together at the start of the month and priorities can shift during it. Whether unused capacity carries over, and which jobs count as outside the scope, is written explicitly into the contract. For businesses with a constant stream of small development needs, this model makes the budget predictable.
We can, and in some situations that is the right thing to do. The knowledge of someone who has known the system for years is valuable; sharing their load rather than taking their place carries less risk, especially through transition periods. In such an arrangement we make clear from the start who is responsible for which area and how changes will be recorded. Two teams touching the same place unannounced causes bigger problems than one team working slowly.
Yes. A specific fault, a single report, fixing an integration or diagnosing system slowness can each be done as a one-off package with scope and duration written up front. We do not impose a maintenance contract as a precondition. We only say this: a one-off intervention does not amount to taking on responsibility for keeping the system standing, and without a contract that responsibility stays with you.
No. There can be sound reasons for the server staying at the factory: proximity to the machines, production continuing through internet outages, data ownership. We provide maintenance in both setups. On an on-premise server the critical thing is not the location but whether the backup genuinely restores and whether the room's power and temperature have been thought through. We check these on site during the assessment; we have seen OSB facilities where the server sat in a cabinet inside the production area.
You leave, and everything stays in your hands: the source code, database, configuration, change logs and handover file. We do not build the maintenance relationship as a lock; we prepare the handover file from the first day of the relationship, on the assumption that someone else could carry on. We want your reason for staying with us to be that we do the work properly — not that you have no choice.
Let's map out together which programs your business runs on, where the source code lives and whether the backup has ever actually been restored. That assessment is useful on its own; you decide afterwards whether the maintenance needs taking on. We are in the same city, and getting there is a phone call away.
