Kosten app laten maken wat betaal je echt in 2026

Een app laten maken kost in Nederland meestal €15.000 tot €75.000 voor een eerste maatwerkoplossing. Een beperkte MVP zit vaak tussen €15.000 en €40.000, terwijl een volwassen B2B-app meestal uitkomt op €40.000 tot €120.000, en dat verschil wordt bijna altijd verklaard door uren x uurtarief x teammix.

Veel MKB-beslissers zitten op dit moment in precies dezelfde situatie. Er ligt een idee op tafel, de interne processen piepen, klanten verwachten een portaal of mobiele app, en dan komen er drie offertes binnen die totaal niet op elkaar lijken. De ene partij noemt een bedrag dat nog haalbaar voelt, de andere zit daar ver boven, en een derde offert iets ertussenin maar blijft vaag over wat wel en niet inbegrepen is.

Die verwarring is logisch. De kosten app laten maken ontstaan niet uit één vaste prijslijst, maar uit een optelsom van keuzes. Eén platform of twee. Alleen een gebruikerslogin of ook rollen en rechten. Een losse app of een app die moet praten met ERP, CRM of boekhouding. Zonder die bril lijken offertes willekeurig. Met die bril wordt zichtbaar waar elke euro naartoe gaat.

Maandagochtend. Er liggen drie offertes op tafel voor ogenschijnlijk dezelfde app. De goedkoopste zit rond een paar tientjes per uur werk, de duurste komt bijna op het drievoudige uit, en beide leveranciers zeggen dat ze precies hebben begrepen wat u nodig heeft.

Dat voelt tegenstrijdig, maar is meestal goed te verklaren.

Een app-offerte is zelden alleen een prijs voor “de app”. Het is een prijs voor een gekozen scope, een gekozen technische aanpak en een gekozen team. Als die drie per leverancier verschillen, krijgt u geen drie prijzen voor hetzelfde product, maar drie verschillende bouwplannen voor iets dat toevallig dezelfde naam heeft.

Neem een groothandel die zegt: “We willen een app waarmee klanten orders kunnen bekijken en opnieuw kunnen plaatsen.” Dat klinkt concreet. Toch kan leverancier A daar een mobiele voorkant in zien. Leverancier B rekent ook een back-end, voorraadkoppeling en beheeromgeving mee. Leverancier C voegt alvast rollen, notificaties en foutafhandeling toe, zodat de app later niet opnieuw opengebroken hoeft te worden.

Dan loopt de prijs snel uiteen.

De bandbreedte in offertes ontstaat dus niet alleen door uurtarief, maar vooral door wat er wel en niet in de doos zit. Een partij offert het casco. Een andere partij rekent ook de leidingen, meterkast en afwerking mee. Van buiten lijkt het hetzelfde huis. Tijdens de bouw blijkt pas hoeveel verschil daaronder zit.

Volgens deze Nederlandse prijsbron over app-kosten vallen maatwerkapps in Nederland grofweg uiteen van kleine MVP's tot veel zwaardere B2B-oplossingen met koppelingen en beheer. Die brede vork is logisch zodra u offertes terugbrengt naar uren maal uurtarief maal teammix.

Veel MKB-beslissers kijken eerst naar het eindbedrag. Voor vergelijking helpt een andere vraag beter: hoeveel uren zitten hierachter, en van wie?

Een eenvoudige offerte kan vooral ontwikkeluren bevatten. Een uitgebreidere offerte verdeelt het werk over UX, back-end, front-end, QA, projectleiding en soms architectuur. Dat maakt de offerte hoger, maar ook duidelijker. U betaalt dan niet alleen voor code schrijven, maar ook voor keuzes vooraf, testwerk achteraf en minder herstelwerk na livegang.

Een ruwe berekening maakt dit tastbaar. Stel dat bureau A uitgaat van 160 uur met vooral één developer. Bureau B plant 260 uur in, verdeeld over een developer, designer, tester en projectmanager. Dan vergelijkt u geen dure partij met een goedkope partij. U vergelijkt een basisbouw met een bouw inclusief controle, afstemming en afwerking.

