DEV Community: Thomas van den Berg

De smaak van AI

Thomas van den Berg — Sun, 05 Jul 2026 15:08:00 +0000

Wij maken veel gebruik van AI bij het ontwerpen en bouwen van producten. Voor code, voor designs, voor het uitproberen van richtingen. Het versnelt alles, maar één ding valt ons steeds meer op. Hoe meer AI genereert, hoe meer alles op elkaar gaat lijken. Het beweegt naar een veilige standaard die op het eerste gezicht best overtuigend is.

Middelmaat is goedkoop geworden. Misschien zelfs gratis. Vroeger kostte het veel moeite om iets te maken dat er redelijk uitzag en redelijk werkte. Die drempel is veel lager geworden. Voor sommige producten is dat niet erg, maar als je iets bijzonders wilt maken, is het een uitdaging.

            <p class="pullquote">Door AI is <span class="qhl">middelmaat</span> goedkoop. Daardoor wordt smaak juist schaars.</p>

Designen met AI

Als wij Claude vragen om designs te genereren, krijgen we vaak een prima basis. Een scherm met logische onderdelen en een strak design system, maar daarna begint het echte werk pas.

Het ontwerp heeft ons nodig om een richting te bepalen. Niet omdat wij de enigen zijn die dat kunnen, maar omdat het model geen smaak heeft in de menselijke zin van het woord. Het kan patronen combineren. Het kan voorbeelden nadoen en een nette oplossing maken voor een bekend probleem.

Wat het niet vanzelf doet is kiezen. Niet met een gevoel voor wat dit product moet zijn. Niet met begrip voor welke ervaring moet blijven hangen. Niet met de discipline om iets weg te laten omdat het de kern verzwakt. Zoals deze blog door AI is geschreven maar door ons geredigeerd ;-)

De standaard die eruit komt is competent en inwisselbaar. Het verschil zit in de keuzes daarna. Dat zijn geen cosmetische vragen maar productvragen. Ze bepalen of iets voelt als een verzameling onderdelen of als een ervaring die klopt.

Code is niet hetzelfde als een product

Wij zien het ook bij ontwikkelaars die met Claude in hun eentje hele apps bouwen. Technisch gezien indrukwekkend, maar dan komt het lastige deel. Gebruikers begrijpen het niet of willen het niet gebruiken. Een werkende app is nog geen goed product. Dat vraagt uiteraard om gebruiksonderzoek maar ook om instinct.

AI helpt bij het bouwen, maar dat is niet hetzelfde als begrijpen wat gebouwd moet worden. Een model kan opties geven. Het kan gaten vullen. Het kan een scherm afmaken. Maar het weet niet vanzelf waar de spanning zit. Daarom vinden wij de huidige AI-discussie vaak te plat. Er wordt veel gepraat over snelheid. Minder over smaak en ervaring. Terwijl snelheid zonder smaak vooral sneller meer van hetzelfde oplevert.

Wat schaarser wordt: product-instinct

Onze overtuiging is simpel. Bouwen wordt makkelijk. Smaak, oordeel en product-instinct worden schaarser. Smaak is getraind oordeel.

            <div class="aside aside-bare">

Product-instinct

Nieuwsgierigheid. Goede instincten beginnen bij nieuwsgierigheid naar hoe mensen denken en zich gedragen.
Populariteit begrijpen. Niet alleen zien dat een product populair of impopulair is, maar willen begrijpen waarom dat zo is.
Ontleden. De gewoonte om nieuwe producten uit elkaar te halen en te kijken welke keuzes eronder liggen.
Ervaring herkennen. Een oog ontwikkelen voor goede en slechte gebruikerservaringen, ook in kleine details.

Dat lijstje is nuttig omdat het product-instinct concreet maakt. Het is geen mysterieuze gave. Het is ook geen truc die in een middag uit een gereedschap komt. Het is jarenlange ervaring. Producten gebruiken. Mensen observeren. Fouten maken. Nog eens kijken. Begrijpen waarom iets op papier goed was en in de praktijk niet werkte.

Er zit een traagheid in die niet populair is. Zeker niet in een tijd waarin alles sneller moet. Maar sommige dingen worden niet beter doordat ze sneller ontstaan. Oordeel groeit door herhaling en aandacht.

Het werk dat overblijft

