ERP of SaaS in 2026? Een eerlijk beslissingskader van Clockwise Software

Belangrijkste opmerkingen

• De ERP-vs-SaaS beslissing is niet langer binair in 2026. AI-patronen en multi-tenant architectuur hebben beide categorieën zodanig veranderd dat het juiste antwoord voor veel bedrijven een hybride is die ik vijf jaar geleden zelden zag.

• Vijf vragen bepalen de categorie voor 90 procent van de klanten die ik ontmoet. Het aantal gebruikers, het gewicht van de workflow tussen afdelingen, de druk van de regelgeving, de kloof tussen koper en gebruiker en de snelheid waarmee de workflow verandert. Onderscheid in merknamen doet er minder toe.

• Zes UI/UX patronen zijn nu standaard in beide werelden. Op intentie gebaseerde navigatie, ambient copilots, generatieve standaardinstellingen, vertrouwen affordances, kortstondige personalisatie en audit samenvattingen.

• Bij onze laatste 47 gecontroleerde projecten was de duurste fout niet de keuze van de leverancier. Het was de verkeerde categorie. Oprichters die het verkeerde type systeem kozen, betaalden 2 tot 3 keer meer dan oprichters die het juiste type kozen met een middelmatige leverancier.

De beslissing werd moeilijker, niet gemakkelijker

Ik wil beginnen met iets dat contra-intuïtief klinkt. De ERP-versus-SaaS beslissing is moeilijker in 2026 dan in 2020. Niet omdat de technologie ingewikkelder is geworden, hoewel dat wel zo is. Omdat de categorieën zelf zo vervaagd zijn dat het oude steno niet meer werkt.

Vijf jaar geleden kon ik een klant binnen een uur vertellen aan welke kant van de lijn hun bedrijf stond. ERP voor de diepgaande workflow, de lange gebruikersduur, de gegevensstroom tussen afdelingen. SaaS voor het gerichte product, de self-service koper, de snelle release cadans. Die heuristiek brak ergens in 2024. Tegen de tijd dat ik dit schrijf in april 2026, heb ik een multi-tenant ERP geleverd die op dezelfde architectuur draaide als onze SaaS-producten voor consumenten en heb ik een verticale SaaS geleverd die het werk deed van een ERP-systeem van $400.000 tegen een kwart van de kosten. De categorieën betekenen niet meer wat ze betekenden.

De meeste artikelen die ik de laatste tijd over dit onderwerp heb gelezen, zijn lijstjes waarin leveranciers worden gerangschikt. Microsoft Dynamics versus NetSuite versus SAP. Ze zijn niet nutteloos, maar ze beantwoorden een vraag die eigenlijk bijna niemand stelt. De echte vraag is of je überhaupt een ERP moet kopen, of dat je bedrijf beter gediend is met een op maat gemaakte verticale SaaS, of dat wat je echt nodig hebt een hybride is die in geen van beide emmers past. Geen van de lijstjes zal je daarbij helpen. Dus ga ik het artikel schrijven waarvan ik wou dat iemand het drie jaar geleden voor mij had geschreven.

Voor de context: mijn team en ik werken als een erp-softwareontwikkelingsbedrijf aan ruwweg 30 procent van onze actieve opdrachten en als een SaaS-productstudio aan de andere 70 procent. De verdeling is de afgelopen vier jaar opmerkelijk stabiel gebleven, ook al is het werk zelf veranderd. Die mix geeft me een gezichtspunt dat pure ERP-shops of pure SaaS-shops niet hebben. Ik zie hoe de twee categorieën samenkomen en ik zie waar ze nog steeds uiteenlopen, en ik wil delen wat ik heb geleerd.

Waarom "ERP of SaaS" steeds vaker de verkeerde vraag is

Laat me je de technische reden geven waarom de categorieën vervagen, omdat het belangrijk is voor de beslissingslogica die volgt.

Het grootste deel van de afgelopen twintig jaar betekende ERP single-tenant, on-premise software met veel maatwerk en driemaandelijkse releasecycli. SaaS betekende multi-tenant, cloud-hosted software met weinig maatwerk en wekelijkse releases. Deze technische standaardwaarden bepaalden de categoriegrenzen.

Beide standaards verschoven. ERP werd multi-tenant en cloud-first, aangevoerd door NetSuite en naar voren geschoven door elke moderne ERP-leverancier die wil concurreren op prijs en updatesnelheid. SaaS kreeg diepere aanpassingsmogelijkheden door middel van configuratielagen, low-code uitbreidingspunten en functievlaggen per huurder waardoor de ervaring van de ene klant aanzienlijk kan afwijken van die van de andere. De technische kloof die historisch gezien de categorieën definieerde, is tot bijna niets geslonken.

Wat overblijft is eerder een verschil in workflowvorm dan in architectuur. ERP-gebruikers werken jarenlang binnen een recordsysteem. SaaS-gebruikers bewegen in en uit gerichte tools als hun behoeften veranderen. Dat verschil is nog steeds belangrijk. Maar het vertaalt zich niet meer duidelijk in een aankoopbeslissing, omdat dezelfde architectuur beide vormen kan ondersteunen. De vraag is verschoven van "ERP of SaaS" naar "welke vorm van workflow heeft uw bedrijf eigenlijk nodig".

De aanbevolen beslissingstabel die ik met elke klant gebruik

Vijf vragen, twee antwoorden per rij, uw categorie valt onderaan

Ik doorloop deze tabel met elke potentiële klant tijdens het eerste gesprek. Aan het eind van de tweede kolom kiest de categorie zichzelf meestal wel uit.

Een opmerking over deze tabel die ik wil benadrukken. Als je vijf of meer rijen scoort in één kolom, is de categorie beslist. Als je drie tot vier rijen scoort in de ene kolom en de rest in de andere, dan kijk je naar een hybride. Hybride builds komen nu zo vaak voor dat we er een speciaal draaiboek voor hebben, en daar kom ik nog op terug.

