Je overweegt custom software te laten bouwen. Niet omdat het hip is, maar omdat de standaardpakketten net niet passen, of omdat je groei tegen de muur van je huidige spreadsheets aanloopt. De vraag die volgt is meestal dezelfde: wat kost dat nu echt, hoe lang duurt het, en hoe weet ik dat ik niet voor vier jaar vastzit aan één leverancier? Deze gids beantwoordt die drie vragen met cijfers uit echte projecten, een eerlijke kosten-tabel, en de valkuilen die we MKB-ondernemers letterlijk maanden zien kosten. Geen jargon. Wel een routekaart, en zie ook onze no-code vs custom gids voor de bredere afweging waarmee je vanmiddag de eerste stap kunt zetten.

Vier fases bovenin, stack van frontend tot hosting onderin. Alles in jouw eigendom.

Wat is custom software eigenlijk?

Custom software is een applicatie die specifiek voor jouw bedrijf gebouwd is, op basis van jouw processen en data, met code die jouw eigendom is. Dat staat tegenover SaaS-pakketten waar je een licentie huurt op software die voor duizenden bedrijven hetzelfde werkt, en tegenover no-code platforms waar je in een visuele editor klikt op een onderliggende platform-engine die niet van jou is.

Het belangrijkste verschil zit niet in de techniek, maar in de eigendomsverhouding. Bij SaaS huur je toegang. Stopt de leverancier of verhoogt hij zijn prijzen, dan zit je vast. Bij no-code bouw je op iemand anders zijn platform; je flows zijn vaak niet exporteerbaar. Bij custom software krijg je de broncode, de database, de hosting-instructies. Je kunt morgen van leverancier wisselen zonder dat er iets stuk gaat.

Wanneer is custom de juiste keuze?

Eerlijk antwoord: in 60 tot 70 procent van de MKB-cases die wij beoordelen is custom software niet de eerste stap. Custom wordt pas de juiste keuze als één van vijf scenarios speelt.

  1. Eigen bedrijfslogica die nergens anders bestaat. Denk: een puntentelling voor sociale huur, een eigen prijsmodel met tientallen variabelen.
  2. Integraties met legacy systemen zonder moderne API. Een ERP uit 2009, een SOAP-koppeling, een database alleen via SQL-views ontsloten.
  3. Schaalvolume dat SaaS onbetaalbaar maakt. Boven 100.000 transacties per maand worden veel SaaS-pakketten exponentieel duurder.
  4. Concurrentievoordeel uit eigen software. Als jouw software het verschil maakt tussen winnen of verliezen van een klant.
  5. Compliance- of data-eisen die zelf-hosting verplicht maken. Medische gegevens, juridische dossiers, financiele transacties.

Loop deze vijf langs voor je een offerte aanvraagt. Geen enkel scenario van toepassing? Begin dan eerst bij SaaS of bij no-code automatisering, en upgrade pas naar custom als je tegen een echte limiet aanloopt.

Wat kost custom software bouwen?

Eerlijk antwoord: de spread is groot, en agencies die een enkele prijs noemen begrijpen jouw scope niet. Wij prijzen bewust aan de onderkant van deze ranges en leveren doorgaans in ongeveer de helft van de doorlooptijd die je elders in de markt ziet. Hieronder een tabel met indicaties op basis van projecten die wij voor Nederlands MKB hebben gebouwd.

Type projectInvestering eenmaligDoorlooptijdMaandelijks onderhoud
MVP (eerste werkende versie, 1-2 modules)€8.000 – €18.0002-3 weken€150 – €400
Standaard platform (3-6 modules, login, integraties)€20.000 – €50.0004-8 weken€400 – €1.200
Uitgebreid platform (multi-user, AI, dashboards)€50.000+2-4 maanden€1.200 – €2.500
Enterprise-grade (compliance, schaal, multi-tenant)€100.000+3-6 maanden€2.500 – €6.000

Uurtarieven in de Nederlandse markt liggen tussen €85 en €165 per uur. Bij ons werken we met een vaste prijs per fase. Maandelijkse hosting is verrassend laag: een Hetzner VPS kost €10 tot €40 per maand. De totale Total Cost of Ownership voor een MKB-platform na het eerste jaar zit vaak op €1.500 tot €5.000 per jaar all-in. Voor de uitsplitsing zie ons aankomende artikel over custom software kosten.