Zoals dit overzicht van uren en tarieven voor app-ontwikkeling laat zien, worden app-kosten in de praktijk vaak herleid tot ontwikkeluren en uurtarieven. Dat helpt, maar alleen als u ook ziet welke uren ontbreken. Geen QA in de offerte betekent niet dat testen gratis is. Het betekent meestal dat testen later alsnog ergens moet gebeuren.

De grootste prijsverschillen zitten vaak niet in grote koppen, maar in kleine zinnen zoals:

• “koppelingen op nacalculatie”
• “publicatie in stores niet inbegrepen”
• “exclusief beheeromgeving”
• “uitgaande van aangeleverde designs”
• “foutafhandeling externe API buiten scope”

Dat zijn geen details. Dat zijn kostenposten.

Een login-scherm lijkt bijvoorbeeld klein. Maar als gebruikers ook wachtwoorden moeten resetten, rechten moeten krijgen, via e-mail bevestigd moeten worden en veilig moeten inloggen op meerdere apparaten, groeit één “feature” uit tot een hele set bouwuren. Hetzelfde geldt voor een koppeling met ERP of CRM. Op papier is het één regel. In de praktijk vraagt het afstemming, testen, foutscenario's en vaak extra beheer.

Een bruikbare vuistregel is simpel: trek elke offerte uit elkaar alsof u een aannemersbegroting leest. Hoeveel schermen worden echt gebouwd? Welke koppelingen zijn inbegrepen? Zit store-publicatie erbij? Is testen apart benoemd? Is onderhoud al meegenomen of begint dat pas na livegang?

Pas dan ziet u waar elke euro naartoe gaat.

Wie offertes vergelijkt zonder scope, uren en teammix naast elkaar te zetten, vergelijkt vooral aannames. Wie dat wel doet, ziet meestal snel waarom de ene offerte lager oogt, maar later duurder kan uitpakken.

Een app bouwen lijkt sterk op een huis bouwen. Een huis lijkt van buiten soms simpel, maar de kosten zitten niet alleen in de muren. Fundering, leidingen, elektra, afwerking, toezicht en oplevering bepalen samen de prijs. Bij software werkt dat net zo.

Het casco van een app is de basisstructuur. Denk aan navigatie, schermindeling, loginflow en de technische opzet. Zonder goed casco kan een app wel werken, maar wordt uitbreiden duur en foutgevoelig.

De installaties zijn de motor achter de schermen. Daar zitten de back-end, database, API-koppelingen, notificaties en rechtenstructuur. Juist hier onderschatten veel opdrachtgevers de inspanning. Een knop “bestelling plaatsen” lijkt klein, maar als die knop voorraad moet controleren, gegevens moet wegschrijven en fouten netjes moet afhandelen, lopen de uren snel op.

De afwerking is wat gebruikers direct zien en voelen. UX/UI, animaties, states voor foutmeldingen, loading-situaties, toegankelijkheid en finetuning. Dit is niet alleen cosmetisch. Slechte afwerking zorgt voor supportvragen, afhakers en extra herstelwerk na livegang.

Kernprincipe: de prijs van een app is geen optelsom van schermen, maar van uren x tarief x risico.

In Nederland ligt het uurloon voor app-ontwikkeling vaak tussen €75 en €150 per uur, waarbij bureaus doorgaans hoger zitten dan freelancers. Gespecialiseerde rollen zoals security, data of UX kunnen daarboven uitkomen. Daardoor wordt de prijs van een app niet primair bepaald door het aantal schermen, maar door de disciplines in de keten: architectuur, back-end, UX/UI, QA, projectmanagement en onderhoud, zoals beschreven in deze uitleg over maatwerk app-kosten.

Een scherm met alleen tekst is goedkoop. Een scherm met authenticatie, autorisaties, synchronisatie en foutafhandeling is dat niet.