De vraag wordt minder: kan dit gemaakt worden. De vraag wordt: moet dit zo gemaakt worden. Is dit de juiste vorm. Is dit helder genoeg. Is dit onderscheidend genoeg. Voelt dit als iets dat iemand wil blijven gebruiken, of alleen als iets dat technisch bestaat. Deze vraag was altijd al belangrijk, maar wordt nu nog crucialer.

Daar zit onze expertise en daar zit voor ons het interessante werk. Niet in het produceren van zoveel mogelijk schermen. Niet in het laten zien dat er weer een app uit een prompt kan rollen. Dat weten we nu wel.

Het interessante werk zit in richting geven. In kiezen.

Gaat AI ook dit werk vervangen? En kun je product-instinct sneller ontwikkelen door het gebruik van AI? Wellicht. Wij zijn er zelf al mee aan het experimenteren en misschien komt er binnenkort een vervolg op deze blog. Tot die tijd blijft een getraind oordeel belangrijk.

Spec-driven development

Thomas van den Berg — Sun, 05 Jul 2026 15:07:57 +0000

Het knelpunt bij bouwen met AI is verschoven. Niet het typen van code houdt je tegen, maar weten wat je wilt bouwen. Voor wie, in welke volgorde, met welke edgecases. Dat klinkt simpel, tot je begint. Dan blijkt dat een product niet bestaat uit een mooi hoofdscherm maar uit keuzes. Wat ziet iemand zonder data? Wat gebeurt er als de API traag is? Welke knop krijgt focus na een mislukte betaling? Wat mag de AI nooit zelf invullen?

Met vibe coding kom je een eind: je prompt, kijkt wat eruit komt en stuurt bij. Voor een demo werkt dat. Voor een product loop je vast. De AI raadt, jij corrigeert, de chat wordt langer en na tien rondes weet niemand meer welke beslissing leidend was.

Eerst de spec, dan de code

Spec-driven development draait die volgorde om. Eerst schrijf je de spec, daarna komt de code eruit. De spec is de bron van waarheid, niet de chatgeschiedenis.

Voor een design-first studio is dat geen technisch trucje. De spec is het ontwerpdocument: flows, states, edgecases, microcopy en toegankelijkheid liggen vast voordat er één regel code is. Goed speccen is goed ontwerpen.

Een goede spec is 90% van het werk.

Speckit maakt dat praktisch. Het is open source, gemaakt door GitHub, en werkt met Claude Code, Copilot en Cursor. Je gebruikt AI als uitvoerder van een helder ontwerp.

Wat spec-driven development is

            <div class="aside aside-float aside-top" data-anchor="sdd-vier-stappen">

De vier stappen

Specify. Wat de gebruiker moet kunnen, welke flows en states, welke teksten.
Plan. De technische aanpak: routes, componenten, datamodellen, koppelingen.
Tasks. Het plan opgeknipt in kleine, te reviewen taken.
Implement. De AI bouwt de taken uit, met spec en plan als leidraad.

Spec-driven development is een manier van bouwen waarbij elk stuk werk begint met een geschreven afspraak. Niet met code, niet met een losse prompt. Speckit werkt met vier stappen, en elke stap levert een markdown-bestand op dat de volgende stap leest. Daarboven hangt een constitution: het bestand met huisregels die altijd gelden, van je design system en goedgekeurde libraries tot security-regels en patronen die niet meer terug mogen komen.

Die bestanden zijn geen administratie achteraf, ze sturen het werk. spec.md zegt wat er moet gebeuren, plan.md hoe het gebouwd wordt, tasks.md maakt het uitvoerbaar en de constitution is de vangrail. We bouwen onze eigen producten exact zo, omdat idee, ontwerp en code dan dicht bij elkaar blijven.

Vanaf nul: speccen voordat je bouwt

Bij een nieuw product is het grootste risico niet dat je langzaam bouwt, maar dat je snel het verkeerde bouwt. AI maakt dat risico groter: je genereert in een middag een dashboard of checkout, en dat voelt als voortgang. Maar als de flow niet klopt, heb je vooral sneller afval gemaakt. Code is pas goedkoop als de richting klopt.

            <div class="aside aside-float">

Wat je vastlegt

