Operations and upkeep

Updates, backups, faults, further development and introduction. From one hand if you want it, and commissionable step by step.

Software is not finished after launch, it is in operation. Consulting, prototype, delivery and upkeep come from one hand, on every development.

What belongs to it

Applying updates before a hole becomes an incident. Backups somebody has restored once, rather than merely created. Fixing faults. Developing further as requirements change, and they do.

Plus introducing new people. Knowledge about a system rarely sits in the documentation and usually in one person’s head; when they leave, the whole thing starts over.

How it is agreed

Every step can be commissioned on its own. Anyone able and willing to handle the upkeep themselves does: the systems are open, the access is yours, and I hold nothing back that is needed for it.

What you do and what I do we settle beforehand, not during an incident.

What does not happen in this phase

No quiet expansion. An addition nobody ordered does not appear on the invoice either.

And no lock-in through technology. If you want to move operations elsewhere, that is a handover and not a migration: there is no format and no interface only I can read.

Frequent questions

Can we handle the upkeep ourselves?

Yes. The systems are open, the access is yours, and I hold nothing back that is needed for it.

What happens during an incident?

What applies then we agree beforehand: availability, order of work, who calls whom. During an incident that is no longer a negotiation.

A system that is already running?