Fixed price past bij een strak afgebakende scope. Handig als de eisen helder zijn en er weinig onzekerheid zit in koppelingen of gebruikersflows. Het risico is dat ontbrekende aannames later als meerwerk terugkomen.

Time and material past beter als het product nog ontdekt moet worden. De opdrachtgever betaalt dan voor bestede tijd. Dat geeft flexibiliteit, maar vraagt strakke sturing en transparante rapportage.

Gefaseerd met mijlpalen is voor veel MKB-bedrijven het meest werkbaar. Eerst een compacte basisversie, daarna uitbreiden op basis van gebruik en feedback. Dat voorkomt dat het hele budget vastzit in aannames die later niet blijken te kloppen.

Niet elke app hoort in dezelfde prijsklasse. De snelste manier om grip te krijgen op kosten app laten maken is het idee eerst in een type te plaatsen. Meestal valt een plan in één van drie groepen: MVP, standaard B2B-app of complexe enterprise-app.

Een MVP is de kleinste versie die een echt probleem oplost. Denk aan één platform, een basislogin, 5 tot 8 kernschermen en beperkte workflowlogica. Vaak gaat het om een eerste versie waarmee een bedrijf intern kan testen of klanten kan laten starten zonder direct alle randzaken mee te bouwen.

Nederlandse marktbronnen noemen voor eenvoudige MVP's en gemiddelde apps vaak een bereik van ongeveer €25.000 tot €75.000, waarbij eenvoudige MVP's lager kunnen starten en een eerste werkende basisversie vaak al 120 tot 400 ontwikkeluren vraagt. Gefaseerd bouwen met een duidelijke MVP-fase wordt daarbij als financieel efficiënt gezien, volgens dit overzicht over app-kosten en MVP-keuzes. Wie een idee nog moet valideren, heeft vaak meer aan een scherpe eerste versie dan aan een complete maar dure eerste release. Een praktisch vertrekpunt staat ook in deze gids over een MVP ontwikkelen.

Een standaard B2B-app gaat verder dan een proof of concept. Dan komen meerdere gebruikersrollen, 10 tot 20 schermen, API-koppelingen, push-notificaties, admin-beheer en publicatie in de stores in beeld. Dat is het type app dat niet alleen iets demonstreert, maar een dagelijks proces ondersteunt.

Hier verschuift het werk van “bouwen wat zichtbaar is” naar “organiseren wat betrouwbaar moet draaien”. Rechten, logging, foutmeldingen, beheer en acceptatietesten nemen dan een groter deel van de planning in.

Enterprise-territorium begint meestal zodra meerdere platforms, realtime data, betalingen, chat, geavanceerde workflows of white-label en multi-tenant architectuur nodig zijn. Dat zijn geen losse extra's. Elke toevoeging trekt nieuwe eisen mee op het gebied van beveiliging, testwerk, schaalbaarheid en beheer.

De belangrijkste les uit deze vergelijking is eenvoudig. Extra functionaliteit telt niet lineair op. Een extra scherm is vaak nog te overzien. Een extra scherm dat moet synchroniseren met externe systemen, rollen moet respecteren en ook offline of fouttolerant moet werken, is een heel andere kostenpost.

Twee bedrijven vragen allebei “een app” aan. Het ene krijgt een offerte van €18.000, het andere van €65.000. Het verschil zit vaak minder in het scherm dat je ziet, en meer in de route erachter: voor welk platform bouw je, hoeveel onderdelen moeten apart getest worden, en hoeveel specialisten zijn erbij nodig.

Platformkeuze werkt als de keuze tussen één winkel openen of direct drie vestigingen runnen. De kern van je dienst blijft hetzelfde, maar de inrichting, controle en dagelijkse operatie worden groter.

Native iOS en Android betekent meestal de meeste vrijheid per platform. Je kunt devicefuncties nauwkeuriger gebruiken en de ervaring strakker afstemmen op iPhone en Android. De keerzijde is duidelijk: meer apart werk in bouw, test en releasebeheer.