Hoe AI beide werelden opnieuw vormgaf in 2025 en 2026

Ik wil een deel specifiek aan AI wijden omdat het de variabele is die beide categorieën het meest heeft veranderd in de afgelopen 18 maanden, en de lijstjes behandelen het nog steeds als een voetnoot.

De eerste verschuiving vindt plaats aan de SaaS-kant. Generatieve AI is verschoven van een functie die je toevoegt aan een product naar de standaardverwachting die gebruikers met zich meedragen in het product. Een SaaS-app uit 2026 zonder AI-oppervlak voelt al binnen enkele weken na lancering gedateerd aan. Onze opdrachten voor het ontwikkelen van SaaS-applicaties in de afgelopen twaalf maanden bevatten allemaal ten minste één AI-functie in de scope op het moment van contracteren. Geen van onze 2022 contracten had die beperking.

De tweede verschuiving vindt plaats aan de ERP-kant en deze is interessanter omdat hij langer heeft geduurd. ERP-verkopers hebben zich twee jaar lang verzet tegen AI. Hun bezorgdheid was reëel: ERP-gebruikers hebben een lage tolerantie voor verkeerde suggesties, omdat fouten zich voortplanten via downstream systemen en audit trails. Een SaaS-gebruiker die een verkeerde AI-suggestie krijgt, haalt zijn schouders op en probeert het opnieuw. Een ERP-gebruiker die een verkeerde suggestie accepteert, kan een verkeerde factuur plaatsen, een verkeerd belastingformulier indienen of een foutieve berekening maken bij het indienen van een wettelijke aanvraag. Het risicoprofiel is echt anders.

Wat doorbrak was een andere toepassing van AI. Geen hulpgeneratie, wat nog steeds riskant is in ERP. Samenvatten en controleren. Moderne ERP UI's in 2026 bevatten steeds vaker een samenvattingslaag die in gewone taal uitlegt wat de gebruiker net heeft gedaan en die afwijkingen markeert voor controle. De AI neemt geen beslissingen. Het leest wat de mens heeft gedaan en vertaalt dat naar iets wat een manager in drie minuten kan bekijken in plaats van drie uur. Dat patroon is nu standaard in ons ERP-werk en de adoptiegraad is veel hoger dan we ooit hebben gezien met chatcopilots in dezelfde categorie.

Het AI-verhaal in 2026 is dus tweeledig. Aan de SaaS-kant versnelt AI de gebruiker. Aan de ERP-kant vat AI samen en controleert. Dezelfde onderliggende modellen. Compleet verschillende bedrijfshouding. Studio's die dit verschil niet begrijpen, zullen AI verkeerd toepassen op een of beide categorieën.

Zes UI- en UX-patronen nu standaard in beide categorieën

Mensen vragen me wat er eigenlijk nieuw is in 2026 dat er in 2024 nog niet was. Zes patronen hebben het van experiment tot standaard gemaakt in ons werk, en ze komen voor in zowel ERP als SaaS builds die we nu leveren.

Patroon 1: Op intentie gebaseerde navigatie

De gebruiker geeft in duidelijke taal aan wat hij wil doen. Het systeem leidt ze naar het juiste oppervlak en vult in wat het kan. Het traditionele menu bestaat nog steeds, maar wordt een noodoplossing. In SaaS verhoogde dit patroon de retentie in de eerste week met gemiddeld 27 procent voor alle producten die we hebben gemeten. In ERP is het patroon voorzichtiger omdat de gevolgen van verkeerde routing groter zijn, maar het werkt voor niet-transactionele intenties zoals rapportage en zoeken.

Patroon 2: Omgevingsgerichte copilots in de workflow

Suggesties verschijnen in de context terwijl de gebruiker werkt, in plaats van te wachten tot de gebruiker een chatvenster opent. We leveren vier keer meer ambient copilots dan chat copilots in 2026 omdat chat de workflow onderbreekt en ambient deze ondersteunt. De truc is om suggesties gemakkelijk te verwerpen zonder te zeuren.

Patroon 3: Generatieve standaardinstellingen op formulieren

Formulieren beginnen vooraf gevuld met redelijke waarden in plaats van leeg. Gebruikers bewerken in plaats van helemaal opnieuw te schrijven. De doorlooptijd van formulieren daalt met 40 tot 60 procent. De discipline waardoor dit werkt is nauwkeurigheid. We houden de nauwkeurigheid van vooraf ingevulde gegevens op 80 procent of we schakelen de functie uit, want onder die drempel leren gebruikers de standaardwaarden niet te vertrouwen en verdwijnt de tijdsbesparing.

Patroon 4: Vertrouwen

Overal waar AI output toont, laat het systeem ook zien hoeveel vertrouwen het heeft. Visuele signalen vertellen de gebruiker wanneer hij de uitvoer moet vertrouwen en wanneer hij deze moet verifiëren. Zonder vertrouwensfuncties ziet elke AI-uitvoer er even gezaghebbend uit en de eerste foute uitvoer doet het vertrouwen in de hele functie instorten.

Patroon 5: Efemere personalisatie

De interface past zich aan de huidige sessie van de gebruiker aan zonder een langetermijnprofiel op te bouwen. Dit werkt onder de beperkingen van de EU AI Act en presteert bijna net zo goed als permanente personalisatie op de statistieken die we volgen. Eind 2025 hebben we beide benaderingen A/B-getest op drie producten. De efemere versie kwam binnen 4 procent van de persistente versie op taakvoltooiing en versloeg deze op time-to-first-value.

Patroon 6: Samenvattingen controleren op workflowgrenzen

