Wat kost bedrijfssoftware laten maken?

Er bestaat geen eerlijke standaardprijs voor bedrijfssoftware op maat. Het budget wordt pas toetsbaar wanneer de eerste workflow, gebruikersrollen, data, koppelingen, uitzonderingen, acceptatie en het beheer na livegang expliciet zijn gemaakt.

Het eerlijke antwoord: zonder scope is ieder bedrag misleidend

Bedrijfssoftware kan een compact intern werkoverzicht zijn, maar ook een applicatie met klantportaal, planning, offertes, dashboards en meerdere koppelingen. Die oplossingen hebben niet dezelfde bouwopdracht. Een bedrag zonder beschrijving van gebruikers, processtappen, data en gewenste uitkomst lijkt concreet, maar vertelt niet wat je ervoor krijgt. Begin daarom bij de bedrijfssoftware op maat die nodig is om één herkenbaar knelpunt op te lossen, niet bij een willekeurige functieslijst.

De prijsartikelen die op 3 augustus 2026 in de Nederlandse zoekresultaten zichtbaar waren, leggen vrijwel allemaal een verband tussen kosten, complexiteit, integraties en onderhoud. De genoemde bedragen lopen echter sterk uiteen en zijn niet zonder hun eigen aannames overdraagbaar. Daarom gebruikt deze gids geen geleende prijsrange. Je krijgt een budgetmodel waarmee je zichtbaar maakt welke onderdelen werk vragen, welke onzekerheden eerst onderzocht moeten worden en wanneer een kleinere eerste versie verstandiger is.

Maak eerst een kostenkaart van de dagelijkse kernworkflow

Teken de route die de software moet ondersteunen van trigger tot afgeronde taak. Bijvoorbeeld: een aanvraag komt binnen, wordt beoordeeld, krijgt een eigenaar, wordt aangevuld met gegevens, leidt tot een offerte en eindigt in uitvoering of nazorg. Noteer bij iedere stap wie handelt, welke informatie nodig is, welke beslissing wordt genomen en wat er bij een uitzondering gebeurt. Zo ontstaat een bouwbare workflow in plaats van een verzameling schermideeën.

Vertaal die route daarna naar zes budgetblokken: functies en schermen; rollen en rechten; datamodel en migratie; koppelingen; uitzonderingen en foutafhandeling; testen en acceptatie. Een extra scherm is niet altijd duur. Een ogenschijnlijk kleine uitzondering kan juist veel ontwerp-, bouw- en testwerk vragen wanneer zij meerdere rollen, statussen en systemen raakt. Door de blokken apart te benoemen kan een leverancier uitleggen waar werk en onzekerheid zitten zonder alles in één totaalbedrag te verbergen.

Bepaal welke gebruikersrollen echt verschillend werk doen

Een rol is meer dan een label als medewerker of beheerder. Beschrijf per rol wat iemand mag zien, toevoegen, wijzigen, goedkeuren, exporteren en herstellen. Een verkoper die eigen leads beheert, een planner die capaciteit verdeelt en een manager die teamrapportages bekijkt, hebben andere schermen en controles nodig. Iedere nieuwe combinatie van rechten kan gevolgen hebben voor navigatie, datatoegang, meldingen en tests.

Voorkom dat uitzonderingen pas tijdens de bouw boven water komen. Vraag bijvoorbeeld wie een foutieve status mag terugzetten, wie gevoelige notities ziet, wat een tijdelijke medewerker mag exporteren en hoe een vertrokken gebruiker wordt afgehandeld. Niet iedere wens hoeft in de eerste release. Het doel is dat de gekozen rollen controleerbaar genoeg zijn om veilig te werken, terwijl zeldzame of onbevestigde varianten bewust buiten scope blijven totdat hun waarde duidelijk is.

Data en migratie kunnen meer werk vragen dan het nieuwe scherm

