Proptechguiden er en dansk købsguide til software for ejendomsbranchen med knap 150 screenede løsninger. Vi har bygget den med AI på tre måneder, uden et udviklerhus. AI skrev næsten al koden. Men det var beslutningerne, der byggede produktet. Her er casen: hvad AI lavede, hvad der krævede menneskelig dømmekraft, og hvilke fejl der kostede.

Det her er femte del af vores serie om vejen fra traditionel BI til AI-drevne applikationer. I fjerde del skrev vi om vibe coding i virksomheden og om reglen om kun at bygge det, man selv kan vedligeholde. Her er det, der sker, når man går hele vejen og bygger noget, der skal holde i drift.

Hvad Proptechguiden er, og hvorfor vi byggede den

En ejendomsadministration eller en boligforening, der skal vælge et nyt system, står over for et uoverskueligt marked. Leverandørernes egne sider svarer sjældent på det, køberen har brug for: hvad koster det, hvad taler det sammen med, og hvem bruger det i Danmark. Da vi gennemgik markedet, svarede kun 22 af 138 løsninger på alle fem af de spørgsmål, en køber typisk stiller. Det skrev vi om i proptech i Danmark.

Proptechguiden er vores svar: én profil pr. løsning med de samme felter, en kilde på hver oplysning og sammenligninger mellem løsninger, der løser samme opgave. Den er også en test af os selv. Vi rådgiver virksomheder om at bygge med AI, og vi ville vide, hvordan det er at stå med ansvaret for et rigtigt produkt, ikke kun en prototype.

Fra idé til drift på tre måneder

• 30. juli: idé, forretningsmodel og datamodel besluttet, domænet købt
• 31. juli: første linje kode
• 2. august: de første 46 løsninger online med søgning, filtre og sammenligning
• 7. august: guiden åbnet for Google med 92 løsninger
• 12. august: integrationer som egne sider, så man kan se, hvilke systemer der taler sammen
• I dag: knap 150 løsninger, ny screening hver tirsdag og genscreening af de eksisterende profiler hver fredag

Tempoet i de første dage er det, AI gør muligt. Men læg mærke til, at tidslinjen fortsætter efter lanceringen. Det meste af arbejdet er sket bagefter, med rettelser, oprydning og beslutninger om, hvad guiden ikke skal være.

Hvad AI lavede

Claude har skrevet næsten al koden: datamodellen, designet, søgning og filtre, sammenligningssiderne, delebillederne og værktøjerne til import og kontrol. Men AI har også lavet det meste af selve indholdsarbejdet:

• Screening. Hver leverandør screenes efter en fast skabelon. Kun primærkilder som leverandørens eget site, dokumentation og CVR, og en kilde med dato på hvert eneste felt
• Kontrol. Før en profil går live, gennemgår en tjekliste kilder, moms, valuta, sprog og stavning. Efter importen læses alle felter tilbage og holdes op mod kilden
• Drift. Faste ugentlige kørsler finder nye kandidater og tjekker de eksisterende profiler for ændringer, efter samme model som vores AI-agent i praksis
• Analyse. Søgedata fra Google: hvilke sider der bliver fundet, og hvad der skal rettes først

Det står også åbent på guidens metodeside: agenterne screener efter en fast skabelon, og jeg fastlægger reglerne og godkender. Jeg har ikke selv efterprøvet hvert datapunkt. Den beskrivelse er vigtig, for den, der bruger guiden, skal vide, hvordan oplysningerne er kommet ind.

Beslutningerne, der byggede produktet

Hvis AI skrev koden, hvad lavede jeg så? Jeg tog de beslutninger, som ingen kode kan tage for en. Her er fem af dem.

Problemet først, ikke teknologien

Løsningerne er inddelt i otte segmenter efter det problem, de løser for ejendommen, og ikke efter teknologi. AI er bevidst ikke et segment. En køber leder ikke efter AI, men efter en bedre måde at klare udlejning, drift eller energi på.