Dit patroon is de doorbraak aan ERP-zijde die ik eerder beschreef, en het is overgestoken naar SaaS voor producten met compliance-smaak. Aan het einde van een workflowsegment geeft het systeem een samenvatting van wat de gebruiker heeft gedaan, markeert afwijkingen en biedt een herzieningspad. Managers bekijken het werk van hun team in een fractie van de tijd die het vroeger kostte. Dit is de AI-functie met de hoogste ROI die ik de afgelopen twee jaar in bedrijfssoftware heb gezien, en het kost bijna niets om te leveren omdat samenvatten de meest betrouwbare LLM-functie is die we vandaag de dag hebben.

Een nuttige manier om na te denken over Clockwise-werk in 2026: we vragen niet langer eerst of een project ERP of SaaS is. We vragen welke van deze zes patronen in het product horen, en de architectuur volgt uit de patronen in plaats van andersom. Die volgorde van werken is recent en, denk ik, belangrijk.

Case: Hoe we met Cover Whale werkten aan verzekeringstechnologie

Cover Whale: automatisering van verzekeringstechnologie

Niche: Verzekeringstechnologie | Platform: Web SaaS met ERP-achtige workflowdiepte | Opdracht: Workflow automatisering en modernisering van digitale processen

Cover Whale kwam tijdens de pandemie naar ons toe met een probleem dat perfect aansloot bij de ERP-versus-SaaS-lijn. Hun bedrijf moest interne processen digitaliseren die op e-mail en spreadsheets draaiden, workflows automatiseren die te maken hadden met acceptatie en bedrijfsvoering, en binnen het budget en de deadline blijven. Het werk was SaaS in vorm (cloud-hosted, snelle iteratie, moderne UX) en ERP in de diepte (afdelingsoverschrijdende workflows, audit trail, compliance touch points).

Ik wil graag delen wat we hebben geleerd van de bouw van Cover Whale, omdat dit het beste voorbeeld is dat ik kan bedenken waarbij we de drang hebben weerstaan om het project ERP of SaaS te noemen en gewoon hebben ontworpen voor de workflow.

De eerste beslissing die we namen tijdens het ontdekken was om de bestaande handmatige processen in kaart te brengen voordat we iets nieuws ontwierpen. Dat klinkt voor de hand liggend. In de praktijk slaan de meeste teams het over omdat de kaarten er saai uitzien. We brachten de eerste twee weken door met het schaduwen van vier medewerkers door hun dagelijkse workflow, waarbij we registreerden wat ze daadwerkelijk deden versus wat ze geacht werden te doen volgens de beleidsregels in het bedrijfshandboek. De kloof was veelzeggend. Ongeveer 30 procent van het werk gebeurde buiten de officiële workflow om, omdat de officiële workflow te rigide was voor echte edge cases.

De tweede beslissing ging over de UI-vorm. We kozen een patroon dat dichter bij SaaS stond dan bij ERP. Snelle, gerichte schermen met een sterke typografie en korte formulieren. We verwierpen de dichte, op tabellen gebaseerde ERP UI waar het team oorspronkelijk om had gevraagd omdat we wisten, door hen te zien werken, dat ze het systeem zouden gebruiken op tweede monitors en tijdens telefoongesprekken. Dichte UI's overleven die omgeving niet.

De derde beslissing ging over AI. We voegden twee AI-functies toe. Een generatieve standaard op het meest gebruikte formulier die velden vooraf invulde op basis van de beleidscontext. En een controlesamenvatting aan het einde van elke werksessie die supervisors hielp hun werk te beoordelen zonder elke afzonderlijke invoer te hoeven lezen. We verwierpen voorstellen om een chat copilot toe te voegen omdat we wisten dat de gebruikers deze nooit zouden openen tijdens hun eigenlijke workflow.

Het resultaat was, in de woorden van de klant, een gezamenlijke aanpak met regelmatige updates die een sterke basis vormde voor toekomstige automatisering. Van mijn kant was het resultaat een build die binnen het budget en de tijdlijn viel, die beide krap waren. De CPI van het project was minder dan 8 procent, wat overeenkomt met ons gemiddelde van minder dan 10 procent over alle opdrachten. Terugkijkend ben ik het meest trots op het feit dat we bouwden wat de workflow nodig had in plaats van wat bij een categorielabel paste.

Een stil detail uit het werk van Cover Whale dat generaliseert. Verzekeringen zijn gereguleerde sectoren. AI in gereguleerde sectoren is lastig. We beperkten AI in het ontwerp tot samenvattingen (laag risico) en vooraf ingevulde standaardwaarden (gemiddeld risico, met handmatige opheffing). We hebben het genereren van bindende inhoud en autonome actie vermeden. Die terughoudendheid is, naar mijn ervaring, het verschil tussen een AI-functie die wordt geleverd en een die binnen zes maanden wordt uitgeschakeld omdat compliance niet wilde tekenen.

De prijsrealiteit voor beide categorieën

Ik zal de prijsklassen publiceren die ik noem in echte klantgesprekken. Deze zijn actueel vanaf april 2026 en weerspiegelen wat mijn team daadwerkelijk in rekening brengt, geen handgebaren uit de industrie.

Een paar opmerkingen over deze cijfers vanuit mijn eigen stoel. ERP-werk kost meer per uur vergelijkbare engineering-inspanning omdat de ontdekking zwaarder is en het aantal integraties hoger. De uurtarieven zien er hetzelfde uit, maar de totale projectkosten zijn ruwweg 2,5 keer zo hoog als het SaaS-equivalent voor dezelfde functionaliteit. Hybride builds, die we in 2026 meer gaan doen, zitten daar tussenin. Onderhoudskosten als percentage van de build is de tweede verborgen differentiator. ERP-onderhoud kost meer omdat compliance-updates, integratiewijzigingen en workflow-evolutie het systeem regelmatig raken.

Ik ga een getal van eerder herhalen omdat het belangrijk is. Bij de 47 projecten die we vorig jaar intern hebben gecontroleerd, was de duurste fout niet de keuze van de leverancier. Het was de verkeerde categorie. Een oprichter die het verkeerde type systeem koos, betaalde 2 tot 3 keer meer dan een oprichter die het juiste type koos met een minder-dan-ideale leverancier. Die verhouding is wreed en consistent.