Bestaande bedrijfsdata staat vaak verspreid over spreadsheets, mailboxen, boekhoudsoftware en losse tools. Voordat die data naar een nieuw systeem kan, moet duidelijk zijn welke bron leidend is, welke velden overeenkomen, welke records dubbel zijn en hoeveel historie echt nodig blijft. Begroot daarom broninventarisatie, veldmapping, opschoning, proefimport en controle als afzonderlijk werk. “Data meenemen” is te vaag voor een betrouwbare offerte.

Kies vooraf acceptatiecontroles die een medewerker zelf kan uitvoeren. Vergelijk aantallen per recordtype, controleer een steekproef van bekende klanten, test statusvelden en relaties en leg vast welke afwijkingen nog acceptabel zijn. Meer historie meenemen is niet automatisch beter. Een compacte set betrouwbare kerngegevens kan voor de eerste versie bruikbaarder zijn dan een volledige migratie vol oude uitzonderingen waarvan niemand nog eigenaar is.

Koppelingen kosten niet alleen bouwtijd, maar ook beheer

Een koppeling met website, mailbox, agenda, boekhouding of een extern platform heeft minimaal een gegevenscontract nodig: welke informatie gaat welke kant op, welk systeem is leidend, hoe vaak wordt gesynchroniseerd en wat gebeurt er bij ongeldige of ontbrekende data? Een demonstratie waarin één record aankomt bewijst nog niet dat dubbele invoer, storingen, terugboekingen en gewijzigde externe velden goed worden behandeld.

Zet per koppeling ook de afhankelijkheden na livegang in de begroting. Denk aan externe abonnementen, API-limieten, veranderende rechten, monitoring, foutmeldingen en herstel. Wanneer de kernvraag alleen gaat over verkoop- en klantopvolging, kan een CRM systeem op maat een scherpere route zijn dan direct brede bedrijfssoftware bouwen. De kosten blijven dan gekoppeld aan één commerciële workflow en noodzakelijke integraties.

Scheid de startversie van de volledige wensenlijst

Gebruik drie kolommen: noodzakelijk voor de eerste werkdag, logisch na bewezen gebruik en bewust buiten de huidige scope. Een functie hoort alleen in de eerste kolom wanneer een kernscenario zonder die functie niet kan worden uitgevoerd of gecontroleerd. Een dashboard met twintig statistieken kan aantrekkelijk zijn, terwijl één overzicht met eigenaar, status en volgende actie voldoende is om de eerste proceswinst te toetsen.

Vergelijk daarna maatwerk met een passend standaardalternatief op dezelfde procesuitkomst. De vergelijking tussen maatwerk en standaardsoftware helpt bepalen of configuratie volstaat of dat afwijkende workflows, rechten en koppelingen werkelijk eigen bouw rechtvaardigen. Dit besluit gaat niet over zoveel mogelijk maatwerk. Het gaat erom dat je geen eigen systeem financiert voor een proces dat een bestaand pakket goed genoeg ondersteunt.

Splits eenmalige bouw en terugkerend eigenaarschap

Een bruikbaar budget heeft twee tabellen. In de eerste staan discovery, procesontwerp, interfaceontwerp, bouw, datamigratie, integraties, tests, training en livegang. In de tweede staan hosting, monitoring, back-ups, technisch onderhoud, beveiligingsupdates, ondersteuning, externe diensten en toekomstige wijzigingen. Noteer per regel wat inbegrepen is, welke aanname geldt en wie eigenaar is. Zo wordt zichtbaar of een lage bouwprijs werk naar de beheerfase verschuift.

Vraag ook wat je bij oplevering krijgt: beheeraccounts, documentatie, data-export, configuratie-informatie en afspraken over incidenten en wijzigingen. De exacte rechten en verplichtingen horen in de overeenkomst en kunnen juridische beoordeling vragen. Voor de budgetkeuze is vooral belangrijk dat toegang, continuiteit en overdracht niet worden gereduceerd tot een losse belofte van nazorg. Ze moeten als concrete werkzaamheden en verantwoordelijkheden herkenbaar zijn.

Vergelijk voorstellen op dezelfde scenario’s en acceptatiecriteria