Welke fases doorloop je in een custom project?

  1. Discovery (1-2 weken). Diep onderzoek naar jouw processen, gebruikers, data en pijnpunten. Resultaat: een functioneel document met user stories, een data-model, een wireframe-set en een vaste prijs voor de bouwfase. Skip dit nooit.
  2. Design (1-2 weken). Op basis van de discovery maken wij interactieve prototypes in Figma. Doel: voordat er een regel code geschreven is, kunnen jij en je team al door het systeem klikken.
  3. Build (1-20 weken afhankelijk van scope). De daadwerkelijke ontwikkeling, opgesplitst in twee-weekse sprints met demos. Eis dat je elke twee weken een werkende versie te zien krijgt.
  4. Test (parallel + 1 week eindsprint). Geautomatiseerde tests, handmatige acceptatietests met echte gebruikers, en een security-scan.
  5. Launch + maintain (continu). Livegang met monitoring, een handover-document, training voor jouw team, en een SLA voor de eerste 6 tot 12 maanden.

Een veelgemaakte fout: meteen de bouw-fase willen starten zonder discovery. In 9 van de 10 gevallen rolt er dan iets uit dat niet past op de daadwerkelijke workflow. Plan op zijn minst een paid discovery van twee weken. Voor details zie ons aankomende artikel over MVP laten bouwen. Voor inspiratie is de Mastone case study een concreet voorbeeld.

Welke tech-stack kiezen wij in 80% van de gevallen?

LaagOnze keuzeWaaromAlternatief
BackendNode.js (TypeScript) of PythonGrootste talent-pool in NL, mature ecosysteemGo, .NET Core, Java Spring
FrontendReact (Next.js) of AstroStabiel, breed inzetbaar, goede performanceVue, Svelte, Angular
DatabasePostgreSQL (via Supabase of zelf-gehost)Open source, betrouwbaar, goed gedocumenteerdMySQL, MongoDB
HostingHetzner VPS of VercelEU-residency, voorspelbare kosten, makkelijk te migrerenAWS, Cloudflare, DigitalOcean
AuthSupabase Auth of ClerkSnel, veilig, GDPR-vriendelijkEigen JWT-implementatie, Auth0
MonitoringSentry + UptimeRobotVoldoende voor 95% van MKB-projectenDatadog, New Relic
CI/CDGitHub ActionsGratis voor MKB-volumes, simpel op te zettenGitLab CI, CircleCI

Waarom geen exotische keuzes? Omdat een stack die hip is in 2026 in 2031 niet meer onderhouden wordt door iemand die je kan inhuren. PostgreSQL, Node.js en React draaien al 10 tot 25 jaar mee. Volgens GitHub Octoverse 2024 blijven JavaScript, TypeScript en Python al jaren in de top 3 van meest gebruikte talen. Voor specifieke use-cases wijken we beargumenteerd af. Voor de bredere afweging tussen platforms, zie het aankomende artikel over web app vs SaaS vs custom platform.

Wat is code-eigendom en waarom is het belangrijk?

Code-eigendom betekent dat alle broncode, configuraties, deployment-scripts en documentatie van jouw platform jouw eigendom zijn. Niet in licentie. Niet “deelbaar”. Eigendom, contractueel vastgelegd, in een Git-repository onder jouw account, met deploy-instructies die een andere partij kan volgen.

Bij TopDevs leveren wij standaard vier dingen: een Git-repository onder jouw account, een README en deploy-document, alle credentials onder jouw beheer, en een handover-sessie van twee uur. Dat staat in onze algemene voorwaarden als standaard-leverbestanddeel. Voor de diepere materie ons aankomende artikel over code-eigendom.

Hoe lang duurt een custom project echt?

Type projectDiscovery + DesignBuild + TestTotaalSprints
MVP (1-2 modules)1-2 weken1 week2-3 weken1-2 sprints
Standaard platform1-2 weken3-6 weken4-8 weken2-4 sprints
Uitgebreid platform2-3 weken6-13 weken2-4 maanden4-8 sprints
Enterprise-grade3-4 weken9-22 weken3-6 maanden6-12 sprints

Voor Mastone bouwden wij het WWS-platform met een discovery van twee weken, design van twee weken, en een bouwfase van acht weken in vier sprints. Totaal: drie maanden van eerste gesprek tot productie. Het project liep niet uit omdat de scope vooraf goed afgekaderd was en omdat er aan klant-zijde één beslisser was die binnen 24 uur op vragen reageerde. Geen magie, wel discipline.