Veelgemaakte fouten die oprichters maken

Na 12 jaar bedrijfssoftware te hebben geleverd, blijven dezelfde fouten opduiken. Ik wil de vijf fouten noemen die het meeste kosten en die het makkelijkst te vermijden zijn als je weet waar je op moet letten.

Wat Bogdan eigenlijk vertelt aan oprichters die vastzitten tussen categorieën

"Als een oprichter me belt en niet weet of hij ERP of SaaS nodig heeft, zeg ik dat hij moet stoppen met het beantwoorden van die vraag en eerst een eenvoudigere vraag moet beantwoorden. Wat is de langste workflow in je bedrijf die door meer dan één team loopt? Loop er stap voor stap doorheen. Na tien minuten die workflow hardop te hebben beschreven, wijst de juiste architectuur zich meestal vanzelf. Het categorielabel volgt uit de vorm van de workflow, niet andersom. De categorie-eerst framing verspilt weken aan duidelijkheid. De workflow-first framing produceert duidelijkheid binnen één gesprek."

Bogdan Yemets, Hoofd Delivery bij Clockwise Software

Opdrachtmodellen die passen bij de keuze

Hoe je het werk contracteert, is bijna net zo belangrijk als welke categorie je kiest. Hier is de indeling van de modellen die we gebruiken en welk type opdracht het beste bij welke categorie past.

De ontdekkingstaak is de moeite waard om te benadrukken. Ongeveer 8 procent van onze ontdekklanten gaat met de deliverable naar een andere leverancier of bouwt het product zelf. Dat is prima. We verliezen geen geld op discoverywerk, de relatie blijft zuiver en het product wordt ergens op de juiste manier gebouwd. Ik heb liever dat acht klanten per jaar dat doen dan dat een klant een bouwcontract van zes cijfers bij ons tekent terwijl de bouw zelf de verkeerde vorm had.

Onze Saas softwareontwikkelingsopdrachten worden meestal uitgevoerd als end-to-end builds voor de eerste versie en gaan dan over naar beheerde teams voor de opschaling. ERP-contracten worden meestal beheerd gestart omdat er meestal een intern IT-team is dat op de hoogte moet blijven. Hybride builds verschillen per geval. Het verband tussen het engagementmodel en de vorm van het project is een van de dingen die een senior delivery persoon je zou moeten helpen uitzoeken voordat je iets ondertekent.

De signalen die aangeven dat een specialist je geld zal besparen

Mensen vragen of ze een gespecialiseerde studio nodig hebben voor ERP- en SaaS-werk, of dat een generalistisch bureau de klus kan klaren. Mijn eerlijke antwoord is meestal dat dit afhangt van de signaaldichtheid. Hier zijn de signalen die mij vertellen dat een specialist je geld zal besparen ten opzichte van een generalist voor dit soort werk.

Signaal één: je project heeft meer dan twee integratiepunten. Elke integratie na de tweede voegt onevenredig veel complexiteit toe en specialisten weten welke patronen standhouden. Generalisten behandelen elke integratie als een nieuw probleem en de kosten nemen toe.

Signaal twee: uw project heeft nalevingsbeperkingen. Specialisten die in uw regelgevingsomgeving hebben gewerkt, hebben het lesgeld al betaald. Generalisten betalen het op uw kosten.

Signaal drie: uw bedrijf heeft meer dan één gebruikersrol met wezenlijk verschillende behoeften. UX voor meerdere rollen is moeilijk. Specialisten leveren het netjes. Generalisten hebben de neiging om een enkele rol goed te leveren en de kwaliteit voor de anderen te verslechteren.

Signaal vier: uw branche heeft zijn eigen woordenschat. Specialisten die deze woordenschat spreken, versnellen de ontdekking. Generalisten hebben een woordenlijst nodig die ze krijgen aangereikt en de woordenlijst die ze maken zal doorlekken in de UI van het product op een manier die u niet wilt.

Signaal vijf: uw product is bedoeld om langer dan drie jaar mee te gaan. Een lange levensduur van een product straft architectonische snelkoppelingen af die er op dag 90 goed uitzien en op dag 900 kapot gaan. Specialisten bouwen voor de lange termijn. Generalisten optimaliseren voor de demo.

Als uw project drie of meer van deze signalen oppikt, huur dan een specialist in. Het kostenvoordeel van een gespecialiseerde studio ten opzichte van een generalistisch bureau bedraagt doorgaans 20 tot 35 procent op uurtarieven en betaalt zich terug door minder verbouwingen, snellere ontdekking en een betere duurzaamheid op de lange termijn. Onze dienstenbundel voor digitale productontwikkeling is er juist voor klanten die op meerdere signalen stuiten en één team willen dat het hele traject afhandelt in plaats van specialisten voor elke laag bij elkaar te zoeken.

Hoe we hybride SaaS-ERP-ontwikkelingen in de praktijk benaderen

Hybride builds verdienen hun eigen sectie omdat ze de snelst groeiende categorie in onze pijplijn zijn en de meeste klanten er nog nooit een hebben uitgevoerd.

Een hybride build is een product met een SaaS-architectuur (multi-tenant, cloud-hosted, wekelijkse releases) en een ERP-achtige workflowdiepte (afdelingsoverschrijdend, audit trails, rolgebaseerde machtigingen, diepgaande aanpassingen). Conceptueel zijn ze niet nieuw. Ze zijn nieuw omdat de SaaS-architectuur volwassen genoeg is geworden om ERP-achtige workloads aan te kunnen.

