Software laten maken: zo toets je aanpak, kosten en continuïteit vóór de start

Een organisatie kan software laten maken met een helder idee, een budget en een ontwikkelpartner. Toch blijft na de eerste demo vaak de lastigste vraag liggen: is dit product straks ook veilig, betaalbaar en overdraagbaar?

Deze customer journeygids volgt de keuze terug vanaf de aanvraag. Wanneer volstaat standaardsoftware? Wanneer is maatwerk verdedigbaar? Welk bewijs moet een partner leveren over requirements, discovery, prototype, architectuur, integraties en security? Ook code-eigendom, hosting, onderhoud, modelkeuze, vendor lock-in en exit komen aan bod.

Groeien AI-budgetten maken software laten maken op basis van wisselbaarheid belangrijker dan een snelle demo

Een demo met één AI-model is snel overtuigend. Een vraag verschijnt op het scherm, het antwoord klinkt goed en het project lijkt bijna klaar. Maar een demo bewijst vooral dat één scenario op één moment werkt. Zij bewijst niet dat de oplossing betaalbaar blijft wanneer het model duurder wordt, minder beschikbaar is of technisch niet meer past.

Dat risico groeit nu organisaties meer met enterprise AI doen. In een onderzoek van 21 tot en met 24 juli 2026 ondervroeg Morning Consult 3.003 Amerikaanse beslissers op managementniveau of hoger. De samenvatting van het onderzoek beschrijft groeiende budgetten, terwijl organisaties hun platformkeuzes nog niet hebben gestandaardiseerd. Verschillende modellen, leveranciers en applicaties blijven naast elkaar bestaan.

Een modelkeuze is ook een architectuurkeuze

Voor een digitaal product betekent dit dat een modelprovider niet ongemerkt de kern van het systeem mag worden. De applicatie moet zelf bepalen welke gegevens naar een model gaan, hoe antwoorden worden beoordeeld en welke acties daarna mogen volgen. De modelaanbieder levert een onderdeel, niet de volledige bedrijfslogica.

Een goede technische intake maakt daarom zichtbaar:

• welke functies afhankelijk zijn van een model;
• welke gegevens in de applicatie zelf blijven;
• hoe prompts, evaluaties en bronverwijzingen worden beheerd;
• hoe een ander model kan worden getest;
• welke kostenlimieten en terugvalscenario’s nodig zijn.

Dat vraagt niet automatisch om een ingewikkelde architectuur. Het vraagt wel om bewuste grenzen. Wie die grenzen pas onderzoekt wanneer een leverancier wegvalt, betaalt vaak voor een migratie onder tijdsdruk.

Het bewijs zit in de wisseltest

Een partner hoeft niet vooraf te beloven dat elk model eenvoudig vervangbaar is. Wel moet duidelijk zijn waar de afhankelijkheid zit en hoe een wissel wordt beoordeeld. Een praktische test is een tweede model laten antwoorden op dezelfde vaste evaluatieset. Dan worden kwaliteit, snelheid, kosten en fouttypen vergelijkbaar.

Bij Metbyte is in de maatwerkchatbot voor VOO juist met verschillende modellen getest. De chatbot werd iteratief ontwikkeld en beantwoordde volgens de case meer dan 95 procent van de vragen correct. Dat percentage hoort bij deze specifieke toepassing en is geen algemene garantie. Het laat wel zien waarom kennislaag, integraties en evaluatie minstens zo bepalend zijn als de naam van het model.

Maatwerk is pas logisch als standaardsoftware het strategische proces niet kan dragen

De vraag “wat moet er gebouwd worden?” komt meestal te vroeg. Eerst moet duidelijk zijn welk probleem de software oplost en of dat probleem werkelijk uniek is. Een generiek proces met een passende SaaS-oplossing vraagt doorgaans niet om een eigen platform. Een organisatie die vooral sneller wil starten, kan beter beginnen met standaardsoftware.

No code kan geschikt zijn voor een beperkte workflow of een intern experiment. Een integratie past wanneer de bestaande systemen goed werken, maar één functie ontbreekt. Maatwerk wordt verdedigbaar wanneer het proces zelf onderscheidend is, wanneer complexe koppelingen bepalend zijn, wanneer rollen en toegangsrechten niet in een pakket passen of wanneer strikte eisen aan data en verwerking gelden.

De build versus buy beslissing vraagt om een harde grens

Een eenvoudige beslisregel helpt:

De fout ontstaat wanneer een organisatie een standaardpakket koopt en het vervolgens met workarounds probeert om te bouwen tot maatwerk. Dan ontstaan extra licenties, losse databronnen en handmatige controles. De software lijkt goedkoper, maar het proces wordt duurder.

