Uw productie-applicatie blijft draaien, ook als de oorspronkelijke ontwikkelaars al lang weg zijn. Wij nemen het 2e- en 3e-lijns beheer over: incidenten, security-updates, kleine wijzigingen en database-monitoring. Voorspelbare maandprijs, vaste contactpersonen, transparante rapportage.
Een applicatie die in productie staat heeft heel andere zorgen dan een applicatie die nog gebouwd wordt. De vraag is niet "wat bouwen we als volgende feature" maar "wat draait er, hoe stabiel, en wat is er over een jaar nodig om dat zo te houden". Dat vraagt om iemand die het systeem doorgrondt zonder elke week iets nieuws te willen toevoegen.
Veel organisaties komen bij ons aan met een werkende applicatie maar zonder vast team eromheen. De bouwer is verder getrokken, de eigen developer is vertrokken, of er was nooit interne capaciteit. Wij nemen de technische verantwoordelijkheid over — voor applicaties die wijzelf hebben gebouwd én voor applicaties van derden waar de documentatie nog leesbaar is.
Onze focus ligt op het 2e- en 3e-lijns technische beheer: incidenten die voorbij de helpdesk komen, RFC's met impact, security-patches op dependencies, performance-tuning op databases, en het soort kleine wijzigingen waar uw business-team niet op kan wachten. Met daarbij heldere afspraken over wat we wel en niet doen — zie de paragraaf verderop over de vier vormen van applicatiebeheer.
We werken doorgaans samen met uw eigen functioneel beheerder of business-owner, en met de partij die uw infrastructuur draait. Een goede beheerrelatie is een driehoek: de business bepaalt het wat, wij doen de technische uitvoering op de applicatie zelf, en de cloud-provider of MSP zorgt voor de onderliggende infrastructuur. Wij willen geen schaduw-IT zijn maar een transparante partner — u krijgt toegang tot ons ticket-systeem, de monitoring-dashboards en de change-log.
Niet elke applicatie heeft 24/7 monitoring nodig, en niet elke business-flow accepteert acht uur stilstand. We kiezen samen het model dat past bij de impact van de applicatie op uw organisatie.
Voor toepassingen waar planbare doorlooptijd voldoende is. We pakken incidenten op binnen normale kantoortijden, doen periodiek onderhoud en security-updates volgens een vast ritme, en rapporteren per kwartaal. Geen piket, geen harde responstijd — wel een vaste contactpersoon en realistische verwachtingen.
De meest gekozen variant. Vier prioriteitsniveaus, voor elke prioriteit een afgesproken reactietijd en een doel-doorlooptijd. Maandelijkse service-review waarin we doorlooptijden, incidenten en achterstallig onderhoud bespreken. Service-credits bij structurele afwijking — geen boete-mentaliteit, wel duidelijke meting.
Voor business-kritische applicaties die ook 's nachts en in het weekend gemonitord moeten worden. Piketdienst, escalatieprotocol, monitoring met geautomatiseerde alerts. We adviseren deze variant alleen als de impact-analyse uitwijst dat het ook echt nodig is — vaak is een hybride vorm (kantoor + on-call buiten kantoor) een betere kostenkeuze.
Beheer is niet alleen "wachten tot er iets stuk gaat". Een goed beheercontract bevat een mix van reactief werk (incidenten oplossen), proactief werk (vóór zijn dat iets stuk gaat) en planbaar werk (klein onderhoud, kleine wijzigingen).
Hieronder de werkzaamheden die we standaard meenemen in een beheercontract. Combinaties zijn mogelijk: u kunt bijvoorbeeld alleen security-updates en database-monitoring afnemen als u zelf een ontwikkelaar heeft voor de rest.
Het BiSL- en ASL-frame onderscheidt vier rollen rond een applicatie. Het helpt om vooraf duidelijk te zijn welke rol u bij ons belegt, en welke u zelf of bij een andere partij houdt.
Technische aanpassingen aan de applicatie, configuratie, integraties met andere systemen, bug-fixes en kleine functionele wijzigingen. Dit is onze kerntaak in een beheercontract.
Process-eigenaarschap, releaseplanning vanuit business-perspectief, prioriteiten stellen, gebruikersondersteuning bij hoe-vragen. Past beter bij uw eigen organisatie omdat het over uw werkproces gaat.
Servers, netwerken, OS-patches op infrastructuur-niveau, fysieke databases. Op moderne stacks ligt dit grotendeels bij uw cloud-provider (AWS, GCP, Azure) of bij een MSP. We werken graag samen met die partij.
Gebruikersvragen, wachtwoord-resets, telefonisch contact, ticketregistratie. Wij zijn geen eerste-lijns helpdesk. Vaak doet uw eigen IT-afdeling dit, of een gespecialiseerde service-desk-partij.
Een gesprek over de applicatie: stack, business-impact, huidige situatie, openstaande issues en geplande wijzigingen. We bekijken codebase en infrastructuur op afstand om in te schatten wat de overname concreet inhoudt.
Als er nog een vorige beheerder of bouwer is, plannen we een overdracht. Geen overdracht beschikbaar? Dan reverse-engineeren we de applicatie aan de hand van code en documentatie, en schrijven we de runbooks zelf. Aan het eind van de transitiefase is helder welk werk in scope zit.
We kiezen het SLA-model dat past bij de impact van de applicatie. Best-effort, response-time-SLA, of 24/7-piket — of een hybride vorm. Ook de scope: alleen wij, of in een gedeelde verantwoordelijkheid met uw interne team of een andere partij.
Vanaf moment één: incidenten registreren, RFC's afhandelen, monitoring inrichten. Maandelijks of per kwartaal een service-review waarin we doorlooptijden, achterstallig onderhoud, en doorontwikkelopties bespreken. Geen lock-in: opzegtermijn redelijk en transitie-uit ook netjes geregeld.
Een eigen ontwikkelaar in dienst is geweldig — tot het moment dat die op vakantie gaat, ziek wordt, of vertrekt. Een beheercontract bij een ontwikkelpartner werkt anders en heeft op een aantal punten een sterk voordeel.
Bij ons werken meerdere mensen aan uw applicatie. Bij vakantie, ziekte of vertrek loopt het beheer door — geen paniek-gesprek met de IT-manager omdat de enige developer net is opgezegd.
Database-tuning, security-audit, performance-optimalisatie: deze specialisaties hebben we in huis. Bij een eigen developer hangt het ervan af welke achtergrond die persoon toevallig heeft.
Een grote release, een security-incident of een onverwacht complex probleem vraagt soms om extra handen. Wij schalen op vanuit ons team — een eigen developer kan dat niet alleen aan.
Een vaste maandprijs in plaats van uurtje-factuurtje plus de werkgeverskosten en overhead van een eigen ontwikkelaar. Bij rustige maanden bouwen we geen achterstand op; bij drukke maanden geen onverwachte facturen.
Doordat we voor verschillende organisaties applicaties beheren, zien we patronen die een geïsoleerde developer mist. Een postgres-tuning die op de ene applicatie werkt, een dependency-strategie die ergens anders een security-incident voorkomen heeft — die kennis nemen we mee.
Als blijkt dat een applicatie zoveel achterstallig onderhoud heeft dat verder beheren weggegooid geld is, zeggen we dat. Liever een eerlijk gesprek over vervanging of modernisering dan jarenlang een patch-architectuur in stand houden.
De vragen die we het vaakst krijgen voordat we een beheercontract afsluiten.
Een vrijblijvend gesprek van een half uur. We vragen door op de stack, de business-impact en de huidige zorgen — en geven u richting over welke vorm van beheer past, ook als dat uiteindelijk niet bij ons is. Voor grotere enterprise-software trajecten denken we vanaf dag één in beheer-scenario's mee.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