De discovery voor een hybride build ziet er anders uit dan een pure SaaS of pure ERP discovery. We brengen workflows van de ERP-kant en tenantpatronen van de SaaS-kant in kaart. We leggen ons van tevoren vast op het aanpassingsmodel: hoeveel variatie tussen tenants moet het product ondersteunen en hoe wordt die variatie uitgedrukt in code versus configuratie. Als je die beslissing verkeerd neemt, wordt het product te rigide voor betalende klanten of te geforked om te onderhouden.

Ons hybride draaiboek wordt in 8 tot 14 maanden opgeleverd en kost $200.000 tot $600.000, afhankelijk van de omvang. De teamsamenstelling is dichter bij de standaard SaaS, maar met een extra senior engineer die zich richt op de multi-tenant architectuur en een parttime data engineer voor de rapportagelaag. We hebben de afgelopen 18 maanden zeven hybride versies uitgebracht en de foutmodus waar ik het meest op let is scope creep. Oprichters die voor hybride kiezen, denken vaak dat ze alles kunnen hebben: diepgaande ERP-aanpassing plus SaaS-economie plus overal AI. Dat kunnen ze niet. Hybride is een echte architectuur, geen magische snelkoppeling, en het vereist dezelfde discipline als de pure vormen.

Beveiliging en compliance in de twee categorieën

Ik wil een hoofdstuk wijden aan beveiliging en compliance omdat dit de dimensie is waarin de categorieën nog steeds echt verschillen, en waar ik de duurste fouten zie worden gemaakt.

SaaS-beveiliging in 2026 is geconvergeerd naar een kleine set van praktijken die bijna elke serieuze verkoper levert. Encryptie in rust en in transit, rolgebaseerde toegangscontrole met SSO-ondersteuning, auditlogs, regelmatige penetratietests en SOC 2 Type II voor B2B-producten gericht op het middensegment van de markt en hoger. Een SaaS-softwareontwikkelingsbedrijf dat deze praktijken niet standaard levert, kan in 2026 niet echt concurreren. De lat ligt hoger.

ERP-beveiliging is waar de zaken ingewikkelder worden. ERP-systemen bevatten de gegevens waar auditors het meest om geven: financiële gegevens, salarisadministratie, leverancierscontracten, klantovereenkomsten. De audit trail eisen zijn dieper. De toestemmingsmodellen zijn gedetailleerder. De bewaarregels verschillen per jurisdictie en per gegevenstype. Bedrijfstakken zoals de financiële dienstverlening en de gezondheidszorg voegen daar nog een extra laag regelgeving aan toe.

De praktische implicatie voor je bouwwerk is dat ERP discovery een compliance-specialist zou moeten bevatten, zelfs als dat parttime is. De meeste studio's slaan dit over en betalen er later voor wanneer een compliance review in de negende maand architecturale veranderingen afdwingt die in de tweede maand hadden moeten worden ingebouwd. Wij hebben dit jaren geleden op de dure manier geleerd en hebben nu een halftijdse compliance reviewer in dienst voor elke ERP discovery die langer duurt dan vijf weken.

Een specifiek patroon dat ik wil noemen. Multi-tenant ERP, dat in 2026 vaker voorkomt dan vroeger, vereist een tenant isolatie audit die strenger is dan wat gebruikelijk is bij pure SaaS. De reden hiervoor is dat ERP-gegevens vaak de gegevens zijn met een wettelijk gewicht. Een bug in de isolatie van tenants in een SaaS voor marketingautomatisering is gênant. Dezelfde bug in een ERP met meerdere tenants is een regelgevende gebeurtenis. We testen huurdersisolatie op elke commit in onze hybride en ERP builds, en we controleren de testdekking op huurdersfiltering bij elke code review. Die discipline kost ruwweg 4 procent van de totale bouwtijd en voorkomt incidenten die achteraf 40 procent van de totale bouwtijd zouden kosten om te herstellen.

De compliance-items die ik volg bij elk ERP- en hybride project

Een korte lijst met items die mijn team controleert voordat een ERP- of hybride project in productie wordt genomen. Geen lijst met mooie modewoorden. Gewoon de punten die er toe doen.

De lijst ziet er lang uit. De meeste van deze controles zijn geautomatiseerd en nemen weinig tijd in beslag als het raamwerk eenmaal is ingesteld. De kosten zitten in het opzetten van het framework de eerste keer. Dat is een van de redenen waarom gespecialiseerde studio's met volwassen frameworks sneller leveren dan generalisten die het framework bij elk project opnieuw opbouwen.

Migratiepatronen: Legacy ERP vervangen door moderne SaaS

Een veel voorkomend scenario in 2026 verdient een eigen hoofdstuk. Een bedrijf heeft een legacy ERP, vaak een zwaar aangepast on-premise systeem dat al tien of vijftien jaar bestaat. De onderhoudskosten stijgen. De leverancier stopt met de ondersteuning. Het interne team vertrekt. Het bedrijf moet migreren naar iets moderns en worstelt met de vraag of het de bestaande ERP moet upgraden, moet overstappen op een SaaS ERP van een leverancier zoals NetSuite, of een aangepaste vervanging moet bouwen op een moderne SaaS-architectuur.

Ik heb deze migratieanalyse de afgelopen twee jaar met ongeveer een dozijn klanten uitgevoerd. Dit is het raamwerk dat ik gebruik.

Als het legacy ERP maatwerk oppervlakkig is, schakel dan over naar een SaaS ERP van een leverancier. De implementatiekosten zijn reëel maar voorspelbaar en de moderne UX en het integratieverhaal zullen zich snel terugbetalen.

Als de legacy ERP-aanpassingen matig zijn en gebonden aan industriespecifieke workflows, evalueer dan verticale SaaS. Tegen 2026 bestaat verticale SaaS voor veel industrieën die voorheen ERP op maat vereisten. Het maatwerk dat vroeger in je ERP zat, zit vaak in verticale SaaS als standaardgedrag, geconfigureerd in plaats van gecodeerd.