Flows. De route van eerste klik tot waarde.
States. Leeg, laden, fout, geen toegang, opgeslagen, gelukt.
Edgecases. Ontbrekende data, dubbele invoer, verlopen sessies, trage API's.
Microcopy. Klant, gebruiker, deelnemer of rekeninghouder?
Toegankelijkheid. Focus, toetsenbord, gekoppelde foutmeldingen, screenreader.

Als je alleen vraagt om "een moderne SaaS onboarding", krijg je een patroon dat de AI al vaak heeft gezien: drie stappen, wat kaarten, een voortgangsbalk. Dat kan er prima uitzien, het zegt alleen weinig over je product. Een goede spec zegt iets anders. Bijvoorbeeld: een zzp'er moet in minder dan twee minuten zien of pensioenaanvulling fiscaal zinvol is, hoeft daarvoor geen fiscale termen te kennen, en bij ontbrekende gegevens geeft de interface geen fout maar een duidelijke vervolgvraag. Dat zijn ontwerpkeuzes. En die horen vóór de code.

Daarom zien wij de spec als ontwerpdocument. Een Figma-scherm laat zien waar de knop staat; een spec legt vast wat hij doet, wanneer hij uit staat en wat er gebeurt als de API-call faalt. De review gaat daarna niet over smaak, maar over de vraag of de output de spec volgt.

Een spec is geen excuus om alles dicht te timmeren. Een goede spec maakt de eerste versie juist kleiner: wat moet iemand doen, zien en begrijpen om te beslissen dat dit product de moeite waard is? De rest hoeft nog niet. Daarna kan AI snel bouwen. Maar dan bouwt het op rails die jij hebt gelegd.

Waar het schittert, en waar niet

Spec-driven development werkt niet overal even goed. Het schittert wanneer de vorm helder is en de uitvoering precies moet zijn.

Greenfield-producten met duidelijke vorm. Als je weet welke waarde de eerste versie moet leveren, is de spec 90% van het werk. Daarna kan AI snel en gericht bouwen.
Regel-gedreven domeinen. Calculators, validaties, workflows, aanvragen en beslisbomen passen goed. De regels moeten toch al expliciet zijn.
Legacy-migraties. Als gedrag al vastligt, kun je de bestaande regels vertalen naar een moderne stack zonder elke afspraak opnieuw te verzinnen.

Het werkt minder goed wanneer je nog zoekt naar de vorm.

Producten waarvan je nog niet weet wat je bouwt. Begin dan met prototypen. Test de richting eerst. Schrijf pas een spec als de kern duidelijk is.
Zwaar creatief UI-werk. Veel beweging, animatie en gevoel in interactie vragen menselijke craft. Een spec helpt, maar vervangt het kijken en finetunen niet.
Pure architectuurkeuzes. De constitution houdt keuzes consistent. Ze maakt de fundamentele keuze niet voor je.

Spec-driven development vervangt het ontwerp-oordeel dus niet, het legt het vast en dwingt het af. De ontwerper ziet wanneer een flow stroef voelt of een knop te vroeg komt; de spec zorgt dat dat oordeel niet verdampt zodra code wordt geschreven. De spec is de brug tussen ontwerp en code.

Tot slot

De spec maakt het verschil: je neemt de keuzes op het moment dat ze nog goedkoop zijn. Eerst de ervaring scherp, dan de code. Voor ons is spec-driven development daarom hetzelfde als design-first bouwen. De spec is geen technische bijlage, maar het ontwerpdocument dat bepaalt wat er straks in handen van je gebruiker komt. En meteen de documentatie van je product.

Heb je een productidee dat nog vorm moet krijgen? Voor € 750 maken we er een klikbaar prototype van, dan weet je of het klopt voordat je een spec schrijft. Is de kern al scherp? Neem contact op, dan speccen en bouwen we hem samen.

Maatwerk of SaaS: wanneer kies je wat

Thomas van den Berg — Sun, 05 Jul 2026 12:37:41 +0000

Software van de plank of maatwerk? Een vraag die bij veel bedrijven leeft. De keuze hangt af van veel factoren. In deze blog een overzicht wanneer je waarvoor kiest. De rekening die je vaak niet ziet, en de hybride die bij de meeste MKB-bedrijven het beste past.

Herken je dit?