Cross-platform is vaak aantrekkelijk als dezelfde app op iOS en Android moet draaien en de functionaliteit niet extreem platformspecifiek is. Je deelt dan een deel van de code. Dat bespaart geregeld uren, maar niet alles. Inloggen, push-notificaties, permissies, build-problemen en store-publicatie vragen nog steeds platformspecifieke aandacht.

Webapp of PWA past vaak beter bij interne tools, klantportalen en processen die vooral via browsergebruik lopen. Je slaat app store-trajecten soms over en updates zijn sneller uit te rollen. Voor een buitendienstapp met veel devicefuncties of zware offline-eisen is dat weer minder vanzelfsprekend.

De praktische les is simpel. Elk extra platform voegt niet alleen schermen toe, maar ook controlewerk.

Zodra je uren aan functies koppelt, wordt prijs minder abstract. Een login lijkt klein. Maar daaronder zitten vaak registratie, wachtwoordreset, sessiebeheer, foutmeldingen, rechten en testgevallen. Hetzelfde geldt voor een dashboard, een koppeling of een notificatie.

Daarom helpt het om een offerte terug te rekenen naar drie bouwblokken:

• Bouwuren: hoeveel tijd gaat naar schermen, logica, koppelingen en testen
• Uurtarief: welk tarief geldt per rol
• Teammix: hoeveel werk ligt bij junior, medior, senior, designer, tester of projectlead

Een voorstel van 150 uur klinkt scherp, totdat je uitrekent wat erin moet passen. Stel dat je app een login, 8 tot 10 schermen, een backoffice-koppeling, push-notificaties en publicatie in stores nodig heeft. Dan is 150 uur vaak te krap voor een team dat ook netjes test, feedbackrondes verwerkt en de release voorbereidt.

Een voorstel van 300 tot 400 uur voor zo'n compacte maar zakelijke eerste versie is vaak beter te plaatsen. Niet omdat elk project zoveel tijd nodig heeft, maar omdat de offerte dan ruimte laat voor echt projectwerk in plaats van alleen code tikken.

Een lage offerte betekent vaak dat uren ergens zijn weggelaten. Meestal bij testen, koppelingen, projectafstemming of releasewerk.

Veel beslissers kijken eerst naar het hoogste uurtarief op de offerte. Begrijpelijk, maar dat getal op zichzelf zegt weinig. De echte vraag is: wie doet welk werk?

Een app bouwen met alleen seniors is duur. Een app bouwen met alleen goedkope uren wordt vaak later duurder, omdat keuzes opnieuw moeten worden gemaakt of fouten pas laat boven water komen. De gezondste opzet is meestal een teammix.

Bijvoorbeeld:

• een designer werkt de gebruikersstroom en schermen uit
• een medior developer bouwt het grootste deel van de standaardfunctionaliteit
• een senior developer of architect pakt technische keuzes, code reviews en lastige koppelingen op
• een tester of QA-rol controleert of alles werkt op verschillende apparaten en scenario's
• een projectlead bewaakt planning, scope en besluitvorming

Dat is vergelijkbaar met een verbouwing. Je laat een architect niet de hele dag plinten zagen, maar je wilt die architect wel laten meekijken naar fundering en constructie.

Voor MKB-offertes is het nuttig om niet alleen naar totaalbedrag te kijken, maar naar verdeling. Een appbudget gaat meestal niet volledig naar “programmeren”. Een flink deel verdwijnt in werk dat pas zichtbaar wordt als je het project ontleedt:

• functioneel meedenken en specificeren
• UX en schermontwerp
• front-end bouw
• back-end of API-werk
• koppelingen met bestaande systemen
• testwerk op meerdere apparaten
• releasevoorbereiding voor iOS, Android of browser
• projectmanagement en afstemming

Daarom kunnen twee offertes met hetzelfde uurtarief toch ver uit elkaar liggen. De ene leverancier rekent alleen bouwuren voor het zichtbare product. De andere neemt ook reviewrondes, testwerk en releasebegeleiding mee.