Een prototype is geen verkleinde eindversie

Bij AI en nieuwe digitale producten is eerst bewijs verzamelen vaak verstandiger dan meteen een volledig platform bouwen. Metbyte onderzoekt een concrete use case in een AI prototype van drie weken, verdeeld over drie sprints van één week. Het doel is zicht krijgen op wat werkt, waar de pijnpunten liggen en wat nodig is om van een MVP naar een schaalbare toepassing te gaan.

Dat prototype maakt de keuze scherper. Misschien blijkt een bestaande applicatie met een koppeling voldoende. Misschien is de brondata te onvolledig voor productie. Of misschien is juist een eigen productomgeving nodig. Het resultaat is niet alleen een demo, maar een beter onderbouwde beslissing over de volgende investering.

Een goede partner verkoopt na discovery geen droom, maar een toetsbaar bouwplan

Een offerte die na één gesprek op de mat ligt, kan er verzorgd uitzien en toch weinig zekerheid bieden. Zolang gebruikers, processen, uitzonderingen, datastromen en technische beperkingen niet zijn onderzocht, blijft een groot deel van het risico onzichtbaar. De prijs lijkt dan precies, terwijl de onderliggende aannames dat niet zijn.

Discovery is de fase waarin requirements worden aangescherpt en keuzes worden getoetst vóór de productieontwikkeling begint. Een partner hoort niet alleen te vragen welke functies gewenst zijn, maar ook wie ze gebruikt, welke systemen al bestaan en wat er gebeurt wanneer een koppeling uitvalt.

Dit moet vóór de eerste productiesprint duidelijk zijn

Een bruikbaar bouwplan bevat minimaal:

• het bedrijfsdoel en de belangrijkste gebruikers;
• de afbakening van de MVP en wat bewust buiten scope blijft;
• concrete gebruikersscenario’s en acceptatiecriteria;
• een overzicht van databronnen, datamodellen en eigenaars;
• integraties, API’s, authenticatie en toegangsrechten;
• technische risico’s, aannames en open beslissingen;
• een voorlopige architectuur en route naar productie;
• een planning met afhankelijkheden, niet alleen een einddatum.

Bij Metbyte begint een samenwerking volgens de eigen werkwijze met de uitdaging en het bedrijfsdoel. Daarna worden strategie, data en gewenste opbrengst aangescherpt voordat de eerste regel code wordt geschreven. Voor websites loopt dat door naar maatwerkdesign, ontwikkeling en doorgroei via een CMS.

Vraag om bewijs, niet alleen om een presentatie

Een partner kan een prototype laten zien, maar ook laten zien hoe het prototype verder moet. Dat verschil is relevant. Vraag bijvoorbeeld welke onderdelen opnieuw moeten worden gebouwd voor productie, welke gegevens nog ontbreken en hoe monitoring, beheer en foutafhandeling worden ingericht.

Bij de VOO case is naast de chatbot ook een beheeromgeving beschreven. VOO kan gesprekken bekijken, de AI bijsturen en zien welke interne data voor antwoorden is gebruikt. De integratie met de website werkt met een eenmalig wachtwoord. Zulke details zeggen meer over productierijpheid dan een lijst met gebruikte frameworks.

De beoordelingsvraag wordt daarmee concreet: welke onzekerheid is na discovery verdwenen, en welke onzekerheid staat nog open? Een goed voorstel doet niet alsof alles al bekend is. Het maakt juist zichtbaar wat nog onderzocht moet worden.

Vergelijk partners op architectuurbewijs, niet op een lijst frameworks

React, Next.js, serverless hosting of een specifieke LLM vertellen op zichzelf weinig over de kwaliteit van een oplossing. De relevante vraag is hoe de gekozen techniek het bedrijfsdoel ondersteunt. Kan de applicatie groeien zonder fundamentele herbouw? Zijn gegevens en verantwoordelijkheden duidelijk gescheiden? Is een koppeling vervangbaar? Kunnen gebruikers alleen zien en doen wat hun rol toestaat?

Een architectuurcheck hoort daarom verder te gaan dan een diagram met blokken. Vraag om onderbouwing op zes punten:

Security begint bij ontwerp, niet bij de laatste controle

Een applicatie die persoonsgegevens verwerkt, heeft meer nodig dan een privacyverklaring. Er moet worden vastgesteld welke gegevens noodzakelijk zijn, wie toegang krijgt, waar verwerking plaatsvindt en welke gebeurtenissen worden gelogd. Bij AI komen daar bronverwijzingen, modeldata, promptlogs en menselijke controle bij.

