Applicatie laten maken in 2026: het volledige traject

Een ondernemer ziet het probleem meestal al maanden voordat er over software wordt gesproken. Medewerkers voeren dezelfde gegevens in meerdere systemen in, klanten bellen over de status van een order en een spreadsheet bepaalt nog altijd welke voorraad beschikbaar is. Dan ontstaat al snel het idee om een applicatie te laten maken die alles oplost.

Dat idee kan juist zijn, maar het kan ook een dure omweg worden. Nederlandse bedrijven zijn digitaal volwassen: in 2025 haalde 89% van de bedrijven het basisniveau van digitale intensiteit, tegenover 83% in 2023, terwijl het EU-gemiddelde op 71% lag, zo blijkt uit de cijfers van het CBS over digitalisering. De vraag is daardoor niet meer óf software nodig is, maar welke oplossing het proces werkelijk verbetert.

De eerste vraag die een MKB-bedrijf moet stellen, is niet welke programmeertaal of leverancier nodig is. De betere vraag luidt: is maatwerksoftware wel het juiste antwoord op het probleem?

Een CRM, ERP-pakket, SaaS-platform, chatbot, PWA of goed ingerichte website kan een bedrijfsproces soms sneller ondersteunen dan een nieuwe applicatie. Een organisatie die alleen een formulier, planningsoverzicht of eenvoudige klantomgeving nodig heeft, hoeft niet automatisch een traject met een App Store-release te starten. Een recente Nederlandstalige analyse over een app laten maken voor het MKB benoemt dat een aanzienlijk deel van de pseudo-app-vraag zonder App Store-traject kan worden opgelost, bijvoorbeeld met een PWA, CRM of website-first aanpak.

Maatwerk is een slechte keuze wanneer de wens vooral voortkomt uit persoonlijke voorkeur. Dat geldt bijvoorbeeld voor een eenmalige interne wens, een proces dat maar zelden voorkomt of een functie die een SaaS-leverancier al voor €50 per maand aanbiedt. In zulke gevallen betaalt een organisatie niet alleen voor software, maar ook voor ontwerp, testen, hosting, beheer en toekomstige wijzigingen.

Een applicatie laten maken is ook onverstandig wanneer niemand het probleem kan omschrijven in termen van tijdverlies, fouten, omzet, klanttevredenheid of operationeel risico. “Een modern platform lijkt ons handig” is geen businesscase. “Orderinvoer kost dagelijks veel handwerk en veroorzaakt fouten in de boekhouding” is dat wel.

Praktische regel: kies maatwerk pas wanneer standaardsoftware aantoonbaar tekortschiet én het betreffende proces bedrijfskritisch, onderscheidend of structureel schaalbaar is.

Maatwerk verdient serieuze aandacht wanneer een bedrijf eigen machines, specialistische workflows of gevoelige gegevens moet koppelen. Hetzelfde geldt voor een uniek klantproces dat niet past binnen de configuratie van een bestaand pakket. Denk aan een technische groothandel die voorraad uit meerdere bronnen combineert, een servicebedrijf met complexe planningsregels of een organisatie die een klantportaal nodig heeft met eigen autorisaties en datastromen.

De Nederlandse markt is klaar voor zulke oplossingen. In 2023 gebruikte 73,9% van de MKB-bedrijven minstens één geavanceerde technologie, zoals AI, cloud computing of data-analyse. In 2024 gebruikte 21,9% van alle MKB-bedrijven AI, terwijl 68% cloud computing toepaste en 25% via e-commerce verkocht, volgens de overheidsinformatie over digitale toepassingen in het bedrijfsleven.

Vanaf het eerste gesprek tot livegang duurt een serieus traject vaak drie tot twaalf maanden. Daarbovenop komt een doorloopbudget dat al snel boven €25.000 uitkomt. Wie die tijd en verantwoordelijkheid niet kan vrijmaken, doet er verstandig aan eerst een bestaande oplossing te configureren.

Een goede offerte begint niet bij de leverancier, maar bij de opdrachtgever. Wie drie bureaus benadert met de zin “bouw een applicatie voor voorraad en orders”, krijgt drie verschillende interpretaties en daarmee drie onvergelijkbare offertes.

Begin met één zin die het bedrijfsprobleem beschrijft. Daarna vertalen betrokken medewerkers die zin naar user stories. Een regionale groothandel in sanitair kan bijvoorbeeld starten met: “Medewerkers moeten voorraad en orders vanuit één werkproces kunnen beheren.”

Die wens is nog geen requirement. De uitwerking kan bestaan uit:

• Barcode-scanning: een magazijnmedewerker scant een product en ziet direct de beschikbare voorraad.
• Orderstatus: verkoopmedewerkers zien welke orders nieuw, gereserveerd, verzonden of geblokkeerd zijn.
• Klantportal: klanten bekijken orderinformatie zonder interne systemen te benaderen.
• Boekhoudkoppeling: factuur- en klantgegevens gaan gecontroleerd naar het boekhoudpakket.
• Rechtenstructuur: magazijn, verkoop en management krijgen elk een passend toegangsniveau.

Groepeer deze onderdelen vervolgens met MoSCoW: Must have, Should have, Could have en Won't have for now. Die laatste categorie is belangrijk. Zonder expliciete uitsluiting verhuist ieder aantrekkelijk idee naar de eerste release.

De opdrachtgever moet één Product Owner aanwijzen met beslissingsbevoegdheid. Die persoon verzamelt feedback, prioriteert de backlog, accepteert functionaliteit en voorkomt dat vijf afdelingen tegelijk de richting bepalen.

Zonder Product Owner ontstaat scope-creep. Een developer bouwt een scherm, een manager voegt een rapportage toe, een medewerker vraagt om een extra filter en een bestuurder wil alsnog een mobiele app. Het team blijft werken, maar de oorspronkelijke businesscase raakt uit beeld.

Een leverancierselectie hoort minimaal vijf onderwerpen te toetsen:

1. Portfolio: zijn vergelijkbare processen, koppelingen of gebruikersrollen zichtbaar?
2. Referentiegesprekken: kunnen klanten uitleggen hoe het bureau omgaat met tegenvallers?
3. Technische diepte: beschrijft de offerte testen, beveiliging, hosting, logging en overdracht?
4. Culturele fit: spreken opdrachtgever en ontwikkelteam dezelfde taal over risico's en keuzes?
5. Werkproces: zijn discovery, Solution Design, sprints, demo's en acceptatie concreet ingericht?

Sturen op uurtarief alleen is een klassieke fout. Een partij van €65 per uur die twee keer zoveel uren nodig heeft, kost uiteindelijk meer dan een bureau dat €95 per uur rekent en sneller tot een bruikbare release komt. De relevante vergelijking is de totale investering voor een werkende, beheersbare applicatie.

Na de requirements volgt de contractkeuze. Geen enkel offertemodel is automatisch veilig. De juiste keuze hangt af van hoeveel onzekerheid nog in het ontwerp zit en hoeveel regie de opdrachtgever zelf kan voeren.

Bij een vaste prijs zijn aannames doorslaggevend. Als een koppeling ingewikkelder blijkt, data niet schoon is of gebruikers toch andere rechten nodig hebben, volgt vaak een wijzigingsverzoek. Time-and-materiaal voorkomt die schijnzekerheid, maar vraagt transparantie via bijvoorbeeld Jira, GitHub of Azure DevOps.

Het sprint-fase-model werkt voor veel MKB-trajecten praktischer. Het team werkt in cycli van twee tot vier weken, met een afgesproken prijs per sprint en een demo aan het einde. De Product Owner ziet werkende functionaliteit en bevestigt de volgende stap op basis van feiten, niet op basis van een lange planning. Een duidelijke introductie op een MVP ontwikkelen helpt om die eerste release scherp te begrenzen.

Een Minimum Viable Product is geen slordige of uitgeklede applicatie. Het is de kleinste snit die het kernprobleem betrouwbaar toetst. Voor de sanitairgroothandel kan dat betekenen: voorraad raadplegen, een order registreren en de boekhouding gecontroleerd informeren. Een klantbeoordeling, geavanceerde dashboards en voorspellende AI horen dan op de roadmap, niet in de eerste sprint.

De roadmap moet per release vastleggen welke gebruikersgroep, welk proces en welke waarde wordt bediend. Een release-strategie met duidelijke beslismomenten voorkomt dat “nog één klein dingetje” de kernrelease vertraagt. De opdrachtgever hoort per sprint te kunnen beantwoorden: wat is gebouwd, wat is geaccepteerd, wat is het risico en wat wordt bewust uitgesteld?

Een MVP is klein in omvang, niet klein in verantwoordelijkheid. Authenticatie, autorisaties, logging en foutafhandeling horen bij de eerste versie wanneer het proces die eisen stelt.

Development begint pas nadat de Solution Design is ondertekend. Dat ontwerp beschrijft de gebruikersrollen, belangrijkste schermen, datastromen, integraties, beveiligingskeuzes en grenzen van de eerste release. Een team dat zonder dit fundament direct codeert, verplaatst onzekerheid naar de duurste fase.

Een monoloog-aanpak levert meestal een demo op die pas laat wordt getoetst. Een sprintcyclus van twee weken geeft de Product Owner sneller zicht op aannames. Pair programming, code-reviews en geautomatiseerde tests zijn geen luxe, maar manieren om fouten vroeg te vinden en kennis niet bij één developer te laten zitten.