Ikke oplyst er ikke det samme som nej

Skriver en leverandør ikke, om systemet har en app, er svaret ikke nej. Det er ikke oplyst. Det lyder som en detalje, men det bestemmer hele datamodellen: alle felter af den type har tre tilstande, og et tomt prisfelt må aldrig betyde gratis. Ellers ville guiden give forkerte svar om netop de leverandører, der skriver mindst på deres hjemmeside.

Hvem der kommer med

I august lukkede jeg en bunke på 36 kandidater ned med én regel: kun nordisk og europæisk software med dokumenteret dansk aktivitet, altså en navngiven dansk kunde, et dansk kontor eller en dansk produktside. Senere genåbnede jeg en fravalgt kategori ud fra et princip, AI ikke selv havde formuleret: ingen holdes ude på et grundlag, som en anden er inde på.

En profil, vi ikke kan vedligeholde, skal ud

Under en gennemgang viste det sig, at ét af selskaberne var opløst, og at alle kilderne til profilen var døde links. Profilen så lige så sikker ud som alle de andre. Den røg ud samme dag. En guide er kun troværdig, hvis den også fjerner det, der ikke længere er sandt.

Hvornår en sammenligning er god nok til Google

Guiden bygger sammenligningssider automatisk, løsning mod løsning. Det kan hurtigt blive til tusindvis af tynde sider. Reglen er derfor, at en sammenligning kun må findes af Google, hvis de to løsninger er forskellige på mindst tre punkter, og mindst én forskel er dokumenteret for begge. To manglende svar er ikke en forskel. I september gik jeg et skridt videre: to løsninger skal også løse samme opgave for samme slags kunde. Det skar antallet af sammenligninger fra over 1.100 til 400. Agenten rådede imod at gøre det med det samme. Jeg gjorde det alligevel, fordi de overflødige par var en fejl, der aldrig skulle have været lavet.

Det AI ikke fangede

Den kontrol, AI laver, er grundig. Den tjekker, om en oplysning står i kilden. Den tjekker ikke, om kilden beskriver noget, der findes. Tre eksempler, som jeg fangede ved at kigge, ikke med et værktøj:

• En integration, der ikke fandtes. En profil listede en integration til et navn, leverandøren selv brugte i sin salgstekst. Der fandtes hverken virksomhed, produkt eller domæne med det navn. Det var et internt kælenavn for offentlige bygningsdata. Ordret gengivelse af kilden er ikke det samme som verifikation
• Et logo, der tilhørte et andet selskab. Logoet på en profil viste sig at tilhøre et andet selskab end leverandøren
• Forbehold, der straffede åbenhed. Profiler, hvor leverandøren selv havde delt mest dokumentation, havde i snit 8,5 forbehold mod 6,7 for de øvrige. Antallet af forbehold målte, hvor meget vi vidste, ikke hvor risikabel en løsning var. I en sammenligning så den mest åbne leverandør derfor ud som den mest usikre

Fejlene, der kostede

Fire fejl lærte os mest. Ingen af dem gav en fejlmeddelelse.

Mailen, der forsvandt i stilhed

Når en leverandør ville overtage sin profil, skulle de have en bekræftelse på mail. Den kom aldrig frem. Mailen blev sendt fra en server, som domænets egne sikkerhedsregler ikke godkendte, så modtageren afviste den. Afvisningen blev sendt tilbage til en adresse, der ikke fandtes, og systemet meldte, at mailen var sendt. Senere fandt vi en beslægtet fejl: henvendelser fra formularerne endte i en kø, som ingen åbnede. Seks henvendelser lå ubesvarede i en måned.

Koden, der tog hele sitet ned