Ook het type partij speelt mee. Een freelancer heeft vaak een lager overheadniveau en kan aantrekkelijk zijn voor een kleine, duidelijke scope. Een bureau rekent meestal meer per uur, maar daar krijg je vaak extra rollen voor terug, zoals design, QA, architectuur en continuïteit bij uitval of vakantie.

Onderstaande video helpt om die afweging visueel te plaatsen.

Een offerte wordt dus pas echt vergelijkbaar als je drie vragen stelt: voor hoeveel platforms is gerekend, hoeveel uren zitten per onderdeel in de raming, en welke teamrollen zijn daarin opgenomen. Zonder dat detail vergelijk je totaalbedragen, geen aanpakken.

De bouwprijs is zelden het hele verhaal. Veel budgetten lopen niet uit tijdens het programmeren, maar pas ná livegang. Dan blijken koppelingen onderhoud te vragen, stores reviews te vertragen en externe systemen onverwacht te veranderen.

Een app die praat met ERP, CRM, webshop of boekhouding is niet klaar zodra de eerste data loopt. API's wijzigen, authenticatie verloopt, velden veranderen en foutafhandeling moet worden bijgewerkt. Dat geldt ook voor push-notificaties, betaalproviders en single sign-on.

Voor MKB-bedrijven is dit vaak het moment waarop een “goedkope” offerte duur wordt. De bouw leek compact, maar het beheer van de keten zat er niet in.

Publicatie in de App Store en Google Play vraagt meer dan een upload. Beoordelingen, releasevoorbereiding, screenshots, privacy-informatie en afwijzingen kunnen tijd kosten. Daarna begint de operationele fase pas echt.

Denk aan deze posten:

• Hosting en runtime: servers, databases, opslag en achtergrondtaken moeten stabiel draaien.
• Monitoring en logging: zonder foutregistratie ziet een team storingen vaak pas als gebruikers gaan mailen.
• Updates van frameworks en libraries: mobiele besturingssystemen en afhankelijkheden blijven bewegen.
• Support en bugfixes: ook een goede release levert vragen en randgevallen op.

Voor onderhoud na livegang is het slim om vooraf een apart budget te reserveren. Wie die kosten concreter wil doorrekenen, vindt extra context in deze uitleg over onderhoud van maatwerksoftware.

Onderhoud is geen luxe. Het is de prijs van bedrijfscontinuïteit.

Bij apps met webcomponenten, portalen of PWA's heeft performance direct invloed op gebruikservaring en beheerlast. Een trage voorkant zorgt voor meer afhakers, meer supportvragen en meer optimalisatiewerk achteraf. Voor technische SEO en laadsnelheid meldt een Nederlandse statistiekbron dat de gemiddelde Largest Contentful Paint van .nl-websites 2,8 seconden bedraagt, boven de Google-drempel van 2,5 seconden, en dat een andere Nederlandse performancebron een mediane mobiele laadtijd van 3,4 seconden noemt in deze verzameling technische SEO-statistieken.

Dat is relevant omdat snelheid zelden “later nog even” wordt opgelost zonder extra kosten. Performance moet onderdeel zijn van ontwerp, front-endkeuzes en testwerk.

Abstracte prijsbandbreedtes worden pas bruikbaar als een bedrijf ze kan narekenen. Daarvoor helpt één simpele methode: schat eerst de uren, bepaal daarna het waarschijnlijke tarief van de teammix, en kijk pas dan naar het totaal.

Een compacte app met beperkte scope kan vaak met een kleine teammix worden opgepakt. Zodra koppelingen, rechten, QA en store-publicatie erbij komen, schuift ook de bezetting op.

De infographic hierboven laat voorbeeldberekeningen zien. Die getallen zijn illustratief en helpen vooral om offertes te ontleden in werkpakketten. Wie vooraf zelf wil rekenen, kan daarvoor ook een kostenraming template gebruiken.

Niet elke offerte verdient dezelfde vragen. Deze punten maken snel zichtbaar of een voorstel compleet is of vooral aantrekkelijk oogt.