Voor een intern dashboard of klantportaal is een webapplicatie vaak de meest nuchtere keuze. Een PWA kan geschikt zijn wanneer gebruikers de oplossing mobiel nodig hebben, maar installatie via een app store geen aantoonbare waarde toevoegt. Native iOS- en Android-apps zijn logisch wanneer functies zoals intensieve apparaatinteractie, offline gedrag of platformspecifieke mogelijkheden centraal staan.

Low-code kan verantwoord zijn voor een afgebakende workflow met beperkte complexiteit. Het wordt riskant wanneer een organisatie afhankelijk wordt van maatwerkcomponenten binnen een platform, wanneer data-eigenaarschap onduidelijk is of wanneer migratie later moeilijk wordt. De keuze moet daarom niet alleen de eerste bouwsnelheid beoordelen, maar ook beheer, integraties en exit-mogelijkheden.

Een offerte voor een applicatie laten maken hoort minimaal duidelijkheid te geven over:

• Codebeheer: één centrale Git-repository met branches, pull requests en toegangsbeheer.
• Deployment: een CI/CD-pipeline die gecontroleerd bouwt, test en naar omgevingen uitrolt.
• Kwaliteit: automatische unit- en integratietests, aangevuld met handmatige acceptatie.
• Beveiliging: OWASP-richtlijnen, dependency-scans, toegangsbeheer en veilige secrets.
• Documentatie: API-keuzes, datamodellen, integratiefouten en beheerprocedures.
• Architectuur: een monoliet als overzichtelijke start voor samenhangende processen, microservices pas wanneer onafhankelijke schaalbaarheid of teamgrenzen dat rechtvaardigen.
• Legacy: een adapter of gefaseerde migratie wanneer een oud systeem niet direct kan worden vervangen.

MG Software bouwt onder meer webapplicaties, mobiele apps, API-koppelingen en AI-integraties, met onderhoud en hosting na oplevering als onderdeel van de bredere softwareaanpak.

Een logistiek MKB-bedrijf liet een applicatie in één keer livegaan. De facturatiemodule was niet met realistische scenario's getest. Orders werden verwerkt, maar facturen liepen vast, waardoor de operatie drie dagen platlag. Dat incident had minder te maken met programmeertalent dan met een ontbrekend releaseproces.

Een gefaseerde uitrol had het risico zichtbaar gemaakt. De applicatie hoort eerst naar staging te gaan, daarna naar een acceptatieomgeving. Een kleine canary-release of blue-green deployment kan vervolgens aantonen of de productieomgeving correct reageert voordat alle gebruikers worden overgezet.

Developers voeren unit-tests uit op afzonderlijke functies. Integratietests controleren of API-koppelingen, authenticatie en gegevensoverdracht samenwerken. End-to-end-tests doorlopen complete gebruikersprocessen, bijvoorbeeld van orderinvoer tot factuurstatus.

Gebruikerstests vullen die technische lagen aan. Een klein panel van echte medewerkers voert herkenbare scenario's uit, inclusief fouten en uitzonderingen. Een magazijnmedewerker test niet alleen de ideale scan, maar ook een onbekende barcode, een dubbele scan en een ontbrekende voorraadregel.

De acceptatieomgeving moet productiegedrag benaderen zonder persoonsgegevens onnodig bloot te stellen. Productiedata-anonimisering is daarom noodzakelijk wanneer realistische records nodig zijn. Een goede UAT-sessie werkt met vooraf vastgelegde scenario's, duidelijke acceptatiecriteria en een geregistreerde beslissing per onderdeel.

Een volwassen plan bevat een rollback-strategie, een eigenaar per actie, een gecontroleerde datamigratie en monitoring vanaf de eerste minuut. Monitoring moet zowel de applicatie als de infrastructuur volgen, inclusief foutmeldingen, wachtrijen, responstijden en beschikbaarheid.

De beheerorganisatie krijgt vóór livegang een warme overdracht. Die overdracht bevat toegang, documentatie, escalatieroutes en instructies voor veelvoorkomende incidenten. Een hypercare-periode van twee tot zes weken houdt het ontwikkelteam bereikbaar voor kinderziektes die pas in dagelijks gebruik zichtbaar worden.

Oplevering is geen eindpunt. Het is het begin van de tweede levensfase van de applicatie, waarin gebruikersfeedback, beveiligingsupdates, externe systemen en veranderende bedrijfsprocessen samenkomen.

