Je bureau is gestopt, je developer is vertrokken, of je prototype werkt in een demo maar niet in de praktijk. Wij kijken naar de code, zeggen eerlijk wat er nodig is en draaien het project daarna zelf.
Liever eerst een half uur sparren zonder verplichting? Plan een gesprek.
Verweesde software is zelden een technisch probleem alleen. Meestal is er ook iemand weg, is de documentatie zoek en durft niemand meer iets aan te raken. Wij zien deze zes situaties het vaakst.
De partij die je software bouwde bestaat niet meer, is overgenomen of reageert niet. Je hebt wel een werkend systeem, maar niemand die het aanraakt.
Alles zat in het hoofd van een vaste of ingehuurde ontwikkelaar. Die is weg, en met hem de kennis over hoe het in elkaar zit.
Er is budget in gegaan, er staat iets, maar het laatste stuk naar iets bruikbaars is nooit gemaakt. Het ligt al maanden stil.
Zelf gebouwd met een AI-tool en het ziet er goed uit. Maar er is geen inlog, geen foutafhandeling, geen beheer en geen idee wat het per maand gaat kosten.
Apple of Google accepteert geen nieuwe releases meer omdat de app te ver achterloopt op de SDK-versies. Updates zijn geblokkeerd.
Of je weet niet zeker of je hem hebt. Dat maakt een overname lastiger, maar niet automatisch onmogelijk. We zoeken het eerst uit.
Software laten overnemen begint bij weten wat je hebt. Wij doen dat in vier stappen, en na stap drie mag je gewoon nee zeggen. Dat gebeurt ook, en soms adviseren wij het zelf.
We brengen in kaart wat er is: broncode, repositories, app-store-accounts, servers, domeinen, databases en documentatie. Vaak ontbreekt er iets. Juist dat lijstje bepaalt hoe zwaar het traject wordt, dus we maken het eerst compleet.
We draaien de applicatie, lezen de code en beoordelen de staat ervan. Welke technieken zijn gebruikt, hoe ver lopen de versies achter, waar zitten de beveiligingsrisico’s en wat is er nodig om er weer veilig in te kunnen werken. Dit is een vast omlijnd traject met een vaste prijs.
Je krijgt een helder oordeel: overnemen, gedeeltelijk hergebruiken of opnieuw beginnen. Als opnieuw bouwen op termijn goedkoper is, zeggen we dat. Dat is geen beleefdheid, het scheelt je later een traject dat toch vastloopt.
We trekken de techniek naar actuele versies, lossen de openstaande problemen op en bouwen af wat er nog miste. Daarna nemen we het structurele onderhoud over, zodat je niet over twee jaar opnieuw een inhaalslag betaalt.
Gaat het specifiek om een mobiele app, dan lees je de uitgebreide versie van dit verhaal in ons artikel over een app laten overnemen van een ander bureau.
Een AI-prototype bouwen is sinds kort makkelijk. Er productiesoftware van maken is dat niet. Het verschil zit bijna nooit in het AI-model zelf, maar in alles eromheen.
Wat wij in de praktijk als eerste toevoegen: inloggen en rechten, foutafhandeling als het model iets raars teruggeeft, logging zodat je kunt zien wat er gebeurd is, een rem op de kosten per gebruiker, en een plek waar iemand zonder technische kennis het kan beheren. Plus de saaie vraag die zelden gesteld is: wat mag er wel en niet met deze data gebeuren.
Onze mening, en die is niet populair: de meeste zelfgebouwde AI-prototypes hoeven niet opnieuw. De prompt-logica en de interface zijn vaak prima. Wat ontbreekt is het gedeelte dat je pas mist als er echte gebruikers op zitten. Dat stuk is goed te bouwen bovenop wat er al staat.
Wij bouwen AI niet los van bestaande systemen. Bij een klant in de technische handel analyseerden we 59.000 orders en 57.000 gesprekslogs, en daaruit kwamen 16 concrete AI-toepassingen. Daarvan draait er inmiddels een zoekfunctie in natuurlijke taal in het platform dat ze dagelijks gebruiken. Lees ook hoe wij AI integreren in bestaande software.
Geen hypothetische voorbeelden. Twee projecten die we daadwerkelijk hebben overgenomen van een ander of uit een verouderde situatie hebben getrokken.
Een app die door een ander bureau was gebouwd en daarna niet meer werd bijgewerkt. De codebase liep zo ver achter dat Apple en Google geen nieuwe releases meer accepteerden.
Wij hebben de techniek naar actuele versies getrokken, nieuwe content en functionaliteit toegevoegd en draaien sindsdien het structurele onderhoud. De app staat gewoon weer in beide stores.
Begonnen in 2016 met onderhoud op een verouderde Access-database. Via een migratie naar .NET en SQL Server staat er nu een platform met 15 modules waar 5.000 klanten en 2.200 producten in beheerd worden.
In 2026 is alles naar Microsoft Azure verhuisd, inclusief 22 jaar aan historische data. Een samenwerking die sinds 2016 stap voor stap is opgebouwd vanuit iets dat al bestond. Bekijk het klantverhaal.
Appec werkt al jaren intensief met ons mee aan het platform dat ons hele bedrijf dagelijks draait.
Ze investeren in de relatie met klanten, denken proactief mee, stellen oplossingen voor, zijn altijd bereikbaar en komen afspraken na. Een aanrader voor klanten die een doordachte softwarepartner zoeken.
Appec zit vol met talentvolle programmeurs die actief met ons meedenken, communicatief zeer prettig werken en ook nog eens echte kwaliteit leveren.
Dat hangt af van de staat van de code, en daarom begint elk traject met de code-scan. Pas daarna kunnen we een serieus bedrag noemen. Iedereen die dat wel meteen doet, gokt.
De factoren die het bedrag bepalen:
Een overname is bijna altijd goedkoper dan volledig opnieuw bouwen, zolang de bestaande code een werkbare basis vormt. Je betaalt dan voor begrijpen en bijwerken, niet voor alles opnieuw maken.
Voor het onderhoud daarna rekenen we jaarlijks 15 tot 20 procent van het bouwbudget. Een basislaag onderhoud ligt tussen de 500 en 1.500 euro per maand, afhankelijk van de omvang en hoe kritisch het systeem is. Meer weten over kosten van nieuwbouw? Kijk op app laten maken kosten of gebruik onze kostencalculator.
Niet elke overname is verstandig. Als de code zo verwaarloosd is dat we eerst weken bezig zijn om te begrijpen wat er staat, en daarna alsnog het meeste moeten vervangen, dan is opnieuw bouwen goedkoper. Datzelfde geldt als er een techniek is gebruikt die niet meer ondersteund wordt en waar geen migratiepad voor is.
We zeggen dat gewoon. Ook al betekent het dat er in eerste instantie minder werk voor ons uit komt.
Stuur ons de situatie
hallo@appec.nlEen paar regels over wat er ligt en wat er stilstaat is genoeg. Je krijgt binnen een werkdag antwoord.
Of bel gewoon even
024 202 243 5Je krijgt meteen iemand aan de lijn die de code begrijpt, geen accountmanager.
Soms wel, maar het is een stuk lastiger. We zoeken eerst uit of de code alsnog opvraagbaar is bij de vorige partij, of er nog een repository of back-up bestaat en of er iets te reconstrueren valt uit wat er draait. Lukt dat niet, dan is nieuwbouw meestal de verstandigste route. Dat horen we liever eerst uit dan dat we het gokken.
Dat hangt af van wat de code-scan oplevert. Een nette applicatie die alleen bijgewerkt moet worden naar actuele versies kost weken. Een verwaarloosde codebase waar we eerst in moeten zien te komen, kost langer, omdat we niets veilig kunnen aanpassen voordat we begrijpen wat er staat. Na de scan weet je waar je aan toe bent.
Dan zeggen we dat, met de reden erbij. Soms is de code zo slecht dat repareren duurder uitpakt dan opnieuw beginnen. Je hebt in dat geval nog steeds iets nuttigs: een onafhankelijk oordeel over wat je bezit en wat het waard is. Daar kun je ook mee naar een andere partij.
Ja. Dat is een groeiende categorie. Vaak is de basis prima en ontbreekt vooral het gedeelte dat je nodig hebt zodra er echte gebruikers op zitten: inloggen en rechten, foutafhandeling, logging, kostenbeheersing en beheer. We bouwen dat bovenop wat er al staat, en gooien zelden alles weg.
Native iOS- en Android-apps, hybride apps in Flutter, webapplicaties, klantportalen en maatwerksystemen. We werken dagelijks met Swift, Kotlin, .NET, React en Azure. Kom je met iets in een techniek die we niet doen, dan zeggen we dat meteen in plaats van het te leren op jouw kosten.
Toegang tot de broncode, de app-store-accounts en de server of hosting. Verder alles wat er aan documentatie is, ook als het rommelig is. Ontbreekt er iets, dan is dat geen blokkade maar wel informatie: het is meestal het eerste wat we gaan regelen.
Nee. Je bent en blijft eigenaar van je code en je accounts. We leveren alles zo op dat een andere partij het kan overnemen, want precies dat probleem lossen we hier op. Een leverancier die je gijzelt met een codebase is nou net de reden dat mensen ons bellen.
Stuur een paar regels over wat er ligt en wat er stilstaat. We laten je weten of overnemen verstandig is, en zo niet, wat dan wel.
Of het nu een app is, een web platform of iets waar nog geen naam voor bestaat.