Tools die net niet op elkaar aansluiten. Een spreadsheet die iemand bijhoudt voor "wat de tool niet kan". Of erger nog, nieuwe features die je niet kunt implementeren omdat je vast zit aan een leverancier: je past je bedrijf aan aan je software in plaats van andersom.

Software as a Service

                - **Standaard processen.** <span>Boekhouden, e-mail, basis-CRM, projectmanagement. Deze problemen zijn al 100 keer opgelost, geen reden om het opnieuw te doen.</span>

                - **Je hebt morgen iets nodig.** <span>Geen maanden ontwikkeltijd.</span>

                - **Beperkt budget om te starten.** <span>Voorspelbaar, laag instapbedrag.</span>

                - **Geen uniek proces.** <span>Als je werkwijze niet anders is dan andere bedrijven, levert maatwerk je weinig op.</span>

            <div class="aside">

De rekening die je niet ziet

€50 per gebruiker per maand klinkt vriendelijk. Tel daar eens bij op:

                    - **Productiviteitsverlies.** <span>Schakelen tussen systemen, dubbele invoer, workarounds onderhouden.</span>

                    - **Gemiste kansen.** <span>Features die je niet kunt bouwen omdat de tool het niet ondersteunt.</span>

                    - **Schaalpijn.** <span>Als je groeit, groeit de tool niet per se mee maar de kosten wel. Migreren is duurder dan vroeg starten met maatwerk.</span>

                    - **Vendor lock-in.** <span>Je data zit in iemand anders zijn systeem en je bent afhankelijk voor wijzigingen en nieuwe features.</span>

En die rekening groeit harder dan je denkt. SaaS-prijzen stijgen al jaren zo'n vier keer sneller dan de gewone inflatie. Je betaalt per gebruiker, dus hoe groter je wordt, hoe sneller het oploopt.

            </div>

Je bent een kleine klant van een groot bedrijf

Een standaardpakket wordt gebouwd voor de grootste klanten van de leverancier. Wat ze bouwen volgt die grote klanten, niet jouw wensenlijst. De functie die jij nodig hebt komt later, of nooit. Je betaalt mee aan software die voor iemand anders wordt gemaakt.

Maatwerk

                - **Er zit concurrentievoordeel in je proces.** <span>Dan zit er meer in dan een standaardpakket.</span>

                - **Je groeit uit je bestaande tools.** <span>De workarounds stapelen, de exports vliegen rond.</span>

                - **Integratie is kritisch.** <span>Je hebt software nodig die direct aansluit op wat er al draait en features die jij wilt.</span>

                - **Data-eigenaarschap telt.** <span>Bij SaaS zit je data vaak vast. Met maatwerk heb jij de sleutel.</span>

                - **Lange termijn.** <span>Op de korte termijn kost het meer, maar de totale kosten over de looptijd liggen lager.</span>

            <div class="aside aside-left">

En maatwerk dan? Daar zit je toch ook aan vast

Zonder goede documentatie zit je straks vast aan de bouwer, in plaats van aan de leverancier. Onze aanpak:

                    - **De code is van jou.** <span>Je krijgt de broncode, niet alleen een ingelogd account.</span>

                    - **We documenteren wat we bouwen.** <span>Een andere ontwikkelaar kan het overnemen, ook zonder ons.</span>

                    - **Standaard technologie, geen exotische keuzes.** <span>Wat we gebruiken kent elke ontwikkelaar. Je bent nergens de enige die het nog snapt.</span>

                    - **Je data staat bij jou.** <span>In jouw omgeving, in een leesbaar formaat.</span>

Zo krijg je de voordelen van maatwerk zonder dat je er op een nieuwe manier aan vastzit.

            </div>

Maatwerk hoeft niet saai

Wij bouwen maatwerk met dezelfde zorg als de apps die we voor consumenten bouwen. Ook je interne dashboard. Want software die fijn werkt, wíllen mensen gebruiken. En dat verhoogt de productiviteit.

Wat is de beste keuze voor jou?

Het is zelden het een of het ander. De meeste klanten gebruiken SaaS voor standaard zaken (boekhouden, e-mail, ticketing) en maatwerk voor hun kern. Wij bouwen de koppelingen ertussen, zodat data één keer bestaat en overal gebruikt kan worden.