Correctief onderhoud herstelt bugs en incidenten. Adaptief onderhoud houdt de software werkend wanneer frameworks, browsers, mobiele besturingssystemen of beveiligingsvereisten veranderen. Perfectief onderhoud verbetert bestaande functies op basis van feedback, zonder dat het kernprobleem wijzigt.

Die categorieën vragen een ander budget en een andere responstijd. Een SLA kan onderscheid maken tussen een bedrijfskritische storing, een beveiligingspatch en een kleine verbetering. Zonder die afspraken ontstaat discussie op het moment dat de applicatie juist stabiel moet blijven.

Integraties verdienen een eigen beheerplan. Boekhoudsoftware, CRM, ERP, betaalproviders, leveranciers-API's en SSO-providers zoals Entra ID of Google Workspace veranderen allemaal buiten de applicatie om. Een koppeling die vandaag werkt, kan morgen fouten geven door een gewijzigde authenticatie, een aangepast datamodel of een ingetrokken API-versie. Een API-koppeling laten maken vraagt daarom ook om monitoring, foutafhandeling en periodiek onderhoud.

Nederlandse kostenoverzichten noemen 10% tot 20% van de bouwkosten per jaar voor onderhoud, hosting en doorontwikkeling, zoals beschreven in dit overzicht over maatwerksoftware. Een vast onderhoudsbudget voorkomt dat iedere noodzakelijke update als onverwacht meerwerk wordt behandeld.

Een applicatie die na twee jaar drie keer zoveel gebruikers moet aankunnen, heeft in de bouwfase al keuzes nodig rond database-indexering, caching, achtergrondtaken, rechten en observability. Een schaalbaar ontwerp betekent niet automatisch microservices. Een goed gestructureerde monoliet kan voor een MKB-organisatie juist eenvoudiger te beheren zijn, zolang grenzen, tests en interfaces helder zijn.

De roadmap hoort via sprints te worden onderhouden. Incidenten krijgen prioriteit, structurele verbeteringen worden gepland en nieuwe functies worden getoetst aan het bedrijfsdoel. Zo blijft de applicatie een beheerd product in plaats van een project dat na livegang langzaam veroudert.

De bouwprijs is slechts één deel van de investering. Voor een MKB-MVP ligt de indicatie op €15.000 tot €80.000. Een volledig maatwerkplatform valt eerder in de bandbreedte van €80.000 tot €250.000 of meer. Nederlandse overzichten noemen daarnaast bredere ranges, van ongeveer €5.000 tot €25.000 voor een eenvoudige MVP tot €150.000 tot €250.000 of meer voor enterprise-platforms, afhankelijk van scope, risico en integraties.

De jaarlijkse doorloopkosten omvatten onderhoud, hosting, security-patches en support. Integratiekosten komen daar vaak afzonderlijk bij, zeker wanneer boekhouding, CRM en ERP elk hun eigen datamodel en foutafhandeling vereisen. Het kostenoverzicht voor een app laten maken is bruikbaar als startpunt, maar een leverancier kan pas na discovery een betrouwbare raming geven.

1. Is het probleem uniek voor het eigen proces?
2. Is minimaal €25.000 beschikbaar voor bouw en eerste doorloop?
3. Kan de organisatie een Product Owner aanwijzen?
4. Is er geduld voor een traject van vier tot negen maanden?
5. Is duidelijk welke data de applicatie nodig heeft en wie die beheert?

Wie vier van de vijf vragen met ja beantwoordt, heeft een serieuze kans van slagen. Bij drie of minder positieve antwoorden ligt een standaardoplossing, PWA of configuratie van bestaande software meer voor de hand.

De juiste beslissing kijkt naar de total cost of ownership over vijf jaar, niet naar de laagste initiële offerte. Bouw, hosting, onderhoud, integraties, beveiliging, support en doorontwikkeling bepalen samen wat een applicatie werkelijk kost. Nederlandse overheidsprojecten laten zien hoe groot het risico van slechte ICT-sturing kan zijn: volgens de tijdelijke ICT-commissie van de Tweede Kamer slaagt ongeveer 30% van alle overheidsprojecten en slechts 7% van grote projecten vanaf €7,5 miljoen, terwijl jaarlijks circa €4 tot €5 miljard verloren gaat aan mislukte ICT-projecten, zoals beschreven in de analyse over falende ICT bij de Nederlandse overheid. Een beperkte eerste release, duidelijke besluitmomenten en structureel beheer zijn geen bureaucratie. Ze beschermen de investering.

MG Software helpt MKB-organisaties met maatwerkapplicaties, webapplicaties, mobiele apps, integraties, onderhoud en doorontwikkeling, van requirements tot stabiele livegang. Bespreek de eigen processen, data en budget met MG Software en laat eerst bepalen of maatwerk werkelijk de verstandigste route is.