Geef iedere leverancier dezelfde kernscenario’s, rollen, databronnen, koppelingen en uitsluitingen. Vraag per onderdeel welke aanpak, afhankelijkheid en acceptatie wordt voorzien. De gids voor een maatwerk-softwareofferte beoordelen helpt vervolgens controleren of resultaat, scope, beheer en risico’s voldoende concreet zijn. Een voorstel met de meeste pagina’s of functies is niet automatisch sterker; een voorstel dat de gekozen workflow aantoonbaar ondersteunt is beter vergelijkbaar.

Maak voor akkoord een kleine acceptatietabel. Beschrijf per scenario de beginsituatie, handeling, verwachte uitkomst, verantwoordelijke tester en beslisregel. Markeer ook wat een defect, een onduidelijke afspraak en een nieuwe wens is. Zonder dat onderscheid groeit iedere bevinding uit tot discussie over de oorspronkelijke prijs. Met toetsbare criteria kan het team gericht accepteren en kan uitbreiding apart worden geschat.

Voorbeeld: een groothandel met serviceplanning

Stel dat een fictieve groothandel aanvragen uit e-mail en website wil samenbrengen, offertes wil opvolgen en na akkoord een servicetaak wil plannen. De volledige wenslijst bevat klantportaal, mobiele app, voorraad, routeplanning, dashboards en boekhoudkoppeling. Voor de eerste release zijn aanvraag, klantkaart, offerte-status, eigenaar, volgende actie en overdracht naar planning de kern. Dat is één controleerbare route in plaats van zes half uitgewerkte modules.

De begroting wordt vervolgens opgebouwd uit twee gebruikersrollen, het minimale datamodel, import van actieve klanten, de website-ingang, een gecontroleerde planningsoverdracht en acceptatiescenario’s. Voorraad, routeoptimalisatie en klantportaal blijven expliciet later. Na gebruik kan het team meten waar nog dubbele invoer of wachttijd zit. Dit voorbeeld is geen klantcase, prijsindicatie of resultaatbelofte; het laat zien hoe afbakening een voorstel toetsbaar maakt.

Werk met beslispoorten in plaats van één groot eindbedrag

Verdeel het traject in resultaten waarop je bewust beslist: een goedgekeurde scopekaart, een getest kernprototype, een geaccepteerde datamapping, een werkende integratieproef en een pilot met echte gebruikersscenario’s. Na iedere poort zijn vier besluiten mogelijk: doorgaan, herstellen, scope aanpassen of stoppen. Hierdoor hoeft onzekerheid niet vooraf in een onnauwkeurig totaalbedrag te worden verstopt.

Leg per fase vast welk bewijs nodig is voordat nieuw budget wordt vrijgegeven. Een prototype moet bijvoorbeeld de belangrijkste taakroute laten zien; een proefmigratie moet herkenbare records correct verwerken; een koppeling moet ook fouten zichtbaar afhandelen. Fasering garandeert geen probleemloos project en maakt maatwerk niet automatisch goedkoper. Ze beperkt wel hoeveel ongetoetste aannames tegelijk worden gefinancierd en geeft het bedrijf een menselijk beslismoment.

Bereid een scopegesprek voor met twaalf concrete antwoorden

Schrijf vóór een gesprek op: welk probleem dagelijks zichtbaar is; welke uitkomst nodig is; wie de eerste gebruikers zijn; welke vijf scenario’s moeten werken; welke gegevens daarbij horen; welke bron leidend is; welke rollen verschillen; welke koppeling noodzakelijk is; welke uitzondering risicovol is; wat later mag; wie intern beslist; en hoe acceptatie plaatsvindt. Onbekende antwoorden hoeven niet te worden verzonnen, maar worden als onderzoeksvraag gemarkeerd.

Met die antwoorden kan Softora tijdens een scopegesprek de kernworkflow, onzekerheden en een beheersbare eerste fase zichtbaar maken. De uitkomst is geen universele prijs of gegarandeerde besparing. Het is een onderbouwde bouwroute waarop een voorstel kan worden gebaseerd. Bekijk de mogelijkheden voor bedrijfssoftware op maat of start een gesprek wanneer je de huidige workflow en de gewenste eerste uitkomst wilt toetsen.