Drie vragen die kunnen helpen bij de keuze:

            <ol>
                <li>Is dit proces uniek voor jouw bedrijf, of doen anderen het ongeveer net zo?</li>
                <li>Verwacht je dat je behoeftes de komende jaren flink veranderen?</li>
                <li>Wat kost het je (in tijd, geld, frustratie) als de software nét niet past?</li>
            </ol>

Vijf vragen voordat je gaat bouwen

Thomas van den Berg — Sun, 05 Jul 2026 12:37:39 +0000

Je hebt een idee voor een app, een tool of een platform. Of je huidige systeem is aan vervanging toe. Je hoeft geen ontwikkelaar te zijn om de juiste vragen te stellen. Begin je project met het stellen van deze vijf vragen.

1. Welk probleem los je op?

Dat klinkt simpel maar wordt vaak overgeslagen. Veel projecten starten met een oplossing ("we willen een app") in plaats van met een probleem ("onze klanten wachten drie dagen op een offerte").

Schrijf het probleem op in één zin. Lukt dat niet, dan is het nog niet scherp genoeg om er software voor te bouwen.

2. Wie gaat het gebruiken?

Software bouwen zonder te weten wie de gebruiker is, is een huis bouwen zonder te weten wie erin gaat wonen. Je eigen team? Je klanten? Allebei? Elke groep heeft andere verwachtingen, een ander technisch niveau en een andere context.

Eén app voor iedereen is meestal een app voor niemand. Kies de groep die het probleem uit vraag 1 het hardst voelt en bouw eerst voor die groep.

3. Wat is het minimum waar je mee live kan?

De verleiding om meteen het complete plaatje te bouwen is groot. En duur. Start met de kleinste versie die al waarde levert. Je leert sneller wat werkt en betaalt niet voor features die niemand gebruikt.

Bij NN hebben we eerst een unbranded app gemaakt als prototype. De beste ideeën hieruit gingen door naar de officiële app. Veel goedkoper om te starten.

            <div class="aside">

Testen met een prototype

Een prototype kan al veel duidelijk maken. Voor € 750 bouwen we in twee weken een klikbaar prototype van je idee. Je ziet of het potentie heeft voordat je een groot plan en budget maakt. Bevalt het niet? Geen factuur.

            </div>

Hoe weet je of het werkt?

Bepaal vooraf hoe succes eruitziet. Geen KPI-document van twintig pagina's, maar een paar concrete meetpunten die ingebouwd zitten in het product. Zonder meten is elke discussie na livegang gevoel tegen gevoel.

            <div class="aside aside-left">

Drie bruikbare meetpunten

Hoeveel uur per week bespaart het je? Hoeveel klanten gebruiken het na drie maanden nog? Hoe snel staat een offerte de deur uit? Simpel te meten en direct gekoppeld aan het probleem uit vraag 1.

            </div>

Wat gebeurt er na de lancering?

Een product is nooit af. Na livegang begint het echte werk: feedback verwerken, bugs fixen, bijsturen. Reserveer daar vooraf budget voor.

Vraag een partij waarmee je praat ook hoe het jaar na de lancering eruitziet. Wie alleen over de bouw nadenkt, is niet de partij waar je mee verder wilt.

Kun je alle vijf beantwoorden? Dan heb je een solide basis.

Dashboards bouwen die je team daadwerkelijk gebruikt

Thomas van den Berg — Sun, 26 Apr 2026 09:09:46 +0000

Je hebt meer data dan je denkt. In je boekhouding, je CRM, je webshop, analytics. Maar data zonder richting is ruis. Een goed dashboard laat in één blik zien wat er nú gebeurt, en waar het heen gaat. Veel dashboards doen dat niet. Hieronder waarom, en hoe het wel werkt.

Het echte probleem: dashboards die niemand opent

Meeste dashboards die we in het wild tegenkomen zijn digitale stoffangers. Mooi opgemaakt, vol grafieken, en niemand die ze na week twee nog opent. Dat ligt zelden aan de tool. Meestal aan de vraag die eraan vooraf ging: "welke beslissing neem jij deze week, en welke informatie heb je daar nu voor nodig?"

Als je die vraag niet scherp hebt, bouw je een rapportage, geen dashboard.