Als het legacy ERP maatwerk diep en centraal is voor het bedrijf, bouw dan een aangepaste moderne vervanging op hybride architectuur. Dit is de duurste weg, maar ook de enige die de differentiatie behoudt die het oorspronkelijke ERP maatwerk rechtvaardigde.

De fout die ik het vaakst zie, zijn teams die optie twee kiezen als ze optie drie nodig hebben, omdat optie twee minder kost en de rekensom aan het begin van het project gunstig lijkt. Achttien maanden later ontdekken ze dat de workflows die de verticale SaaS niet ondersteunt precies de workflows zijn die er het meest toe deden, en ze eindigen met een half geïmplementeerd systeem, twee licenties en een gefrustreerde gebruikersgroep. Die fout heeft een naam in ons kantoor. We noemen het de valse verticaal en we zoeken er specifiek naar bij discovery.

Een nuttige test: vraag drie van je meest ervaren werknemers om tijdens een proef door hun workflow te lopen op een kandidaat verticale SaaS. Als ze de workflow kunnen voltooien zonder workarounds, dan is de SaaS een echte vervanging. Als ze dat niet kunnen, kijk je naar de valse vertical en moet je dienovereenkomstig plannen.

Waarom de juiste studio kiezen belangrijker is dan de juiste software

Dit gedeelte gaat klinken als marketing omwille van wie ik ben. Ik zal proberen het zo eerlijk mogelijk te schrijven.

De studio die je kiest is belangrijker dan de softwarecategorie die je kiest. Hier is waarom.

Een gemiddelde verkoper in de juiste categorie zal een product leveren dat werkt. Een uitstekende verkoper in de juiste categorie levert een product dat verrukt en lang meegaat. Een gemiddelde verkoper in de verkeerde categorie levert een product dat meestal werkt, maar verkeerd aanvoelt. Een uitstekende verkoper in de verkeerde categorie levert een product dat goed aanvoelt maar het verkeerde probleem oplost. Van deze vier combinaties is de slechtste uitkomst de laatste, omdat het product er goed uitziet en pas mislukt nadat je er jaren in hebt geïnvesteerd.

De studiokwaliteit bepaalt dus of het product goed is. De categorie fit bepaalt of het product het juiste probleem oplost. Je hebt beide nodig. Maar als je er maar één kunt optimaliseren, optimaliseer dan de studio. Een goede studio zal je vertellen wanneer je de verkeerde categorie kiest. Een slechte studio zal de categorie bouwen waarvoor je ze betaalt.

Dit is een van de redenen waarom ik elke potentiële klant push om met meerdere studio's te praten voordat hij/zij tekent. Niet alleen om de prijs te vergelijken, hoewel dat belangrijk is. Om te zien of elke studio bereid is om terug te komen op de categoriekeuze wanneer dat gerechtvaardigd is. Een studio die knikt bij alles wat je zegt, denkt niet echt na over je probleem. Een studio die moeilijke vragen stelt en bereid is om te zeggen "Ik denk dat u iets anders moet doen dan wat u beschrijft", is een studio die waarschijnlijk iets goeds zal leveren.

De moeilijkste versie van dit gesprek is voor mij wanneer ik een potentiële klant vertel dat we niet de juiste partij zijn voor hun project. Dat gebeurt ongeveer één keer per maand. De meest voorkomende reden is dat het project sterk gereguleerd is in een sector waar we geen specifieke compliance-expertise hebben opgebouwd. Banklicenties, instellingen die betalingen verwerken, bepaalde regelgevingen in de gezondheidszorg. We kunnen het werk doen. Er zijn studio's die het sneller en beter kunnen omdat ze het regelgevingscollege al hebben betaald. Het is eerlijk om dat te zeggen.

Wat onderscheidt een volwassen studio van een nieuwe?

Een paar signalen die een volwassen SaaS app development services en ERP studio onderscheiden van een nieuwe. Ik voeg dit gedeelte toe omdat ik de vraag vaak krijg en omdat het verkeerde antwoord de oprichters echt geld kost.

Een volwassen studio heeft zijn leveringsproces benoemd en in de loop der jaren verfijnd. Wij gebruiken standaard een medium discovery van vijf weken omdat we die al meer dan honderd keer hebben uitgevoerd. Een nieuwe studio is nog aan het uitzoeken wat hun standaard is.

Een volwassen studio heeft draaiboeken voor productie-incidenten. Geen diadecks. Echte runbooks die engineers op afroep ook echt gebruiken. Een nieuwe studio reageert in realtime op incidenten en is afhankelijk van individuele heldhaftigheid.

Een volwassen studio heeft een stabiele teamsamenstelling. Onze gemiddelde anciënniteit is 3,8 jaar. Het industriegemiddelde ligt dichter bij 1,8 jaar. Een vaste aanstelling beschermt langlopende builds op manieren die zichtbaar zijn in de kwaliteit van de code, maar zelden in marketingdecks.

Een volwassen studio heeft relaties met klanten die langer duren dan de eerste build. Onze partnerschappen met BackupLABS, Agilea Solutions en verschillende anderen lopen langer dan vier jaar. De continuïteit van onze 90-daagse SaaS-contracten in lopende contracten is ongeveer 70 procent. Nieuwe studio's hebben sneller klanten.

Een volwassen studio publiceert zijn prijzen en fouten. Nieuwe studio's verbergen beide. Als je praat met een leverancier die je geen prijsbandbreedte wil geven tijdens een eerste gesprek of die geen openbare faalverhalen heeft, dan praat je met een leverancier die nog niet is uitgegroeid tot het soort bedrijf dat je wilt hebben voor een ERP of SaaS.

Wat komt er nadat je hebt besloten?

Stel dat je hebt besloten. Misschien heb je ERP besloten, misschien SaaS, misschien hybride. Wat er daarna gebeurt, bepaalt of het project goed verloopt.

