Your production application keeps running, even long after the original developers have moved on. We take over 2nd- and 3rd-line maintenance: incidents, security updates, minor changes and database monitoring. Predictable monthly pricing, fixed points of contact, transparent reporting.
An application in production has very different concerns from one still being built. The question is not "what do we build as the next feature" but "what is running, how stable is it, and what will be needed in a year to keep it that way". That calls for someone who understands the system thoroughly without wanting to add something new every week.
Many organisations come to us with a working application but no permanent team around it. The builder has moved on, the in-house developer has left, or there was never any internal capacity to begin with. We take on the technical responsibility — for applications we built ourselves and for applications from third parties where the documentation is still readable.
Our focus is on second- and third-line technical management: incidents that go beyond the helpdesk, RFCs with impact, security patches for dependencies, performance tuning for databases, and the kind of small changes your business team cannot afford to wait for. We also set clear agreements about what we do and do not cover; see the section below on the four forms of application management.
We usually work alongside your own functional manager or business owner, and with the party that runs your infrastructure. A good management relationship is a triangle: the business decides the what, we carry out the technical work on the application itself, and the cloud provider or MSP looks after the underlying infrastructure. We do not want to be shadow IT but a transparent partner: you get access to our ticketing system, monitoring dashboards and change log.
Not every application needs 24/7 monitoring, and not every business flow can tolerate eight hours of downtime. Together we choose the model that fits the impact the application has on your organisation.
For applications where a planned turnaround time is sufficient. We pick up incidents during normal office hours, carry out periodic maintenance and security updates on a fixed schedule, and report quarterly. No on-call duty, no hard response times, but you get a fixed point of contact and realistic expectations.
The most popular option. Four priority levels, each with an agreed response time and target resolution time. A monthly service review in which we discuss resolution times, incidents and outstanding maintenance. Service credits apply in the event of structural deviation: no penalty mentality, just clear measurement.
For business-critical applications that must also be monitored at night and at weekends. On-call rota, escalation protocol, monitoring with automated alerts. We only recommend this option if the impact analysis shows it is genuinely necessary; often a hybrid model (office hours plus on-call outside them) is the more cost-effective choice.
Management is not just "waiting until something breaks". A good management contract combines reactive work (resolving incidents), proactive work (preventing things from breaking) and planned work (minor maintenance, small changes).
Below are the activities we include as standard in a management contract. Combinations are possible: for example, you might take only security updates and database monitoring if you have your own developer for the rest.
The BiSL and ASL frameworks distinguish four roles around an application. It helps to be clear in advance which role you assign to us, and which you keep yourself or with another party.
Technical changes to the application, configuration, integrations with other systems, bug fixes and minor functional changes. This is our core task in a management contract.
Process ownership, release planning from a business perspective, setting priorities, user support for how-to questions. Better suited to your own organisation, as it concerns your work processes.
Servers, networks, OS patches at infrastructure level, physical databases. On modern stacks this largely sits with your cloud provider (AWS, GCP, Azure) or with an MSP. We are happy to work alongside that party.
User questions, password resets, telephone contact, ticket logging. We are not a first-line helpdesk. Your own IT department often handles this, or a specialised service desk provider.
A conversation about the application: stack, business impact, current situation, open issues and planned changes. We review the codebase and infrastructure remotely to assess what the takeover concretely involves.
If there is still a previous administrator or builder, we arrange a handover. No handover available? Then we reverse-engineer the application from code and documentation, and write the runbooks ourselves. By the end of the transition phase it is clear what work is in scope.
We choose the SLA model that suits the impact of the application: best-effort, response-time SLA, or 24/7 on-call, or a hybrid form. Also the scope: us alone, or shared responsibility with your internal team or another party.
From day one: logging incidents, handling RFCs, setting up monitoring. A monthly or quarterly service review in which we discuss turnaround times, outstanding maintenance and further development options. No lock-in: a reasonable notice period, and an orderly exit transition arranged too.
Employing your own developer is wonderful, until the moment they go on holiday, fall ill, or leave. A management contract with a development partner works differently and has a strong advantage on a number of points.
Several people work on your application with us. When someone is on holiday, ill or leaves, management carries on, with no panic meeting with the IT manager because the only developer has just resigned.
Database tuning, security audits and performance optimisation: we have these specialisms in-house. With an in-house developer, it depends on which background that person happens to have.
A major release, a security incident or an unexpectedly complex problem sometimes calls for extra hands. We can scale up from our team, which a single in-house developer cannot do alone.
A fixed monthly fee instead of hourly invoices plus the employer costs and overheads of an in-house developer. In quieter months we don't build up a backlog; in busier months there are no unexpected invoices.
Because we manage applications for several organisations, we spot patterns that an isolated developer would miss. A Postgres tuning approach that works on one application, or a dependency strategy that prevented a security incident elsewhere: we carry that knowledge across.
If an application carries so much deferred maintenance that continuing to manage it is money down the drain, we'll say so. We'd rather have an honest conversation about replacement or modernisation than keep a patchwork architecture alive for years.
The questions we're asked most often before signing a managed service contract.
A no-obligation half-hour conversation. We ask about the stack, the business impact and your current concerns, and give you direction on which form of management suits you, even if that ultimately is not with us. For larger enterprise software projects, we think through management scenarios from day one.
Appfront uses cookies and similar technologies to keep the website working properly, for analytics and for marketing. You choose what you allow. Read more in our privacy policy.