Welke risicos zijn er en hoe vermijd je ze?

  1. Scope-creep zonder mechanisme. Vermijden: alle scope-wijzigingen in een formele change-request met impact-schatting.
  2. Vendor lock-in zonder uitwegplan. Vermijden: vraag voor de start om een exit-clausule en deploy-instructies. Zie ons artikel over code-eigendom.
  3. Slechte of geen documentatie. Vermijden: documentatie is geen optie maar een leverbestanddeel.
  4. Geen ordentelijke handover. Vermijden: eis een handover-sessie van minimaal twee uur, met opname en schriftelijke architectuur-uitleg.
  5. Geen of zwakke tests. Vermijden: vraag specifiek naar de test-coverage. 60 tot 80 procent test-coverage is normaal voor een goede MKB-codebase.

Volgens McKinsey-onderzoek naar software-projecten loopt 45 procent van grote IT-projecten over budget. Een kortere doorlooptijd, een vaste prijs en een strakke discovery zijn de drie grootste hefbomen op succes.

Wat is een goede SLA en wat moet erin staan?

  1. Uptime-garantie. Voor MKB-platforms is 99,5 tot 99,9 procent realistisch en haalbaar.
  2. Response-tijden per prioriteit. Bij ons: kritiek binnen 1 uur, hoog binnen 4 werkuren, normaal binnen 2 werkdagen.
  3. Fix-tijden per prioriteit. Een fix-tijd voor kritieke issues van 4 uur is normaal.
  4. Beschikbaarheidsvenster. Voor MKB-platforms is kantooruren met een storings-piket vaak voldoende.
  5. Backups en restore-garantie. Een dagelijkse backup met restore-belofte binnen 4 uur is een redelijke ondergrens.
  6. Onderhoudsuren per maand. Typisch 4 tot 12 uur per maand, afhankelijk van complexiteit.

Wat gebeurt er precies in een discovery-traject?

Discovery is geen vrijblijvende kennismaking. Het is een betaalde fase van één tot twee weken waarin we drie tot vijf werksessies van twee uur doen, en daarnaast jouw bestaande spreadsheets, e-mails en handmatige stappen in kaart brengen. Aan het einde lever je een document op waarmee elke ontwikkelaar ter wereld jouw platform kan bouwen, en waarmee jij een vaste prijs voor de bouwfase op tafel hebt.

  • Sessie 1 (proces-mapping): wij filmen letterlijk hoe je medewerker een dagelijkse taak uitvoert in de huidige tools. Stappen, klikken, copy-paste, foutmomenten.
  • Sessie 2 (data-model): alle entiteiten op tafel. Welke velden, welke relaties, welke validaties, welke audit-eisen.
  • Sessie 3 (rollen en rechten): wie ziet wat, wie mag wat. Eindgebruiker, manager, admin, klant. Aparte tabel per rol.
  • Sessie 4 (integraties): welke externe systemen, welke APIs, welke export-formaten. Per integratie een diepte-check op documentatie en stabiliteit.
  • Sessie 5 (edge cases): wat gebeurt er als de input ontbreekt, dubbel is, of niet voldoet aan de regels. Hier vinden we 30 procent van de scope die anders pas tijdens de bouw boven water komt.

Concreet voorbeeld uit de praktijk. Bij een accountancy-klant kwam pas in sessie 5 boven tafel dat hun grootste klant (40 procent van de omzet) een eigen factuur-formaat gebruikt dat afwijkt van de standaard UBL-XML. Was die check pas in de bouwfase gedaan, dan had dat €4.500 aan herwerk gekost. Nu zat het in de scope vanaf dag één. Discovery kost €1.500 tot €3.500 en bespaart in een gemiddeld traject 5 tot 15 procent van het bouwbudget. Voor de bredere context zie no-code vs custom automation.

Wanneer kies je Node vs Python, Next.js vs Astro?

De stack-tabel hierboven is onze standaard, maar de keuze tussen alternatieven binnen die stack is niet willekeurig. Per laag spelen twee tot drie factoren die de keuze bepalen. Hieronder de afweging zoals wij die in elke discovery maken.

