Technical Maintenance

Yes. Taking on a system built elsewhere is a normal starting point for this service. We begin with a technical audit — code, dependencies, infrastructure, backups, and monitoring — which tells both sides what condition the system is in and what it needs. If the audit shows a system that is not economical to maintain, we say so plainly and set out the alternatives rather than charging for upkeep that will not hold.

We don't publish prices, because the honest answer depends on the system: its size, its condition, how much traffic it carries, and how much change you want alongside routine upkeep. Tell us about the system through the contact or project form and we'll set out scope and cost in a written proposal. The proposal states what is covered, so there is no ambiguity later about what sits inside the arrangement.

Monitoring usually tells us first: alerting is part of the standard setup, so failures surface without waiting for a user to complain. Issues are triaged by impact, fixed in version control, checked on staging where the situation allows, and released through the same controlled deployment used for planned work. Afterwards you get a plain account of what failed, what we changed, and what, if anything, should change to prevent a repeat.

Ownership, access, and service commitments — including response expectations and what happens when the arrangement ends — are defined in the written engagement agreement each project signs. The day-to-day work supports a clean exit regardless: changes live in version control, infrastructure and credentials are documented, and there is an audit trail of everything done. If you later bring engineering in-house or move to another supplier, handover is documentation, not archaeology.

Small improvements are part of the arrangement and are scheduled alongside routine upkeep. Larger pieces — a new feature, an integration, a redesign of part of the interface — get their own defined scope, so the maintenance budget is never quietly consumed by project work. Because we already run the system, the boundary is easy to manage: we tell you when a request has outgrown maintenance, propose it properly, and deliver it through the same staged pipeline.