• Scope en aannames: staat precies beschreven welke schermen, rollen, koppelingen en platformen inbegrepen zijn?
• Teammix en tariefopbouw: is zichtbaar wie UX, development, QA en projectsturing doet, of staat er alleen één totaalbedrag?
• Testen en acceptatie: bevat de offerte tijd voor QA, bugfixing en acceptatierondes?
• Publicatie en livegang: zitten store-publicatie, releasebegeleiding en eventuele afwijzingen in de prijs?
• Onderhoud en eigendom: is duidelijk wie de code bezit, hoe support loopt en welk meerwerktarief geldt?

Een bruikbare offerte beschrijft niet alleen wat gebouwd wordt, maar ook wat bewust níet gebouwd wordt.

De goedkoopste manier van bouwen is zelden “alles in één keer doen”. Voor de meeste MKB-situaties werkt dit beter:

1. Start met een afgebakende kern Alleen de flow die direct waarde levert. Niet meteen elk denkbaar scenario.
2. Hergebruik waar dat kan Standaardcomponenten voor login, dashboards of notificaties besparen tijd, zolang ze echt passen.
3. Leg acceptatiecriteria vroeg vast Een scherm is niet “ongeveer goed”. Een scherm is klaar als het voldoet aan concrete voorwaarden.
4. Reserveer ruimte voor integraties en nazorg Juist daar ontstaan de meeste verrassingen.

Wie op deze manier rekent, onderhandelt niet meer op gevoel maar op inhoud.

Maandag vraagt sales om een extra veld in het offerteproces. Op papier lijkt dat een kleine wijziging. In een verouderde app kost zo'n aanpassing soms geen 6 uur, maar 18 uur. Eerst uitzoeken waar de validatie zit, dan een oude koppeling herstellen, daarna bugs wegwerken die pas bij testen zichtbaar worden. Dan wordt doorbouwen duur, ook als de offerte voor “nieuwbouw” hoger oogt.

De kernvraag is daarom niet alleen: wat kost opnieuw bouwen? De betere vraag is: hoeveel herstelwerk betaal je inmiddels verstopt mee in elke nieuwe feature?

Een bestaande app blijft vaak rendabel zolang het team voorspelbaar kan werken. Een scherm aanpassen kost dan ongeveer de uren die je verwacht. Zodra elke wijziging extra speurwerk vraagt, betaal je een technische rente. Net als bij een pand met achterstallig onderhoud lijkt de maandlast nog beheersbaar, tot elke kleine verbouwing eerst leidingen, elektra en fundering raakt.

Dat zie je meestal op drie plekken terug:

• Features kosten structureel meer uren dan bij vergelijkbare nieuwe bouw
• Bugfixes raken onverwacht andere onderdelen
• Releases vragen veel handmatig testwerk omdat vertrouwen in de code ontbreekt

Een praktisch rekenvoorbeeld maakt dat verschil zichtbaar.

Stel: je wilt de app komend jaar uitbreiden met 6 middelgrote features. Bij een gezonde codebasis kost zo'n feature gemiddeld 35 ontwikkeluren, 8 uur QA en 4 uur projectafstemming. Met een teammix van developer €110 per uur, QA €85 en projectlead €95 kom je uit op ongeveer:

• Development: 6 x 35 uur x €110 = €23.100
• QA: 6 x 8 uur x €85 = €4.080
• Projectlead: 6 x 4 uur x €95 = €2.280

Totaal: €29.460

Bij een verouderde app komt daar vaak 20 tot 40 procent herstel- en uitzoekwerk bovenop. Neem voorzichtig 25 procent extra ontwikkeltijd en 25 procent extra testtijd:

• Extra development: 52,5 uur x €110 = €5.775
• Extra QA: 12 uur x €85 = €1.020

Dan stijgt hetzelfde jaarbudget naar €36.255, zonder dat je méér functionaliteit krijgt. Je betaalt alleen voor de weerstand van het bestaande systeem.

Herontwikkeling klinkt duur omdat het bedrag eerder op tafel komt. Toch kan het over 12 tot 24 maanden goedkoper zijn als de huidige app elke wijziging vertraagt.