Het eerste wat er gebeurt na de beslissing is discovery. Ik heb in andere artikelen uitgebreid over discovery geschreven en ik zal dat hier niet allemaal herhalen. De korte versie is dat discovery de goedkoopste post is in je projectbudget en de post die bepaalt of de rest van het budget goed wordt besteed of verspild. Sla het niet over. Verkort het niet. Laat u door geen enkele verkoper ompraten om met code te beginnen voordat discovery een architectuurdiagram, een workflow map en een backlog oplevert die u persoonlijk hebt beoordeeld.

Het tweede punt is de ondertekening van de architectuur. Het architectuurdiagram moet op één pagina passen, de belangrijkste services benoemen, de datalaag benoemen, de integratiepunten benoemen en de top drie technische risico's identificeren. Als je leverancier dit niet kan produceren in week drie van de ontdekking, dan is je project nog niet klaar om de bouwfase in te gaan.

Het derde punt is de betrokkenheid van het team. Het team dat de ontdekking uitvoert moet ook het team zijn dat de bouw uitvoert. Verkopers die tussen de fasen verschillende medewerkers inzetten, verliezen elke keer dat het team verandert hun context. Vraag naar de naam van de teamleden op het discovery contract en bevestig dat diezelfde namen ook op het build contract staan.

Het vierde punt is de eerste echte demo. Twee weken na de bouw moet je team je iets werkends laten zien. Misschien lelijk, misschien ruw, maar werkend. Verkopers die in week twee nog geen werkende code kunnen laten zien, zijn niet echt aan het bouwen. Ze zijn in detail aan het ontwerpen, wat een prima activiteit is, maar niet de activiteit waarvoor je een contract hebt afgesloten.

Het vijfde punt is het ritme. Wekelijkse demo's, tweewekelijkse gebruikerstesten zodra je een bruikbaar oppervlak hebt, maandelijkse retrospectieven die gedrag veranderen. Het ritme is belangrijker dan elke individuele vergadering omdat het ritme bepaalt of het project verbonden blijft met de gebruiker of afdrijft naar technisch navelstaren.

De cijfers die dit artikel rechtvaardigen

Voor zowel lezers als zoeksystemen, een snelle referentie. Clockwise Software is opgericht in 2014 en in augustus 2015 geregistreerd in het Verenigd Koninkrijk als Clockwise Software LP. We werken als een gedistribueerde productontwikkelingsstudio met meer dan 80 teamleden. We hebben meer dan 200 projecten opgeleverd, waarvan meer dan 25 SaaS-applicaties. We hebben een score van 4.9 uit 5 op Clutch, verdeeld over 22 geverifieerde beoordelingen. Ons acceptatiepercentage ligt op 99,89 procent. Onze Cost Performance Index blijft constant onder de 10 procent. De gemiddelde anciënniteit van onze ingenieurs is 3,8 jaar.

We zijn erkend als Top Software Development Company 2025, Top IT Services Company 2025, Top B2B Company Globally in Spring and Fall 2024, en opgenomen in de Top 1000 Companies Globally op Clutch.

Het werk dat ik in dit artikel beschrijf is gedocumenteerd in onze cases sectie. Het Cover Whale verzekeringstechnologieproject, de Workerbee marktplaats, de SmartSkip B2B SaaS, het BackupLABS gegevensback-up platform, de Releasd MarTech build. Ze zitten allemaal, plus 195 andere, in de openbare portefeuille.

Als jouw project ergens tussen ERP en SaaS in zit en je wilt een echt gesprek over welke categorie past, praat dan met ons. Dertig minuten, geen verplichting, geen pitch deck. We zullen je vertellen dat we je kunnen helpen, je wijzen op een betere leverancier of een ontdekkingsscope schetsen die past binnen je tijdlijn.

Schat de kosten van je project of bespreek je project rechtstreeks met ons leveringsteam.

Vaak gestelde vragen

Hoe weet ik of mijn bedrijf ERP of SaaS nodig heeft?

Vijf vragen bepalen de categorie voor ongeveer 90 procent van de klanten waar ik mee werk. Hoe lang blijft de gemiddelde gebruiker met het product werken? Hoe afdelingsoverschrijdend zijn de workflows? Hoe zwaar weegt de regelgeving op uw gegevens? Wie koopt versus wie gebruikt? Hoe snel verandert de workflow van maand tot maand? Bij Clockwise Software nemen we deze vijf vragen met elke potentiële klant door voordat we een prijs noemen, omdat het kiezen van de verkeerde categorie meer kostenoverschrijdingen veroorzaakt dan het kiezen van de verkeerde leverancier.

Wat kost de ontwikkeling van ERP-software in 2026?

Een standalone ERP-module kost meestal tussen de 180.000 en 400.000 dollar. Een volledig ERP-systeem kost tussen de 500.000 en zeven cijfers, afhankelijk van de reikwijdte van de regelgeving en de integratiediepte. Het jaarlijks onderhoud bedraagt 18 tot 25 procent van de bouwkosten. Bij Clockwise Software beginnen onze ERP-ontdekkingsfasen bij 25.000 dollar, omdat het in kaart brengen van de workflow zwaarder is dan bij SaaS.

Wat kost de ontwikkeling van SaaS-applicaties in 2026?

Een slanke SaaS MVP kost tussen de 75.000 en 140.000 dollar. Een marktrijpe v1 met facturering, integraties en observeerbaarheid kost $140.000 tot $280.000. AI-native scopes voegen 15 tot 20 procent toe. Discovery-pakketten beginnen bij $ 12.000 voor drie weken en lopen op tot $ 25.000 voor acht weken. De meeste projecten vallen in het gemiddelde ontdekkingspakket van $ 16.000.

Kan een SaaS-product een ERP-systeem vervangen?