Den nyeste version af WordPress havde fjernet en funktion, som vores kode brugte. Det automatiske tjek af koden sagde, at alt var i orden, fordi fejlen først opstår, når siden kører. Hele sitet gik ned, da koden blev lagt op. Rettelsen tog minutter. Lærdommen var, at et grønt tjek kun dækker det, tjekket kan se.

Oversigten, der viste forsiden

Den oversigt, der skulle fortælle Google om 351 sammenligningssider, viste i stedet forsiden, fordi et navn indeholdt en bindestreg. Tre målinger gav tre forskellige tal: vores eget værktøj talte 351 sider, en anden visning 39 og en tredje 0. Først da jeg åbnede filen i en almindelig browser, kunne man se, hvad Google faktisk fik.

Prøvekørslen, der lignede en skrivning

Værktøjet til delebilleder skriver kun noget, hvis man beder det om det. Uden det ekstra flag laver det en prøvekørsel, men udskriften ser ud, som om billedet er lagt op. Fejlen kom igen tre gange, før reglen blev fast: tjek resultatet på siden, ikke værktøjets egen besked.

Fælles for de fire: alle systemer meldte succes. Hvis I selv bygger med AI, er det den vigtigste lektie. Spørg ikke, om noget kørte. Spørg, hvordan I kan se, at det virkede.

Det, vi droppede igen

Ikke alt, AI kan bygge hurtigt, er værd at beholde. Vi byggede anmeldelser med kontrol og visning. Der kom ingen, og i oktober fjernede jeg funktionen, fordi den kunne give mere besvær, end den var værd. Vi slog Google Analytics til, så at den var tom, og slog den fra igen en uge senere. Guiden måles nu kun på søgedata.

Når det er billigt at bygge, bliver det vigtigere at fjerne. Hver funktion skal vedligeholdes, også den, ingen bruger.

Hvad det har kostet, og hvad det har givet

Vi har ikke registreret timer, så vi kan ikke give et ærligt timetal. Det, vi kan dokumentere, er omfanget: arbejde på godt 60 af de første 90 dage, over 470 gemte ændringer og en fast ugentlig drift, hvor jeg godkender, før noget nyt kommer ind. Driften kræver opmærksomhed hver uge. Den er ikke gratis, selv om koden var hurtig at skrive.

Resultatet er en guide, som Google viste omkring 4.000 gange om ugen i oktober, med få klik endnu. Den første henvendelse til Digital Forlomme, der kom gennem guiden, fandt den via ChatGPT. Det er ét eksempel, ikke en tendens, men det viser, hvor en guide med kilde på hver oplysning bliver læst i dag.

Kunne en uden teknisk baggrund have gjort det?

Ikke alene. Flere af fejlene ovenfor blev fanget, fordi jeg vidste, hvor jeg skulle kigge: mailens sikkerhedsregler, nye versioner af WordPress og forskellen på, hvad et værktøj siger, og hvad en browser viser. AI skrev rettelserne, men nogen skulle vide, at der var noget at rette.

Det betyder ikke, at I skal ansætte udviklere. Det betyder, at nogen med den viden skal være med, når beslutningerne bliver taget, og når fejlene skal findes. Resten kan AI i dag klare overraskende langt.

Før I bygger jeres egen løsning

Har I en idé til et dataprodukt eller et internt værktøj, så start med de spørgsmål, AI ikke kan svare på for jer:

• Hvem tager beslutningerne? Der skal være én person, der ejer reglerne for, hvad løsningen må og ikke må
• Hvad er sandt? Bestem, hvor data kommer fra, og hvad I gør, når en oplysning mangler
• Hvem vedligeholder den? En løsning, der kører hver uge, kræver opmærksomhed hver uge
• Hvordan ser I, at den virker? Byg kontrollen ind fra start, så fejl, der ikke larmer, bliver fanget

Vil I have hjælp til at finde ud af, om jeres idé skal bygges, og hvordan, er det det, vi arbejder med i AI-rådgivning.

Ofte stillede spørgsmål om casen