Weet wat AI echt oplost.
AI in app ontwikkeling is inmiddels overal, maar het is niet overal hetzelfde. Wij zetten AI in ons eigen ontwikkelproces én in de apps die we voor klanten bouwen, en kiezen per situatie bewust een andere aanpak.
AI wordt overschat op korte termijn en onderschat op lange termijn. Het is heel goed in het voorwerk: prototypes visueel maken, eerste versies van code schrijven, een concept binnen een dag toetsen bij echte gebruikers. Maar de architectuurkeuzes die bepalen of een app over drie jaar nog overeind staat, blijven mensenwerk. Daarom zetten we AI in waar het tijd wint, en houden we het weg waar het risico toevoegt.
Wat we met AI bouwen
Niet elke AI-toepassing is een chatbot. Dit is wat er in de praktijk in de apps van onze klanten terechtkomt — en meestal is het een combinatie van een paar hiervan.
Chat & assistenten
Klanten en medewerkers die direct antwoord krijgen, in de taal van je eigen documentatie en handleidingen. Geen algemeen internetantwoord, maar wat er bij jou geldt.
Patroonherkenning
Signaleren wat afwijkt in productie-, sensor- of verkoopdata, voordat iemand het zelf opmerkt. Vaak de stilste AI-functie in een app, en meestal de nuttigste.
Documentverwerking
Facturen, formulieren en rapporten automatisch uitlezen en wegschrijven naar het systeem dat je al gebruikt. Dat scheelt overtypen, en daarmee ook typefouten.
Zoeken in je eigen data
Antwoorden uit je eigen handleidingen, contracten en historie in plaats van uit het open internet. De juiste norm in tien seconden in plaats van tien minuten.
Spraak naar tekst
Handsfree registreren op de werkvloer, zonder de handschoenen uit te trekken. Inspraken die meteen als nette regels in het systeem terechtkomen.
On-device intelligentie
Modellen die op het toestel zelf draaien, ook zonder verbinding. Geen cloudkosten en geen data die de app verlaat — wel beperkter in wat het model aankan.
AI in ons eigen proces
Waar versnelt AI ons werk?
In het voorwerk. Een schermflow schetsen voordat er een designer aan zit, een concept binnen een dag bij een paar gebruikers neerleggen, een eerste versie van een koppeling opzetten. Dat scheelt vooral tijd in de concept- en designfase — precies de fase waarin bijsturen nog goedkoop is. Verderop in het project neemt het repeterend werk over, zoals eerste versies van code en het opzetten van tests, zodat developers hun tijd steken in wat echt denkwerk vraagt.
En wat doen we bewust zelf?
Hoe een app meegroeit van vijftien naar honderdvijftig gebruikers, welke koppelingen met bestaande systemen nodig zijn, waar de technische risico’s zitten. AI versnelt het proces, maar vervangt het vakmanschap niet. Daar zit het verschil tussen een app die over drie jaar nog overeind staat en een die bij de eerste groeispurt opnieuw moet.
Merk je daar als klant iets van?
Vooral aan het begin: je ziet sneller iets tastbaars. Een concept dat je kunt aanklikken in plaats van een document, een schermflow waar je op kunt reageren voordat er ontwerpwerk in zit. Daardoor praten we eerder over het product zelf en minder over aannames.
Waarom dan niet alles met AI?
Omdat de duurste fouten niet in het typen zitten maar in de keuzes. Een architectuur die niet meegroeit, een koppeling die het onder druk begeeft, een gat in de beveiliging: dat zie je vaak pas als het te laat is om het goedkoop te herstellen. Daar zetten we mensen op die verantwoordelijk zijn voor het resultaat.
Lees onze visie
AI in de apps die we bouwen
Hoe ziet dat er in de praktijk uit?
Soms een chatfunctie waarmee klanten of medewerkers direct geholpen worden. Vaker iets dat op de achtergrond meedraait: een app die patronen herkent in productiedata, of die informatie naar boven haalt op het moment dat iemand op de werkvloer die nodig heeft. Wat het ook is, het zit in de app die mensen al gebruiken, niet in een los hulpmiddel ernaast dat ze eerst moeten leren kennen.
Waar zit de winst?
Bij de bedrijven waar wij voor werken — in productie, handel en installatie — zit de waarde zelden in een opvallende chatbot. Die zit in het wegnemen van rompslomp: minder papierwerk, minder handmatig overtypen, minder tijd aan werk dat een systeem net zo goed doet. Dat levert zelden één grote doorbraak op, maar wel elke dag een beetje tijd terug bij iedereen die met de app werkt.
Wat doet zo’n functie op de achtergrond concreet?
Een factuur of formulier dat automatisch wordt uitgelezen en belandt in het systeem dat je al gebruikt. Een melding zodra een meetwaarde afwijkt van wat normaal is. Een monteur die in de app een vraag stelt en het antwoord krijgt uit de eigen handleidingen, niet van het open internet.
Hoe beginnen we daaraan?
Niet bij het model, maar bij het werk. We kijken waar in een gewone werkdag de handmatige stappen zitten — wat er wordt overgetypt, opgezocht of nagelopen — en of een AI-functie daar echt iets wegneemt. Is het antwoord nee, dan bouwen we het niet. Levert het wel iets op, dan bepaalt wat er met je data mag welke aanpak past: op het toestel, op eigen infrastructuur of via een extern model.
Plan een kennismaking
Hoe dat er in de praktijk uitziet
In FiDB draait een assistent op het toestel zelf: vragen over races, coureurs en klassementen worden beantwoord zonder dat die data het apparaat verlaat. Van de drie routes hierboven is dat de meest uitgesproken vorm van ’op het toestel’.
FiDB
Proof of concept met on-device AI
Bekijk Casestudy
Wat een AI-prototype meestal mist
01
Code die niet is opgedeeld
Alles in één blok werkt prima, tot het moment dat iemand anders er iets in moet veranderen.
02
Geen tests
Niets dat aangeeft of een aanpassing ergens anders iets breekt. Elke wijziging wordt dan een gok.
03
Geen documentatie
Waarom een keuze zo is gemaakt staat nergens. Een half jaar later weet niemand het meer, ook de bouwer niet.
04
Sleutels in de code
Wachtwoorden en API-sleutels die gewoon zichtbaar in de broncode staan in plaats van veilig weggezet.
Kom je bij ons binnen met een prototype dat je zelf hebt gebouwd, dan is dat een prima startpunt — je hebt iets tastbaars om over te praten in plaats van alleen een idee. Wat bruikbaar is houden we, de rest zetten we recht voordat we erop doorbouwen.
Het AI-landschap verschuift elk kwartaal. Daarom knopen we een app nooit vast aan één model of één leverancier. De AI-laag zit achter een eigen interface, zodat er een beter of goedkoper model in kan zonder dat de rest van de app eraan hoeft te geloven. Wat vandaag via een API loopt, kan volgend jaar on-device draaien — zonder dat je gebruikers er iets van merken.
Welke AI-aanpak past bij jouw app?
De eerste vraag is altijd of de AI internet nodig heeft. Daarna volgen privacy, maatwerk en of het model op het toestel past. Bij de meeste professionele apps wordt het een combinatie.
Lees de beslisboom
On-device AI
Het model draait op het toestel zelf. De snelste route wanneer de functie compact genoeg is om mee te reizen.
- Geen internet nodig
- Geen cloudkosten
- Data blijft op het toestel
- Beperkter in wat het model aankan
Onze voorkeur
Eigen gehost model of LLM met RAG
Een open-source model op eigen infrastructuur, desgewenst met RAG bovenop je eigen documenten en data.
- Privacy of maatwerk cruciaal
- Volledige controle over het model
- Geen vendor lock-in
- Vraagt MLOps-kennis
API naar een bestaand model
GPT, Claude, Gemini of Mistral via een API. Vaak de snelste weg naar kwaliteit, zolang privacy en maatwerk niet doorslaggevend zijn.
- Internet nodig
- Snelste route naar resultaat
- Afhankelijk van een externe partij
- Data verlaat de app · kosten per gebruik
App je een vraag?
Deels. AI versnelt het voorwerk: prototypes, eerste versies van code en het toetsen van een concept voordat er ontwikkeltijd in gaat. De architectuurkeuzes die bepalen of je app over drie jaar nog overeind staat blijven mensenwerk, en die fase versnelt niet.
Dat is precies de vraag die bepaalt welke aanpak we kiezen. Past het model op het toestel, dan verlaat er niets de app. Is privacy doorslaggevend maar moet het model groter zijn, dan hosten we een open-source model op eigen infrastructuur. Pas als privacy en maatwerk niet doorslaggevend zijn, is een API naar een extern model de snelste route.
Meestal wel, en vaker dan je denkt zonder dat de app op de schop gaat. We kijken eerst waar in het dagelijkse werk de handmatige stappen zitten en of daar een AI-functie tegenaan kan. Soms is dat een chatfunctie, veel vaker iets dat op de achtergrond meedraait.
Ja, en het is een prima startpunt: je hebt iets tastbaars om over te praten in plaats van alleen een idee. We kijken wel eerst naar de laag eronder. Wat bruikbaar is houden we, de rest zetten we recht voordat we erop doorbouwen.
Dat hangt vooral af van welke van de drie aanpakken hierboven past. On-device is eenmalig bouwen zonder cloudkosten, een eigen gehost model is duurder in beheer, en een API naar een bestaand model rekent per gebruik. In een eerste gesprek leggen we de opties naast je use case.
Nee. AI neemt het repeterende werk uit handen: eerste versies, refactors, tests opzetten. Elke regel gaat langs een developer voordat hij naar productie gaat, en waar het om architectuur, beveiliging of afwegingen met je business gaat, beslissen mensen.
Snelheid aan de voorkant mag niet betekenen dat je er aan de achterkant voor betaalt. Wat AI oplevert gaat door dezelfde review als ons eigen werk: is het opgedeeld in behapbare stukken, staat er niets gevoeligs in de code, en kan iemand anders dan de bouwer het over een jaar nog onderhouden.