KeuzeKies dit alsKies het alternatief als
Node.js (TypeScript)Veel async I/O, real-time features, gedeelde types tussen front en back, team met React-ervaringPython: zwaar data-werk, AI/ML pipelines, scripting, integraties met data-science libraries
Python (FastAPI)Data-processing, AI-integraties, complexe rekenmodellen, ML-inferentieNode: full-stack JavaScript, real-time apps, dezelfde taal voor front en back
Next.jsVeel interactieve schermen, dashboards, ingelogd gedeelte, dynamische data per gebruikerAstro: marketing-site, content-zwaar, SEO-prioriteit, weinig interactiviteit
AstroStatic-first, content-management, blog, SEO, lage time-to-first-byte vereistNext.js: complexe app-state, veel client-side rendering, real-time updates
Supabase (managed Postgres)MVP, geen DBA in huis, snelle iteratie, RLS-policies past op rollen-modelZelf-gehoste Postgres: dataset >100GB, eigen DBA, specifieke extensions, kostenoptimalisatie op schaal
Vercel hostingFrontend-zwaar, edge-rendering nodig, korte deploys, kleine SaaSHetzner VPS: backend-zwaar, websockets, langlopende processen, voorspelbare hoge kosten

Concreet: voor Mastone kozen we Next.js met Postgres omdat het dashboard 80 procent van de tijd in gebruik is door één interne rol met veel formulieren. Voor een marketing-site met blog en case studies (zoals deze pagina) kozen we Astro omdat SEO en first-paint belangrijker zijn dan client-state. Voor een AI-onderzoeksassistent met embeddings en zoek-queries kozen we Python (FastAPI) backend met een Next.js front, omdat de Python-kant nodig was voor de ML-libraries. Zelfde agency, drie keuzes, drie redenen. Voor de bredere afweging zie het aankomende artikel over web app vs SaaS vs custom platform.

Hosting vergeleken: Hetzner VPS, Vercel of Supabase?

Hosting is de post die het vaakst onder-begroot wordt in offertes. Niet omdat het duur is (vaak juist niet), maar omdat de keuze tussen drie tot vijf opties impact heeft op zowel kosten als migratie-vrijheid. Hieronder de drie configuraties die wij in 90 procent van de MKB-projecten kiezen, met concrete maandkosten.

SetupWanneer geschiktMaandkosten typischVoordeelNadeel
Hetzner VPS + zelf-gehoste PostgresBackend-zwaar, langlopende processen, websockets, voorspelbaar volume€15 – €55Volledige controle, lage kosten op schaal, EU-residency in Nuremberg of HelsinkiEigen onderhoud, security-updates zelf doen, geen autoscaling out-of-the-box
Vercel + Supabase (Pro)Frontend-zwaar, MVP, snelle deploys, edge-rendering, 0-30k users€45 – €120Zero-ops, automatische deploys, Edge functions, gratis SSL, instant rollbackPricing schaalt met bandbreedte, vendor lock-in op build-systeem, koud-start bij low-traffic
Cloudflare Pages + Workers + R2Static-first, wereldwijd publiek, kosten-minimaal bij groei€0 – €25Goedkoopste optie, global edge, generous free tier, ingebouwde DDoSBeperkte runtime, geen langlopende processen, eigenaardige debug-ervaring
AWS (ECS + RDS)Enterprise compliance, multi-region, complexe DevOps, >100k users€250 – €1.500+Volwassen ecosysteem, certificeringen, fine-grained controleHoge complexiteit, lange leercurve, kosten lopen snel op zonder discipline

Onze default: Hetzner VPS voor backend-zware platforms (Mastone, Planit Consulting), Vercel plus Supabase voor frontend-zware MVPs en marketing-apps, Cloudflare Pages voor static sites en marketing-pagina-bundels. We gebruiken AWS alleen als de klant het al heeft of als er een specifieke compliance-eis is. Migratie tussen deze setups duurt typisch 1 tot 3 weken bij standaard-stacks, omdat de applicatie-code los staat van de infrastructuur.

Wie heb je nodig aan klant-zijde?

