Wat kunnen domeinspecialisten zelf bouwen?

Je kent je proces beter dan enige ontwikkelaar ooit zal kennen. Je hebt jaren in het magazijn gewerkt, claims in de wachtrij beheerd of de productieplanning verzorgd, en elke keer als je IT om een kleine wijziging vraagt, duurt het drie weken en een ticketnummer. Dus je begint je af te vragen: zou ik dit niet zelf kunnen bouwen?

Het eerlijke antwoord is: ja, voor meer dan je waarschijnlijk denkt — maar niet voor alles. Dit artikel trekt de lijn zo duidelijk mogelijk, waarbij echte low-code tools (FileMaker, Klai en FmBetterforms) als concrete voorbeelden dienen van wat nu binnen bereik van een domeinspecialist ligt, en waar het overdragen aan een ontwikkelaar je nog steeds voor een dure rotzooi behoedt.

Waarom is deze vraag plotseling relevant?

Gedurende het grootste deel van de softwaregeschiedenis betekende "je eigen app bouwen" ofwel worstelen met Excel-macro's ofwel wachten in de IT-backlog. Die kloof is kleiner geworden. Low-code platforms zoals FileMaker laten je een werkende database ontwerpen met formulieren, layouts en logica met behulp van visuele tools in plaats van raw code. Met AI ondersteunde tools zoals Klai ga je nog een stap verder — je kunt beschrijven wat je wilt in plain language en een werkend startpunt genereren. Het resultaat: een magazijnmanager, een operations manager of een claims handler kan nu iets produceren dat vijf jaar geleden een professionele ontwikkelaar nodig zou hebben gehad.

Dit is belangrijk omdat de bottleneck in de meeste bedrijven niet gebrek aan ambitie is — het is de mismatch tussen hoe snel het bedrijf verandert en hoe snel IT kan reageren. Ons gerelateerde artikel over hoe low-code en AI ondersteunde development zakelijke software veranderen behandelt die verschuiving dieper. Dit artikel zoemt in op één praktische vraag erin: wat kun je, als domeinspecialist, veilig zelf aanpakken?

Wat kan een domeinspecialist realistisch alleen bouwen?

Hier is een concrete lijst, gebaseerd op wat we daadwerkelijk zien dat niet-ontwikkelaars succesvol bouwen en onderhouden in tools zoals FileMaker:

• Een single-purpose tracker. Een verzendinglogboek, een retourregister, een onderhoudschecklist — één tabel, een formulier, een lijstweergave, misschien een statusveld. Dit is pure low-code territorium: sleep een paar velden naar een layout, definieer een waardenlijst, klaar.
• Een eenvoudig goedkeurings- of intakeformulier. Een verzoek voor vakantie, een inkooprekwest, een klantintakeformulier dat een PDF verzendt wanneer het is ingediend. Tools zoals FmBetterforms (een formulier-renderlayer voor FileMaker) laten niet-ontwikkelaars schone, mobiele formulieren bouwen zonder direct layoutobjecten aan te raken.
• Persoonlijke of teamdashboards op bestaande gegevens. Als de onderliggende gegevensstructuur al bestaat (bijvoorbeeld in je FileMaker-systeem of via API), kan een domeinspecialist meestal hun eigen samenvattingsweergave, filter of rapport bouwen zonder iets stroomopwaarts te veranderen.
• Snelle automatiseringen voor repetitieve persoonlijke taken. Een macro die bestanden hernoemt, een script dat een spreadsheet herformatteert voor import, een door Klai gegenereerde snippet die een standaard emailreactie opstelt. Deze zijn laag risico omdat ze alleen je eigen workflow raken, niet gedeelde bedrijfsgegevens.
• Een eerste werkend prototype om aan IT over te dragen. Zelfs als de bouw van een domeinspecialist niet productie-klaar is, communiceert een ruw werkend model bedoeling veel beter dan een schriftelijke spec. "Dit is ruwweg wat ik nodig heb" verslaat drie pagina's eisen elke keer.

Waar begint zelfgebouwde software problemen op te leveren?

Het eerlijke patroon dat we in elke branche zien: zelfgebouwde tools werken prachtig totdat ze meer dan één persoon, één proces of één systeem raken. Concreet: let op deze vijf waarschuwingstekens.

1. Meer dan één persoon bewerkt dezelfde record. Een single-user tracker heeft geen concurrency-probleem. Op het moment dat twee magazijnmedewerkers gelijktijdig dezelfde zending bijwerken, heb je echte conflict handling nodig — iets wat low-code defaults vaak eerder oversluiten dan oplossen.
2. De gegevens moeten het tool verlaten. Een zelfgebouwde spreadsheet die een database is geworden, is prima totdat iemand die gegevens in je boekhoudprogramma, je webshop of een leveranciersportal nodig heeft. Dit is een integratieprobleem, en het vraagt om een echte API-strategie, niet om een CSV-exportknop.
3. Compliance of controleerbaarheid komen in beeld. GDPR, audit trails voor financiën of branchespecifieke opslagvereisten voor records veranderen "wie heeft dit veld veranderd en wanneer" van een nice-to-have in een wettelijke vereiste. Zelfgebouwde tools loggen dit meestal niet standaard.
4. De bedrijfslogica splitst zich sterk op. Een prijsregel die afhangt van klanttier, ordervolume, regio en drie seizoensuitzonderingen is precies het soort logica dat eenvoudig uitziet in een spreadsheet en binnen zes maanden onhoudbaar wordt zonder een goede structuur.
5. Iemand anders dan de bouwer moet het onderhouden. De meest riskante zelfgebouwde apps zijn die welke volledig in het hoofd van één persoon leven. Als die persoon vertrekt of bevorderd wordt, heeft het "systeem" waarvan nu half de afdeling afhangt geen documentatie, geen back-upplan en niemand die het veilig kan wijzigen.

