Wat een vastgoedbeheersysteem bouwen in 2026 echt kost

Iedereen die meer dan een handvol verhuureenheden beheert, loopt uiteindelijk tegen dezelfde muur aan. Spreadsheets schalen niet meer, de kant-en-klare tools gaan uit van een workflow die je eigenlijk niet hebt, en op een dag zegt iemand de woorden "misschien moeten we er gewoon zelf een bouwen." De eerste vraag daarna is altijd identiek. Wat gaat het kosten?

Ik kan beter doen dan een generieke range, want we hebben precies dit onlangs gescoopt. Een langetermijnverhuurder kwam bij ons met twee wensen: een publieke website om beschikbare panden te tonen en aanvragen op te vangen, en een interne tool om te stoppen met de business runnen vanuit e-mail en spreadsheets. We prijsden het op drie manieren. De uren zijn echt, en de nuttigste les van de hele exercitie had bijna niets met de technologie te maken.

De marktreflex: waarom niet gewoon er een kopen?

Vastgoedbeheersoftware is geen gat in de markt. Het is een drukke, volwassen markt, ergens boven de $6 miljard waard in 2026 en groeiend met bijna 9 procent per jaar. AppFolio, Buildium, DoorLoop, Mews en een dozijn andere verhuren je morgen graag een gepolijst platform.

En voor veel verhuurders zouden ze dat ook moeten doen. De vuistregel in de branche is dat software zichzelf terugverdient zodra je voorbij drie of vier units bent, want elk uur administratie dat je automatiseert valt rechtstreeks in de winst. De prijzen zijn op kleine schaal ook toegankelijk. DoorLoop begint rond $69 per maand, Buildium zit in dezelfde buurt, en AppFolio draait op een per-unit-model met een minimum van $298 per maand dat je precies vertelt voor wie het gebouwd is.

Dus waarom bouwt iemand dan? Twee redenen komen telkens terug. De eerste is fit. Elk kant-en-klaar PMS codeert één bepaalde manier van werken, en als je leases, je eigenaren of je lokale regels niet bij die vorm passen, breng je je leven door met vechten tegen de tool in plaats van hem te gebruiken. De tweede is de per-unit-meter. Een abonnement is goedkoop bij 20 units en een vaste tax bij 2.000. De software bezitten ruilt die terugkerende rekening voor een eenmalige build en veel lagere hostingkosten. Of de ruil loont is de echte vraag, en die draait volledig om scope.

Een echte schatting, in uren in plaats van bijvoeglijke naamwoorden

Dit is wat het project van onze verhuurder behapbaar maakte. Ze sneden in de scope voordat we ook maar een spreadsheet openden. Ze vroegen niet om een SaaS-platform. Ze vroegen om een praktische interne tool die een klein team kon gebruiken om te stoppen met dingen kwijtraken.

Versie één had precies dit nodig en niets meer:

• Een register van panden en units
• Records van eigenaren en huurders
• Een leaseregister, met getekende contracten opgeslagen bij elke lease
• Beschikbaarheid die de publieke website kon uitlezen
• Basale tracking van terugkerende kosten en handmatige registratie van betalingen
• Documentopslag en het loggen van onderhoudsverzoeken
• Eén intern dashboard voor het personeel

En dit is het deel dat de meeste mensen te zenuwachtig zijn om op te schrijven. Ze wilden expliciet niet:

• Huurder- of eigenaarlogins
• Een betaalgateway
• Geautomatiseerde overzichten, notificaties of messaging
• Planning, geavanceerde rapportage of financiële automatisering

Die tweede lijst is waar het geld zit. Elk item erop is een echte feature met echte waarde, en elk daarvan verdubbelt ruwweg het oppervlak van de build. Huurderlogins alleen al slepen authenticatie, rechten, wachtwoordresets en een beveiligingsmodel mee die je nu voor altijd moet verdedigen. Door "nog niet" te zeggen tegen dat alles, veranderde de klant een platform van zes cijfers in een interne tool van vijf lage cijfers. Scope is geen detail van de schatting. Scope is de schatting.

De drie routes, geprijsd

Met de scope vastgezet splitst het werk zich op in een website en een backoffice, en de backoffice kan twee kanten op. We berekenden alles in uren, optimistisch tot pessimistisch, zoals elke eerlijke schatting hoort te ontstaan.

• De publieke website (Next.js, pandvermeldingen, zoeken, een interactieve kaart, aanvraagformulieren): 280 tot 580 uur.
• Een maatwerk interne admin, gebouwd op Laravel met het Backpack-adminpaneel in plaats van vanaf nul: 376 tot 789 uur.
• Of de SaaS-route: in plaats van de maatwerkadmin een bestaand platform configureren en de beschikbaarheids- en boekingsdata daarvan aan de site koppelen, voor 227 tot 497 uur.

