Klantverhaal: Hoe AI de vastgoedsector kan helpen

Onze klant had slimmere software nodig. Geen AI advies. Geen chatbot. Iemand die naast hen ging zitten, het werk snel kon begrijpen, en dat begrip kon omzetten in iets dat daadwerkelijk hun probleem oploste.
Dus dat hebben we gedaan.
Bij Stackhavn zijn we ‘builders’. Geen consultant die aanbevelingen schrijft. Geen bureau dat wacht op een briefing of een extra hand in een bestaand team. We draaien mee in het dagelijks werk van ondernemers, maken het domein ons eigen, en beginnen te bouwen.
Dit is hoe dat eruit zag bij dit project.
Startpunt: begrijp het domein, niet de requirements
We begonnen niet met een productspecificatie. We begonnen met kijken.
We zaten naast de taxateur terwijl hij werkte. We zagen hoeveel webpagina’s er openstonden. We keken hoe hij eigendomsgegevens uit het Kadaster haalde, gebouwgegevens uit de BAG, bestemmingsplannen van de gemeente, energielabels van RVO, klimaatrisico-kaarten, en recente vergelijkbare transacties uit aparte platforms. Alles gekopieerd en geplakt in een Word-sjabloon.
Het schrijven van een (commercieel) taxatierapport dat uren zou moeten kosten, duurde dagen. Niet omdat de taxateur langzaam was. Omdat data verspreid is over te veel systemen en het juiste gereedschap simpelweg niet bestaat.
Dit is wat een embedded engineer met een pragmatische mentaliteit kan: het echte probleem zien en het vertalen naar werkende software. Documenten beschrijven zelden wat mensen écht doen tijdens hun werk. Meekijken met iemands werk en vervolgens de vragen stellen die nergens beschreven staan, daar zit de echte waarde.
Binnen dagen begrepen we het werkproces, de knelpunten en de wettelijke kaders goed genoeg om te beginnen met ontwerpen.
Daarna: vertaal domeinkennis naar beslissingen
Nederlandse vastgoeddata behoort tot de rijkste van Europa, maar is vaak versnipperd en tegenstrijdig. De BAG zegt het één, de satellietbeelden weer iets anders, en WOZ-waardes sluiten niet altijd aan bij de markt.
Doordat onze engineers direct naast de domeinexperts zaten, konden we snel doorpakken naar de architecturale keuzes: alle relevante bronnen samenbrengen in één interface. We kiezen voor transparantie in plaats van abstractie; in een gereguleerde sector moet de taxateur juist de frictie in de data zien om een verdedigbaar oordeel te vellen. We bouwen een AI-laag die fungeert als een scherpe junior collega: die doet het voorwerk, de professional neemt de beslissing.
Hier loont onze aanpak. Ongeveer 80% van wat we bouwen is herbruikbaar voor iedere klant: de infrastructuur, het AI-framework, data-pipelines en security. Dit noemen we de Stackhavn platform-modules. De overige 20% is domeinspecifiek: de Kadaster-integratie, de taxatie-workflow en de specifieke regelgeving. Dit is het deel dat de embedded engineer samen met de klant ontwikkelt.
Omdat de basis al staat, kunnen we alle energie richten op wat er écht toe doet: een product dat naadloos aansluit op het werkelijke werkproces van de taxateur.
Vervolgens: samen bouwen
Met veel kennis van het domein en de architectuur op de juiste plek, bouwden we het product in korte cycli. Niet vanuit een afgelegen kantoor, maar zij aan zij met de domeinexpert.
Data-layer: Voer een adres in en het platform haalt direct perceelgegevens, gebouwspecificaties, demografische CBS-data, bestemmingsplannen, energielabels en visualisatiekaarten op. Eén scherm, alle bronnen helder vermeld en weergegeven.
AI-agent: Geen simpele chatbot, maar een gestructureerde assistent die de expert door het hele taxatieproces begeleidt. Van dataverzameling en documentanalyse tot de transcriptie van inspecties en concept rapport secties met bronverwijzingen. Ieder datapunt is herleidbaar, want in gereguleerd werk is kunnen aantonen waar een getal vandaan komt immers een vereiste.
Workflow: Dit is het deel dat de meeste teams onderschatten. De AI is het zichtbare onderdeel, maar de workflow bepaalt of het echt past binnen jouw bedrijf. We bouwden een dashboard voor concept taxaties, de mogelijkheid om te delen met collega's en een helder traject van start tot conceptversie. Vormgegeven rond hoe de taxateur daadwerkelijk werkt, niet zoals het internet dat voorschrijft.

Waarom deze manier van werken ertoe doet
Ons model is gemaakt voor een specifieke situatie: een bedrijf met diepe domeinkennis, een concreet operationeel probleem, en geen zin in een software project van twaalf maanden.
We schakelen snel. Een embedded engineer levert vanaf week één. Niet omdat we stappen overslaan, maar omdat we geen tijd verspillen aan overdrachten, powerpoints en verkeerd begrepen briefings.
We maken het domein ons eigen door samen te werken, en bouwen op maat. De taxateur schreef geen specificaties. Hij liet ons zijn werk zien. Wij stelden vragen, keken mee bij beslissingen en vertaalden wat we zagen naar productkeuzes. Samen. Aan het einde van week één kon onze engineer het verschil tussen erfpacht en vol eigendom uitleggen. Dat soort context maakt of breekt een domeinspecifiek AI product.
We vertalen problemen in werkende oplossingen. Geen features uit een document of iets bouwen om maar iets met AI te doen. We bouwen oplossingen voor knelpunten die we in de praktijk zagen. Versnipperde databronnen werd een geïntegreerde datalaag. De eis van controleerbaarheid werd herleidbare AI. Het rommelige werkproces uit de echte wereld werd een flexibele pipeline.
De basis was al bewezen. De taak van de embedded engineer is om die laatste 20% om te vormen rondom het domein van de klant zodat het product voelt alsof het intern is gebouwd.
Wat we meenemen uit dit project
Kijk voordat je bouwt. De beslissingen die stand hielden kwamen voort uit observatie, niet uit documenten. Een engineer die in de operatie zit zal altijd beter presteren dan een team dat werkt vanuit een voorstel.
In gereguleerde sectoren is controleerbaarheid onderdeel van het product. Je werk kunnen uitleggen en beredeneren is geen bijzaak. Het is vaak de reden dat een professional het gebruik van een AI oplossing überhaupt kan verantwoorden.
Generieke AI is makkelijk te bouwen. Specifieke AI is moeilijk te negeren. Er is een wezenlijk verschil tussen een oplossing die alles beantwoordt en eentje die weet welk deel van het proces geautomatiseerd kan of zelfs mag worden. Dat komt alleen door dicht bij de mensen te zitten die het werk doen.