Wat een dashboard goed maakt

                - Vijf tot tien KPI's, niet vijftig. Wat moet je vandaag weten om iets te kunnen beslissen? De rest is achtergrond en kan in een diepere view.

            - **Drie seconden regel.** Elke grafiek moet binnen drie seconden te lezen zijn. Moet je eerst een legenda decoderen, dan klopt iets niet.

            - **Live of near-live data.** Een dashboard met data van vorige week is een rapport. Real-time verandert hoe je werkt, niet alleen wat je ziet.

            - **Gekoppeld aan de bron.** Geen handmatige uploads, geen exports om 09:00. Als iemand iets moet "bijwerken", sneuvelt het dashboard binnen een maand.

Van spreadsheet naar dashboard op maat

Veel bedrijven starten met Excel of Google Sheets. Prima, tot je merkt dat onderhouden meer tijd kost dan kijken. Een dashboard op maat importeert je bronnen (boekhouding, CRM, eigen database, soms een maandelijkse export van een systeem zonder API) en presenteert ze in één plek. Geen copy-paste, geen versies die afwijken.

Waar we vaak starten

We beginnen bij de beslissingen, niet bij de data. "Op basis waarvan besluit je deze week je voorraad bij te vullen?" levert een ander dashboard op dan "laat alle verkoopdata zien". Vanaf daar bepalen we welke bronnen we aansluiten, welke visualisaties werken, en waar dit in jouw dagritme past.

Wil je weten hoe een dashboard er voor jouw bedrijf uit zou kunnen zien? Vertel ons welke data je hebt en welke beslissing je wil versnellen. Dan schetsen we een opzet.

Wat kost een applicatie laten maken?

Thomas van den Berg — Sun, 26 Apr 2026 09:09:43 +0000

"Wat kost een applicatie laten maken?" is de eerste vraag die we bijna altijd krijgen. Het eerlijke antwoord is "dat hangt ervan af", maar daar heb je weinig aan. Dus hieronder de richtprijzen die we in de praktijk hanteren, en wat de scope écht bepaalt.

Waarom er geen vaste prijs is

Een applicatie is geen product van de plank. Het is maatwerk rondom jouw proces, jouw klanten, jouw groeiplannen. Vergelijk het met een verbouwing: een nieuwe keuken is iets anders dan een complete aanbouw. Bij software werkt het precies zo.

De factoren die de prijs bepalen

                - Complexiteit. Een contactformulier is iets anders dan een boekingssysteem met betalingen, notificaties en gebruikersbeheer.

            - **Integraties.** Moet de applicatie koppelen met je boekhouding, CRM of een externe API? Elke koppeling is werk.

            - **Design en UX.** Een standaard interface bouwen is sneller dan een op maat ontworpen ervaring met eigen componenten en animaties.

            - **Schaal.** 50 gebruikers of 50.000? De architectuurkeuzes die je nu maakt bepalen wat later opschalen kost.

Onze tiers, eerlijk opgeschreven

                - Quick prototype. €1.000, 2 weken, no cure no pay. Werkend prototype van een nieuw idee. Bedoeld om te zien of het werkt. Niet tevreden? Geen factuur. Echt.

            - **MVP build. €15.000 tot €25.000, 6 tot 8 weken.** De eerste productieversie die echte gebruikers aankan. Je bouwt hem pas nadat een prototype liet zien dat het idee overeind blijft.

            - **Abonnement. €4.000 tot €6.000 per maand.** Voor doorontwikkeling, onderhoud en nieuwe features na livegang. Niet elk project heeft dit nodig.

De duurste manier om iets te leren

Een MVP bouwen zonder eerst een prototype is de duurste manier om te ontdekken dat je iets verkeerd hebt ingeschat. Wij zijn daar heel duidelijk in. Bij NN bouwden we drie prototypes. Met behulp van gebruiksonderzoek kozen we een richting om door te ontwikkelen.

Hoe je slim investeert

Begin klein. Valideer snel. Breid uit op wat daadwerkelijk werkt. In een brainstorm helpen we je om scope te knippen in dat-kan-vandaag en dat-komt-later. Vaak wordt een MVP na een prototype een stuk kleiner dan je vooraf dacht.

Benieuwd wat jouw applicatie zou kosten? Plan een halfuurtje, dan maken we het concreet. Als we denken dat je het anders moet aanpakken, zeggen we dat ook.