Bij elkaar zijn de twee realistische pakketten een website plus een maatwerkadmin op 656 tot 1.369 uur, of een website plus de SaaS-route op 507 tot 1.077 uur. Tegen een gemengd tarief van $45 tot $65 per uur voor een gevestigd Oost-Europees team is dat ruwweg $30,000 tot $89,000 voor het volledig maatwerktraject, en zo'n $23,000 tot $70,000 als je op de SaaS leunt. Die cijfers verrekenen al een korting van 20 procent op de ontwikkeluren door AI-tooling, met QA en projectmanagement er weer bovenop. De AI-korting is echt, en hij is kleiner dan de keynotes beloven.

Eén klein ding in die schatting vertelt je meer over goed scopen dan welke featurelijst ook. De website moet beschikbaarheid ergens vandaan lezen. Als de admintool bestaat, voedt die de site. Bestaat die nog niet, dan kan een eenvoudige bewerkbare Google Sheet als bron dienen terwijl het team beslist wat het gaat bouwen. Dat soort goedkope, ietwat onelegante keuze is precies wat een echt plan onderscheidt van een verlanglijst.

Bouwen versus kopen, en de regel waar niemand voor offreert

De maatwerkadmin en de SaaS-route liggen qua prijs dicht genoeg bij elkaar dat de kosten alleen het niet beslissen. Het verschil duikt op in waar je je daarna voor inschrijft.

Bouw het en je bezit het. Geen per-unit-kosten, geen leverancier die je workflow herschikt op hun releaseschema, en hosting die $83 tot $612 per maand kost voor de hele stack afhankelijk van verkeer en data. Het addertje is dat je ook het onderhoud, de updates en het gevoel van 02:00 uur waarop niemand anders komt opdagen wanneer er iets stuk gaat zelf bezit.

Koop het en je gaat sneller met veel minder te onderhouden, maar je huurt voor altijd, en de meter loopt per unit. Op AppFolio's instaptier betaalt een portefeuille van 200 units elke maand echt geld, onbeperkt, bovenop het integratiewerk dat het kostte om het platform überhaupt aan je website te koppelen. Vermenigvuldig dat met vijf jaar en de goedkopere optie is dat vaak niet.

Er schuilt een valkuil in die SaaS-route, en onze schatting markeerde hem felrood. Het platform dat de klant overwoog had geen publieke API-documentatie. Geen enkele. Wat betekende dat de hele integratieschatting, elk uur ervan, een gok was tot iemand kon bevestigen dat er überhaupt een bruikbare API en webhooks bestonden. Dit is het meest onderschatte risico in bouwen-versus-kopen-beslissingen. Een SaaS-integratie is alleen zo goedkoop, of zo mogelijk, als de API van de leverancier open is. "We koppelen het wel even aan de website" is een zin die meer planningen heeft verwoest dan welke hoeveelheid maatwerkcode ook. Bevestig de API voordat je de offerte vertrouwt, niet erna.

De rekening die blijft komen

Wat je ook bouwt, de factuur is niet het einde van de uitgaven. Hosting, een managed database, objectopslag voor die getekende contracten, een maps-API, e-mail en monitoring: op dit project kostte die stack $83 per maand aan de onderkant en ruim $600 als verkeer en data oplopen. Bescheiden tegenover een per-unit SaaS-rekening op schaal, maar nooit nul, en het begint de dag dat je lanceert.

Onderhoud is de regel die mensen het hardst vergeten. Begroot 5 tot 10 procent van de bouwkosten per jaar alleen al om een maatwerksysteem actueel te houden met dependency-updates, securitypatches en de kleine fixes die zich opstapelen. Sla het twee jaar over en je onderhoudt niet meer. Je bouwt opnieuw.

Dus wat kost het nou echt?

Voor een gericht intern PMS plus een marketingwebsite, met de scope getrimd zoals onze klant hem trimde, landt het eerlijke antwoord voor 2026 in de lage tot middelhoge vijf cijfers: ruwweg $23,000 tot $89,000, afhankelijk van of je het backoffice bouwt of huurt. Een volledig platform met meerdere rollen, huurderportalen, betalingen, automatisering en rapportage is een ander beest, en zit comfortabel in de zes cijfers. Dezelfde twee woorden, "vastgoedbeheer," wild verschillende builds.

Als je je eigen versie afweegt, brengen drie vragen je een heel eind richting een echt cijfer. Wat is de kleinste scope die oprecht helpt, voordat iemand logins en automatisering toevoegt? Kun je beter per unit huren of de code bezitten, gezien hoeveel units je over vijf jaar runt, niet over één? En voor alles wat je van plan bent te integreren: bestaat de API waar je op rekent echt en komt die met documentatie? Beantwoord die eerlijk en de range stopt eng te zijn. Dan wordt het een budget.