Een custom project mislukt zelden door techniek. Het mislukt door een trage beslislijn aan klant-zijde, een product owner die er geen tijd voor heeft, of een eindgebruiker die pas bij de oplevering ziet wat er is gebouwd. Voor een succesvol project heb je drie rollen nodig aan jouw kant, en die hoeven niet drie verschillende mensen te zijn.

  • Beslisser (eindverantwoordelijke): typisch de DGA, CEO of MD. Beschikbaarheid: 1 tot 2 uur per week. Taak: scope-keuzes, prioriteiten bij conflicten, akkoord op meerwerk. Cruciale eigenschap: kan binnen 24 uur een ja of nee geven.
  • Product owner (dagelijkse contactpersoon): vaak de operations-manager of senior medewerker die het proces door en door kent. Beschikbaarheid: 4 tot 12 uur per week. Taak: vragen beantwoorden, demos beoordelen, user stories aanscherpen, acceptatietests draaien.
  • Power users (2 tot 4 eindgebruikers): de mensen die het systeem dagelijks gaan gebruiken. Beschikbaarheid: 2 tot 4 uur per sprint (elke twee weken). Taak: demos meekijken, feedback geven op flow en usability, acceptatietests draaien voor go-live.
RolTijd per weekBeslissingsbevoegdheidRisico bij ontbreken
Beslisser1 – 2 uurVolledig op scope en budgetProject stagneert bij scope-conflicten, meerwerk-discussies
Product owner4 – 12 uurFunctioneel op user storiesVerkeerde aannames in bouw, late herwerk, scope-creep
Power users2 – 4 uur per sprintFeedback op usabilityLage adoptie na go-live, herwerk op UI/UX

In de praktijk loopt dit het vaakst mis bij twee patronen. Patroon één: de DGA wil zelf product owner zijn, maar heeft maar 1 uur per week beschikbaar. Resultaat: vragen blijven 5 tot 10 dagen liggen, de bouw vertraagt 30 tot 50 procent. Patroon twee: er is geen power user betrokken, alleen management. Resultaat: bij oplevering blijkt dat de daadwerkelijke gebruiker drie kritieke workflows niet kan uitvoeren, en je hebt drie weken herwerk. Bij Mastone werkte het wel omdat de DGA de product owner was met 8 uur per week beschikbaar, en er twee power users in de demos zaten vanaf sprint 1.

Concreet voorbeeld: Mastone WWS platform

Bij Mastone bouwden wij een custom platform waarin de WWS-logica centraal staat. Voorheen deden ze dat in spreadsheets met formules per cel en handmatige beleidsupdates. Discovery van twee weken: alle WWS-regels in een formeel data-model. Design van twee weken: een interface waar een beheerder per woning in 4 schermen alle kenmerken invoert. Build van acht weken in vier sprints met demos. Test parallel via een uitgebreide testset. Launch met handover-document, training, en SLA voor het eerste jaar.

Het resultaat: woningen kunnen nu in minuten beoordeeld worden in plaats van uren. Bij een beleidswijziging passen wij de logica op één plek aan. De audit-rapportage is een knop in plaats van een dag werk. SaaS bestaat niet voor dit type berekening. No-code kan het niet aan op deze schaal. Custom was hier geen luxe, maar een rationele keuze. Terugverdientijd: 14 maanden. Voor andere vastgoed-klanten en voor recruitment, advocatuur zien we vergelijkbare patronen.

Welke andere cases zijn relevant om te bekijken?

  • Recruitment: voor Simply bouwden wij een platform met eigen scoring-logica voor inkomende sollicitaties.
  • Advocatuur: voor BBS Advocaten bouwden wij een intake- en dossier-koppeling die juridische e-mails classificeert.
  • Consultancy: voor Planit Consulting bouwden wij een AI-onderzoeksassistent die over hun eigen rapporten zoekt.

Wat is de eerste stap?

  1. Stap 1: schrijf jouw probleem op in twee paginas. Niet de oplossing, het probleem. Welke processen kosten teveel tijd?
  2. Stap 2: kijk eerst of SaaS of no-code volstaat. Lees onze gids over no-code vs custom.
  3. Stap 3: plan een paid discovery, geen gratis offerte. Een paid discovery (€1.500 tot €3.500 bij ons, verrekenbaar) levert je een echt functioneel document en een vaste prijs.

Plan een gratis intake-gesprek als je samen wilt kijken. Geen verkoop-druk, wel een onderbouwd advies. Onze werkwijze en garanties staan in onze algemene voorwaarden. Voor de oplossingen die wij bouwen zie custom platforms, websites en dashboards en CMS.