Een nuchtere vergelijking helpt.

Scenario A: doorbouwen op oude basis

• Technische opschoning per nieuwe feature inbegrepen als verborgen meerwerk
• 6 features per jaar
• Totaal jaar 1: ongeveer €36.255
• Extra risico: hogere kans op regressie, langere releasecycli, meer afhankelijkheid van oud framework of vorige leverancier

Scenario B: eerst audit, daarna gefaseerde herbouw

• Technische audit en architectuurscan: 40 uur x €120 = €4.800
• Herbouw kernmodules, bijvoorbeeld login, gebruikersrollen, dashboard en API-laag: 300 uur x €120 = €36.000
• QA en releasebegeleiding: 70 uur x gemiddeld €90 = €6.300

Totaal initiële investering: €47.100

Dat is in jaar 1 meer geld. Maar nieuwe features landen daarna vaak weer tegen normale uren. Als je in jaar 2 opnieuw 6 features bouwt tegen het gezondere ritme van €29.460 in plaats van €36.255, begint het verschil al te schuiven. En dat is nog zonder de kosten van spoedfixes, releaseproblemen en omzetverlies door instabiliteit mee te rekenen.

Volledig opnieuw bouwen in één keer is zelden verstandig als de huidige operatie moet doorlopen. Een gefaseerde aanpak werkt meestal beter, juist voor MKB-bedrijven die geen maanden zonder zekerheid willen zitten.

Een bruikbare volgorde ziet er vaak zo uit:

1. Code-audit en afhankelijkheden in kaart brengen Denk aan frameworkversies, libraries, hosting, CI/CD, database-structuur en koppelingen met CRM, ERP of betaalprovider.
2. Bepalen wat je laat staan en wat je vervangt Soms is de backend nog bruikbaar, maar is de mobiele schil verouderd. Soms geldt precies het omgekeerde.
3. Eerst de onderdelen vervangen met de hoogste onderhoudslast Bijvoorbeeld authenticatie, notificaties of een fragiele API-koppeling.
4. Tijdelijk parallel draaien waar nodig Oude en nieuwe modules bestaan dan even naast elkaar, zodat de operatie niet stilvalt.

Hier gaat vaak geld verloren in offertes die alleen “herontwikkeling” als totaalpost noemen. Vraag liever welk deel audit is, welk deel migratie is, hoeveel uur naar datamapping gaat, en hoeveel tijd gereserveerd is voor regressietesten. Dan zie je waar elke euro naartoe gaat.

Bij doorbouwen én herbouwen zitten de verrassingen meestal niet in het schermontwerp, maar in de randen eromheen.

Denk aan:

• aanpassen van API-koppelingen met boekhouding, voorraad of planning
• vervangen van verouderde libraries of SDK's
• migreren van gebruikersdata en rechtenstructuren
• opnieuw inrichten van buildstraat en store-publicatie
• extra testwerk op oude toestellen of verschillende OS-versies

Vooral app stores worden vaak vergeten. Een herbouw kan betekenen dat certificaten, provisioning profiles, package names, push-configuratie of review-eisen opnieuw goed gezet moeten worden. Dat zijn geen losse details. Het zijn uren van developers en QA die gewoon op de factuur verschijnen.

Doorbouwen is meestal goedkoper als de app nog voorspelbaar uitbreidbaar is en nieuwe functionaliteit geen structurele hersteluren veroorzaakt.

Herontwikkeling is vaak goedkoper als je per feature steeds opnieuw betaalt voor oude fouten, verouderde techniek en fragiele koppelingen.

MG Software bouwt maatwerksoftware, webapplicaties, mobiele apps, koppelingen en herontwikkelingstrajecten voor organisaties die grip willen op kosten, scope en onderhoud. Voor bedrijven die de kosten app laten maken eerst helder willen krijgen, kan een technisch plan met MVP-afbakening, integratie-inschatting en onderhoudsaanpak veel onnodige herbouw voorkomen. Meer informatie staat op MG Software.