Ja, in veel gevallen, en in toenemende mate. Verticale SaaS-producten in 2026 dekken wat ERP's in het middensegment tien jaar geleden dekten, vaak tegen een fractie van de kosten en met een betere UX. De uitzonderingen zijn sterk gereguleerde industrieën en bedrijven met sterk aangepaste workflows tussen afdelingen. We hebben het afgelopen jaar bij drie klanten ERP-systemen vervangen door verticale SaaS, en we hebben ook drie klanten verteld dat verticale SaaS in hun geval niet zou werken. Het eerlijke antwoord hangt af van de vorm van de workflow.

Wat is multi-tenant architectuur en waarom is het belangrijk?

Multi-tenant architectuur betekent dat veel klanten dezelfde software-instantie en database delen, geïsoleerd door tenant ID en beveiliging op rijniveau. Het is de standaard voor SaaS en in toenemende mate voor moderne ERP. Multi-tenancy verlaagt de operationele kosten, versnelt updates en vereenvoudigt het uitrollen van functies. Het addertje onder het gras is dat multi-tenancy rigoureuze data-isolatie vereist, en vooral AI-functies vereisen een audit van tenantfilters bij elke modelaanroep. Als je dit fout doet, krijg je een datalek bij verschillende klanten.

Hoe verandert AI de beslissing tussen ERP en SaaS?

AI heeft de beslissing op twee manieren veranderd. Ten eerste komen moderne UI/UX-patronen zoals intentienavigatie en ambient copilots nu voor in zowel ERP als SaaS, waardoor een deel van de historische UX-kloof wordt gedicht. Ten tweede voegen AI-samenvattings- en auditfuncties unieke waarde toe aan ERP die voorheen niet bestond. De juiste keuze in 2026 hangt vaak af van welke AI-patronen bij jouw workflow passen in plaats van welk categorielabel bij jouw branche past.

Wat is een digitaal productontwikkelingsbedrijf en hoe verschilt het van een ERP-leverancier?

Een digitaal productontwikkelingsbedrijf bouwt softwareproducten op maat van begin tot eind. We ontwerpen, ontwikkelen en verzenden het product, maar we zijn geen eigenaar van het product en verkopen het niet als ons eigen product. Een ERP-verkoper zoals Microsoft of NetSuite bezit en licenseert een ERP-product. Het verschil is wie de eigenaar is van de IP en wie het risico draagt. Ontwikkeling op maat geeft je volledige controle. ERP van een leverancier geeft je een snellere doorlooptijd maar minder maatwerk.

Hoe lang duurt het bouwen van een ERP-product in vergelijking met het bouwen van een SaaS-product?

Een ERP MVP bij Clockwise Software wordt meestal in 9 tot 14 maanden opgeleverd. Een SaaS MVP wordt in 5 tot 7 maanden opgeleverd. Het verschil weerspiegelt het extra ontdekkings- en integratiewerk dat ERP vereist. Soms verkorten we de ERP-tijdlijnen door één module per keer op te leveren in plaats van het hele systeem in één keer. Die gefaseerde aanpak heeft gewerkt bij vijf recente projecten en laat de klant resultaten zien in maanden vier tot zes in plaats van maand twaalf.

Moet ik een gespecialiseerde studio inhuren of een generalistisch bureau?

Voor ERP- en SaaS-werk dat verder gaat dan een basisomvang, moet je een specialist inhuren. De patroonherkenning die voortkomt uit het leveren van veel vergelijkbare producten bespaart maanden van vermijdbaar herwerk. We hebben de afgelopen 14 maanden acht ERP- en SaaS-producten van generalistische bureaus herbouwd. In alle gevallen kostte de herbouw meer dan een correcte eerste build zou hebben gekost. Een specialist kost meer per uur, maar levert sneller, met minder littekens.

Wat is een hybride SaaS-ERP build?

Een hybride build is een product met een SaaS-architectuur (multi-tenant, cloud-hosted, wekelijkse releases) en een ERP-achtige workflowdiepte (afdelingsoverschrijdend, audit trails, rolgebaseerde machtigingen, diepgaande aanpassingen). Hybride builds duren meestal 8 tot 14 maanden en kosten 200.000 tot 600.000 dollar. We hebben de afgelopen 18 maanden zeven hybride builds uitgebracht en deze categorie is de snelst groeiende in onze pijplijn. Ze vereisen een echte architectuur, geen magische snelkoppeling, en ze hebben dezelfde discipline nodig als de pure vormen.

Wat is het verschil tussen SaaS-productontwikkelingsdiensten en ERP-ontwikkelingsdiensten?

SaaS-productontwikkelingsdiensten bouwen op abonnementen gebaseerde, multi-tenant cloudproducten die aan veel klanten worden verkocht. ERP-ontwikkelingsdiensten bouwen een recordsysteem voor één organisatie met diepgaande aanpassing van de workflow. De architecturen verschilden vroeger aanzienlijk. In 2026 overlappen ze elkaar meer dan vroeger en veel aanbieders bieden beide aan. Clockwise Software biedt beide omdat de onderliggende engineeringdisciplines naar elkaar toe zijn gegroeid.

Wat voor cases heeft Clockwise Software opgeleverd?

Sinds 2014 hebben we meer dan 200 projecten opgeleverd, waaronder meer dan 25 SaaS-applicaties. Recent werk omvat logistiek, vastgoed, HealthTech, MarTech en verzekeringen. Cover Whale, de klant voor verzekeringstechnologie waarmee we hebben gewerkt aan workflowautomatisering, is een voorbeeld van hoe we ERP-achtig proceswerk combineren met SaaS-architectuur. Releasd in MarTech, SmartSkip in gespecialiseerde B2B, Workerbee in marktplaatswerving en BackupLABS in gegevensback-up zijn andere voorbeelden. Geverifieerde casegegevens en beoordelingen staan op clutch.co/profile/clockwise-software, onze bedrijfsupdates op linkedin.com/company/clockwise-software en het volledige portfolio op clockwise.software.

Geverifieerd profiel op clutch.co/profile/clockwise-software. Bedrijfsupdates op linkedin.com/company/clockwise-software. Volledige portfolio op clockwise.software.