Hoe verandert AI wat een domeinspecialist kan doen?

AI-ondersteunde development tools zoals Klai verschuiven de startlijn, niet de eindlijn. Vraag Klai om "een tabel bouwen die binnenkomende inspecties volgt met een pass/fail-status en een fotoveld," en je krijgt een werkende structuur in minuten in plaats van uren. Dat is echt nuttig — het sluit het blanco-paginaprobleem op dat niet-ontwikkelaars gebruikte tegen te houden voordat ze zelfs maar begonnen.

Maar AI-gegenereerde structuur heeft nog steeds een mens nodig die de bedrijfsregels begrijpt om het te controleren. Een gegenereerde inspecttietracker weet misschien niet dat je kwaliteitsteam twee onafhankelijke handtekeningen voor een mislukte batch nodig heeft, of dat bepaalde productlijnen onder een leveranciersovereenkomst helemaal niet worden geïnspecteerd. AI geeft je een snelle eerste schets; het vervangt geen domeinbeoordeling, en het produceert niet automatisch iets dat schaalt, integreert of onderhoudbaar blijft wanneer vijf meer mensen het gaan gebruiken.

Een praktische checklist: zelf bouwen of een ontwikkelaar bellen?

Stel jezelf deze vragen voordat je begint:

• Zullen meer dan 2-3 personen dit regelmatig gebruiken?
• Moeten de gegevens verbonden zijn met een ander systeem (ERP, webshop, boekhouding, leveranciersportal)?
• Is er een wettelijke of compliance-reden om bij te houden wie wat heeft veranderd en wanneer?
• Zou het verlies van dit tool voor een dag echte bedrijfsverstoringen veroorzaken?
• Heeft de logica meer dan 2-3 voorwaardelijke vertakkingen?
• Zal iemand anders dan jij het later moeten onderhouden of uitbreiden?

Als je "ja" hebt geantwoord op twee of meer van deze, is het tijd om een ontwikkelaar in te schakelen — niet om het project van je over te nemen, maar om hetzelfde idee op een fundament te bouwen dat niet onder zijn eigen gewicht zal barsten.

Wat is de slimste manier om een zelfgebouwde tool over te dragen?

De beste uitkomst die we zien is niet "domeinspecialist bouwt alles" of "IT bouwt alles" — het is een handoff die goed wordt gedaan.

1. Bewaar je prototype. Gooi het spreadsheet of het ruwe FileMaker-bestand dat je hebt gebouwd niet weg. Het is het duidelijkste vereistendocument waar een ontwikkelaar om kon vragen.
2. Schrijf de uitzonderingen op, niet alleen het happy path. De regel die iedereen vergeet te noemen is meestal die welke het nieuwe systeem breekt. Wat gebeurt er bij een geretourneerde bestelling? Wat als de klant kredietgeblokkeerd is? Zeg het hardop voordat de heropbouw begint.
3. Noem wie else dit proces raakt. Een ontwikkelaar moet weten of magazijn, verkoop en financiën allemaal met deze gegevens omgaan, zelfs als slechts één van hen het tool heeft aangevraagd.
4. Vraag om iets dat nog steeds van jou voelt. Een heropgebouwd systeem moet nog steeds passen hoe je team echt werkt — je niet dwingen in een generieke template omdat dat het snelst is verzonden.

Veelgestelde vragen: domeinspecialisten die hun eigen software bouwen

Kan ik echt een werkende zakelijke app bouwen zonder te weten hoe ik moet coderen? Ja, voor scoped, single-purpose tools — trackers, formulieren, checklists, dashboards op bestaande gegevens. Low-code platforms en AI-generators zijn specifiek ontworpen om dit mogelijk te maken.

Is een zelfgebouwde tool ooit permanent "goed genoeg"? Soms ja — als het single-user blijft, laag-inzet en losgekoppeld van andere systemen. De problemen beginnen wanneer de omvang ervan stilletjes groeit buiten dat.

Wat is de grootste fout die domeinspecialisten maken? Niet het bouwen zelf — het is een persoonlijk tool stilletjes laten worden kritieke departementale infrastructuur zonder dat iemand dat opzettelijk besluit.

Telt het gebruik van AI om de eerste versie te genereren als "het zelf bouwen"? Grotendeels ja, en dat is een goed ding — het verlaagt de drempel om het te proberen. Sla alleen niet het beoordelen van de gegenereerde logica tegen je werkelijke bedrijfsregels over.

Wanneer moet ik een ontwikkelaar inschakelen in plaats van het zelf uit te breiden? Zodra twee of meer van de checklistitems hierboven van toepassing zijn. Dit is het punt waarop verborgen kosten — gegevensconflicten, missende audit trails, onhoudbare logica — beginnen op te wegen tegen de tijd die je hebt bespaard door het zelf te bouwen.

Als je team een zelfgebouwde spreadsheet of FileMaker-prototype is ontgroeid, of je weet nog niet zeker of het een tool voor twee personen of het begin van iets groters is, dat is precies het gesprek dat je vroeg wilt voeren. Loggix kan helpen een werkend prototype om te zetten in een goed gestructureerde FileMaker-oplossing, het verbinden met de systemen waarmee het uiteindelijk moet communiceren via API-integraties, of gewoon met je gaan zitten voor een kort consultatieoesprek om in kaart te brengen wat eenvoudig moet blijven en wat een echte basis verdient.