Voor organisaties die onder de Nederlandse Cyberbeveiligingswet vallen, gelden vanaf 15 augustus 2026 nieuwe verplichtingen. De Rijksoverheid schrijft dat de wet gevolgen heeft voor ruim 8.000 organisaties. Niet iedere organisatie valt eronder, maar de richting is duidelijk: continuïteit en cyberrisico’s horen bij de bestuurlijke beoordeling van een digitaal systeem.

Architectuur moet ook een migratieroute bevatten

Een leverancier die alleen vertelt hoe iets vandaag draait, laat een belangrijk deel van de opdracht weg. Laat ook beschrijven hoe hosting, databases, modelproviders en identitydiensten later kunnen worden vervangen. Dat hoeft niet allemaal direct te gebeuren. Het moet wel technisch en contractueel denkbaar zijn.

Bij een maatwerkwebsite beschrijft Metbyte een headless aanpak met Next.js, React en een headless CMS. De keuze voor een dergelijke opzet moet in een offerte niet als doel op zichzelf worden gepresenteerd. De relevante vraag is welke vrijheid, snelheid, schaalbaarheid en beheerkeuzes de architectuur voor deze organisatie oplevert.

De laagste offerte is niet de laagste investering als beheer en exit ontbreken

Een ontwikkelofferte bestaat zelden alleen uit code. De totale investering omvat ook discovery, design, testen, hosting, licenties, security, monitoring, support, updates, kennisoverdracht en doorontwikkeling. Wie alleen de bouwprijs vergelijkt, zet twee aanbiedingen naast elkaar die mogelijk niet hetzelfde leveren.

Een realistisch kostenmodel splitst ten minste deze posten uit:

• requirements, discovery en technisch ontwerp;
• UX, design en prototype;
• ontwikkeling, integraties en datamigratie;
• testen, beveiligingscontroles en livegang;
• hosting, domeinen, licenties en modelgebruik;
• onderhoud, monitoring, support en incidenten;
• doorontwikkeling en wijzigingen in scope;
• documentatie, overdracht en een eventuele migratie.

Voor Metbyte zijn op basis van de beschikbare eigen pagina’s geen algemene bedragen voor softwareontwikkeling, beheer of productieplanning gepubliceerd. Ook ontbreken algemene cijfers over budget, doorlooptijd en rendement. Die cijfers horen dus niet als schijnprecisie in een offerte of artikel te worden ingevuld. De juiste prijs ontstaat pas nadat scope, integraties, risico’s en beheer zijn onderzocht.

Eigendom van code moet op papier staan

De organisatie moet vooraf weten welke broncode, configuratie, documentatie, ontwerpen, data en accounts worden overgedragen. Ook moet onderscheid worden gemaakt tussen specifiek gemaakte onderdelen en bestaande open source of herbruikbare bouwstenen. Een contract moet beschrijven welke rechten gelden en wanneer overdracht plaatsvindt.

Vraag daarnaast wie eigenaar is van:

• de repository en deploymentomgeving;
• database, exports en back-ups;
• API-sleutels, domeinen en hostingaccounts;
• prompts, evaluatiesets en kennisbronnen;
• documentatie en technische beslissingen.

Een exitplan is een ontwerpkeuze

The Register meldde op 6 augustus 2026 dat bijna driekwart van de Europese bedrijven bezorgd is over een mogelijke beperking van toegang tot Amerikaanse technologie, terwijl veel organisaties nog geen concreet plan hebben om van leverancier te wisselen. Het bericht van The Register raakt daarmee ook maatwerksoftware.

Een exitplan hoeft geen verhuizing morgen te betekenen. Het beschrijft wel welke data exporteerbaar is, in welk formaat, hoe gebruikers kunnen worden overgezet en welke diensten tijdelijk naast elkaar kunnen draaien. Ook de kosten en ondersteuning bij overdracht horen vooraf bespreekbaar te zijn. Zonder die afspraken kan een lage startprijs later veranderen in een dure afhankelijkheid.

Van beoordelen naar een technische intake

De lastigste keuze is vaak niet welke technologie wordt gebruikt, maar welk bewijs nog ontbreekt. Een partner moet kunnen uitleggen wat er gebouwd wordt, waarom maatwerk nodig is, hoe de oplossing beheerd wordt en wat er gebeurt wanneer een leverancier, model of hostingplatform verandert.

Geen zin om zelf requirements, architectuur en prototype aan elkaar te knopen? Metbyte brengt strategie, design en development samen en werkt met één aanspreekpunt van eerste idee tot livegang. De logische vervolgstap is een technische intake of prototypegesprek, zodat de onzekerheden eerst op tafel komen en pas daarna de bouw begint.