19 jul 2025·7 min
AI-bouwkosten per functie: een eenvoudige budgetmethode
AI-bouwkostenschatting eenvoudig gemaakt: voorspel credits en tokens per functie, scope prompts en voorkom herwerk zodat je app binnen budget blijft.
AI-bouwkostenschatting eenvoudig gemaakt: voorspel credits en tokens per functie, scope prompts en voorkom herwerk zodat je app binnen budget blijft.
AI-geassisteerd bouwen voelt goedkoop tot het dat opeens niet meer is. Dat komt omdat je niet betaalt voor een vaste featureprijs. Je betaalt voor pogingen: berichten, gegenereerde code, revisies, tests en herwerk. Als het plan vaag is, lopen het aantal pogingen snel op.
De meeste kostenpieken ontstaan door een handvol patronen:
Als je inschat, wees duidelijk over wat je precies budgetteert:
Behandel elke schatting als een bereik, niet als één getal. Een feature kan er klein uitzien in de UI maar groot zijn in logica, of andersom. Best case is een sterke eerste versie. Worst case zijn meerdere correctierondes.
De rest van deze gids gebruikt herhaalbare feature-buckets: auth, CRUD, integraties en UI-herontwerpen. Als je een credit-gebaseerd vibe-coding platform gebruikt zoals Koder.ai (koder.ai), merk je dit snel: beginnen met "bouw een dashboard" en later rollen, auditlogs en een nieuwe layout toevoegen kost veel meer credits dan die beperkingen van tevoren opschrijven.
Mensen verwarren vaak drie verschillende ideeën: tokens, credits en bouwstappen. Ze scheiden maakt kosten makkelijker voorspelbaar.
Een token is een klein stukje tekst dat het model leest of schrijft. Je prompt gebruikt tokens, het antwoord van het model gebruikt tokens, en een lange chatgeschiedenis gebruikt tokens omdat het model die opnieuw moet lezen.
Een credit is de factureringseenheid van je platform. Op tools zoals Koder.ai dekken credits meestal modelgebruik plus werk achter de chat (bijv. agenten die taken uitvoeren, bestanden aanmaken en resultaten controleren). Je hoeft de interne details niet te kennen om te budgetteren, maar je moet herkennen wat het gebruik laat groeien.
Een bouwstap is één zinvolle wijziging aan het project: "email-login toevoegen", "de users-tabel aanmaken" of "dit scherm koppelen aan een endpoint." Eén feature bestaat vaak uit veel stappen en elke stap kan meerdere modelaanroepen triggeren.
Gebruik stijgende usage wanneer je veel context hebt (grote specificaties, veel chatgeschiedenis, veel bestanden), veel iteraties, grote outputs (hele bestanden herschrijven, grote codeblokken) of vage verzoeken die het model laten gokken.
Kleine promptwijzigingen kunnen kosten sterk laten schommelen omdat ze bepalen hoeveel retries je nodig hebt. "Een compleet auth-systeem" nodigt uit tot opties die je niet vroeg. "Email en wachtwoord alleen, geen social login, precies twee schermen" snijdt bewegende delen weg.
Een vuistregel: minder bewegende delen betekent minder retries.
Stop met inschatten in "schermen" of "berichten." Schat in functies die een gebruiker hardop zou benoemen. Dat verbindt het budget aan resultaten, niet aan hoe kletserig de build wordt.
Voor elke feature schat je drie delen:
De meeste overschrijdingen gebeuren bij testen en revisie, niet bij het eerste concept.
Gebruik een bereik voor elk deel: laag (rechttoe rechtaan), typisch (wat heen-en-weer), hoog (verrassingen). Als je platform credit-gebaseerd is, houd het in credits bij. Als je tokens bijhoudt, houd het in tokens bij. Het punt is hetzelfde: een forecast die eerlijk blijft als de realiteit verandert.
Twee regels helpen zelf veroorzaakte overschrijdingen te voorkomen:
Onzekerheidsbuffer (10–20%) als aparte regel. Verberg die niet in de features.
Later gevraagde wijzigingen als aparte bucket voor nieuwe ideeën nadat een feature is geaccepteerd ("voeg ook teams toe", "laat het dashboard eruitzien als X"). Als je dit niet apart houdt, blameer je de oorspronkelijke schatting voor normale veranderingen.
Hier is een lichtgewicht template die je kunt kopiëren:
Feature: Password login
- Build: low 30 | typical 60 | high 120
- Test: low 15 | typical 30 | high 60
- Revise: low 10 | typical 20 | high 40
Subtotal (typical): 110
Buffer (15%): 17
Later changes (held): 50
Herhaal dit voor elke feature (auth, CRUD, een integratie, een UI-refresh). Tel ze op met "typisch" voor je plan en "hoog" als worst-case check.
Auth en CRUD lijken basaal, maar worden duur als de scope vaag is. Behandel ze als een menu: elke optie voegt kosten toe.
Schrijf op wat "klaar" betekent voor toegangscontrole. De grootste drijfveren zijn het aantal loginmethoden en het aantal permissiepaden.
Wees specifiek over:
Als je alleen zegt "voeg auth toe", krijg je een generieke oplossing en betaal je later om randgevallen in te bouwen. Het vormgeven van auth vooraf is goedkoper.
CRUD-kosten worden bepaald door hoeveel entiteiten je hebt en hoeveel gedrag elke entiteit nodig heeft. Een praktisch model: elke entiteit impliceert vaak 3–6 schermen (lijst, detail, aanmaken, bewerken, soms admin of audit views), plus API-werk en validatie.
Wanneer je CRUD scopet, benoem de entiteiten en includeer velden, types en validatieregels (verplicht, uniek, bereiken). Definieer vervolgens lijstgedrag: filters, sorteren, paginatie en zoeken. "Zoeken" kan een simpele contains-filter zijn of iets veel zwaarders.
Bepaal ook of admin-schermen verschillen van gebruikersschermen. Verschillende layouts, extra velden en bulk-acties kunnen het werk verdubbelen.
Randgevallen die kosten snel doen oplopen zijn rijniveaupermissies, audit logs, CSV import/export, soft delete en goedkeuringsworkflows. Dit is allemaal uitvoerbaar, maar het budget blijft voorspelbaar als je expliciet kiest wat je wilt voordat je de feature genereert.
Integraties voelen duur omdat ze werk verbergen. De oplossing is ze in kleine, testbare stukken te breken in plaats van “maak verbinding met X.” Dat maakt de schatting voorspelbaarder en geeft je een schonere prompt.
Een solide integratie-scope bevat meestal:
Slot het datacontract vast vóór je prompt. Noem de objecten en exacte velden die je nodig hebt. "Sync customers" is vaag. "Sync Customer{id, email, status} and Order{id, total, updated_at}" houdt het model ervan weer extra tabellen, schermen en endpoints te verzinnen.
Bepaal daarna richting en frequentie. Eénrichtingssync (alleen import) is veel goedkoper dan tweerichtingssync omdat tweerichtingssync conflictregels en meer tests nodig heeft. Als tweerichtingssync moet, kies dan de 'winner rule' vooraf (source of truth, last-write-wins of handmatige review).
Plan voor falen alsof het gegarandeerd is. Bepaal wat er gebeurt als de API down is. Een logentry plus een alert en een handmatige "re-run sync" knop is vaak genoeg. Het minimal houden voorkomt dat je betaalt voor een volledige ops-omgeving die je niet vroeg.
Voeg ten slotte een buffer toe voor derde-partij eigenaardigheden en testen. Zelfs "simpele" API’s brengen paginatie, vreemde enums, inconsistente docs en rate limits. Budgetteren van extra 20–40% voor integratietesten en fixes is realistisch.
UI-werk is waar budgetten stilletjes lekken. "Redesign" kan kleuren wisselen of de hele flow herbouwen betekenen, dus benoem wat er verandert: layout, componenten, copy of gebruikersstappen.
Schei visuele-only wijzigingen van wijzigingen die gedrag beïnvloeden. Visuele-only raakt styles, spacing en componentstructuur. Zodra je verandert wat een knop doet, hoe validatie werkt of hoe data laadt, is het featurewerk.
Vermijd "herontwerp de hele app." Maak een lijst van exacte schermen en staten. Als je de pagina’s niet kunt opsommen, kun je het niet inschatten.
Houd de scope kort en concreet:
Dit type prompt voorkomt dat het model design over de hele codebase verzint, wat veel heen-en-weer veroorzaakt.
UI-wijzigingen hebben meestal minstens twee checks nodig: desktop en mobile. Voeg een snelle basis-toegankelijkheidspass toe (contrast, focus states, keyboardnavigatie), zelfs als je geen volledige audit doet.
Een praktische schattingsmethode is:
(aantal pagina’s) x (diepte van wijziging) x (aantal passes)
Voorbeeld: 3 pagina’s x medium diepte (nieuwe layout plus componentaanpassingen) x 2 passes (build plus polish) is een voorspelbaar chunk credits. Als je ook de onboardingflow verandert, behandel dat als een aparte lijn in de scope.
De goedkoopste manier om credits te controleren is beslissen wat je wilt vóór je het model vraagt het te bouwen. Herwerk is waar kosten omhoog schieten.
Begin met één alinea die de gebruiker en het doel noemt. Bijvoorbeeld: "Een kleine kliniekreceptionist logt in, voegt patiënten toe, plant afspraken en ziet de lijst van vandaag." Dit stelt grenzen en ontmoedigt het model om extra rollen, schermen of workflows te verzinnen.
Beschrijf het product daarna als schermen en acties, niet als vage modules. In plaats van "afsprakenmodule", schrijf "Kalenderscherm: aanmaken, verzetten, annuleren, zoeken." Het maakt de werklast telbaar.
Includeer alleen de data-essentials. Je hebt nog niet elk veld nodig, alleen wat de feature echt maakt. Een sterke prompt bevat meestal:
Acceptatiechecks voorkomen dat je dubbel betaalt. Voor elke feature schrijf 2–4 checks zoals "User can reset password via email" of "Create appointment prevents double booking." Als je Koder.ai gebruikt, passen die checks ook natuurlijk in Planning Mode vóór codegeneratie.
Wees expliciet over out-of-scope items: "geen admin dashboard", "geen betalingen", "geen meertaligheid", "geen externe kalender-sync." Dit voorkomt dat "nice to have" werk ongevraagd wordt toegevoegd.
Bouw in kleine brokken en her-schat na elk blok. Een simpel ritme is: genereer één scherm of endpoint, voer het uit, fix problemen en ga dan door. Als een blok meer kost dan verwacht, snijd dan scope of reduceer het volgende blok voordat je afdrijft.
De meeste kostenpieken ontstaan doordat je te veel in één bericht vraagt. Behandel het model als een teamgenoot: brief het in kleine, duidelijke stappen.
Begin met een plan, niet met code. Vraag om een kort bouwplan met aannames en open vragen, bevestig dat, en vraag vervolgens de eerste kleine implementatieronde. Als je planning, bouwen, testen, copywriting en styling in één prompt combineert, nodig je lange outputs en meer fouten uit.
Houd context strak. Voeg alleen de schermen, componenten of API-notities toe die relevant zijn voor de wijziging. Als je Koder.ai gebruikt, selecteer dan de specifieke bestanden en verwijs ernaar bij naam. Extra bestanden verhogen tokens en trekken bewerkingen naar niet-gerelateerde gebieden.
Vraag om kleine diffs. Eén prompt zou idealiter één ding moeten veranderen: één endpoint, één formulier, één foutstaat, één scherm. Kleine wijzigingen zijn makkelijker te reviewen en als iets fout gaat betaal je niet om niet-gerelateerd werk opnieuw te doen.
Een simpele set werkregels:
Stop loops vroeg. Als de tweede poging nog steeds niet goed is, verander dan de input, niet alleen de tekst. Voeg het ontbrekende detail toe, verwijder tegenstrijdige eisen of laat het exacte falende geval zien. "Probeer opnieuw" herhaaldelijk verbranden vaak tokens zonder dichter bij het juiste resultaat te komen.
Voorbeeld: je wilt "login + wachtwoord vergeten" en een nettere layout. Doe het in drie prompts: (1) schets flows en vereiste schermen, (2) implementeer alleen de auth-flow, (3) pas UI-spacing en kleuren aan. Elke stap blijft controleerbaar en goedkoop.
De meeste overschrijdingen worden niet veroorzaakt door grote features. Ze komen door kleine scope-gaten die zich vermenigvuldigen in extra prompt-rondes, meer gegenereerde code en meer fixes.
Bouwen voordat je akkoord bent over "klaar"
Als je code genereert zonder acceptatiechecks, betaal je voor herschrijvingen. Schrijf eerst 3–5 checks: wat een gebruiker kan doen, welke fouten getoond worden, welke data opgeslagen moet worden.
Vage woorden gebruiken
"Modern", "mooi" en "maak het beter" nodigen uit tot veel heen-en-weer. Vervang ze door specifics zoals "twee-koloms layout op desktop, één kolom op mobiel" of "primaire knopkleur #1F6FEB."
Meerdere features in één prompt proppen
"Voeg auth toe, voeg betalingen toe, voeg admin-dashboard toe" maakt het moeilijk veranderingen te volgen en opvolgschattingen te bepalen. Doe één feature per keer en vraag om een korte samenvatting van welke bestanden zijn aangeraakt.
De datamodel laat veranderen
Tabellen hernoemen, relaties veranderen of IDs switchen halverwege dwingt edits door UI, API en migraties. Lock de kernentiteiten vroeg, ook al blijven sommige velden "toekomstig."
Testen tot het einde overslaan
Bugs veranderen in regenerate-fix-regenerate loops. Vraag per feature om een kleine testset, niet één gigantische testpass aan het eind.
Een concreet voorbeeld: je vraagt Koder.ai om "maak de CRM beter" en het wijzigt layouts, hernoemt velden en past endpoints in één keer aan. Daarna breekt je integratie en je betaalt credits alleen al om te vinden wat er verschoven is. Als je in plaats daarvan zegt "houd het datamodel ongewijzigd, update alleen de lijstpagina UI, raak geen API-routes aan en voldoe aan deze 4 checks", beperk je churn en houd je kosten stabiel.
Behandel budgeting als het plannen van een klein project, niet als één magische prompt. Een check van 2 minuten vangt de meeste overspend-problemen vroeg.
Loop deze items door en los elke "nee" op voordat je meer code genereert:
Als je Koder.ai gebruikt, behandel elk blok als een snapshotpunt: genereer een onderdeel, test het en ga dan verder. Snapshots en rollback zijn het meest waardevol vóór risicovolle wijzigingen (datamodelwijzigingen, brede UI-refactors of integratieherschrijvingen).
Een simpel voorbeeld: in plaats van te prompten "Bouw gebruikersbeheer", scope het naar "Email-login alleen, wachtwoordreset inbegrepen, geen social login, admin kan gebruikers deactiveren, moet tests hebben voor login en reset." Duidelijke checks verminderen retries, en retries zijn waar tokens en credits verdwijnen.
Hier een klein, realistisch voorbeeld dat je kunt kopiëren. De app is een intern hulpmiddel voor een team: login, twee eenvoudige modules en één integratie.
Ga ervan uit dat één "build cycle" is: kort plan, code genereren of bijwerken, snelle review en fix. Je credits volgen meestal hoeveel cycles je draait en hoe groot elke cycle is.
Featurelijst voor het interne hulpmiddel:
| Feature | Wat inbegrepen is | Laag | Typisch | Hoog |
|---|---|---|---|---|
| Login + rollen | Inloggen, uitloggen, twee rollen (Admin, User), beschermde pagina’s | 1 cycle | 2 cycles | 4 cycles |
| CRUD module 1 | "Employees" lijst, aanmaken/bewerken, basisvalidatie, zoeken | 2 cycles | 3 cycles | 6 cycles |
| CRUD module 2 | "Assets" lijst, aanmaken/bewerken, toewijzen aan medewerker, auditvelden | 2 cycles | 4 cycles | 7 cycles |
| Eén integratie | Stuur een event naar een externe service wanneer een asset wordt toegewezen | 1 cycle | 2 cycles | 5 cycles |
Een promptvolgorde die checkpoints strak houdt:
Kosten schieten omhoog als je beslissingen verandert nadat er code is. Veelvoorkomende triggers zijn rolwijzigingen (nieuwe rollen of permissiepaden), late velden (vooral die beide modules en de integratie raken), integratiefouten (auth-fouten, payload mismatch) en UI-herontwerpen nadat formulieren bestaan.
Volgende stappen: plan feature-voor-feature, bouw in cycles en check credits na elke cycle. Gebruik snapshots vóór risicovolle wijzigingen zodat je snel kunt terugrollen en het project binnen je typische bereik blijft.
Budgetteer altijd als een bereik omdat je betaalt voor pogingen, niet voor een vaste featureprijs. Kosten stijgen door:
Een “kleine” UI-wijziging kan duur zijn als deze logica, data of flows verandert.
Tokens zijn tekststukken die het model leest/schrijft (je prompt, de output en de chatgeschiedenis die het model opnieuw moet lezen).
Credits zijn de factureringseenheid van je platform (dekken vaak modelgebruik plus platformtaken zoals agenten en bestandsbewerkingen).
Build steps zijn zinvolle projectwijzigingen (een tabel toevoegen, een scherm koppelen, een endpoint maken). Eén feature heeft meestal meerdere stappen en elke stap kan meerdere modelaanroepen vereisen.
Schat in functies die een gebruiker zou benoemen ("wachtwoordlogin", "medewerkerslijst", "asset toewijzen") in plaats van in schermen of berichten. Voor elke functie maak je drie onderdelen:
Ken vervolgens lage/typische/hooge ranges toe en tel ze op.
Voeg twee expliciete regels toe:
Houd “latere wijzigingen” apart zodat je de oorspronkelijke schatting niet de schuld geeft van normale scopegroei.
Beschrijf wat “klaar” betekent voor auth. Belangrijkste kostenveroorzakers zijn:
Standaardiseer op één methode (email/wachtwoord) en 1–2 rollen voor voorspelbare kosten.
CRUD-kosten volgen gedrag, niet alleen tabellen. Voor elk entiteit definieer je:
CSV-import/export, audit logs, goedkeuringsworkflows of rijniveaupermissies moeten als aparte featurelijnen gebudgetteerd worden.
Breek “maak verbinding met X” in kleine, testbare delen:
Leg ook het datacontract vast (exacte velden) voordat je code genereert zodat het model geen extra tabellen of flows verzint.
Scope UI-werk als een lijst met pagina’s en staten:
Als een redesign validatie, dataladen of gebruikersstappen verandert, behandel het als featurewerk, niet als "alleen UI".
Gebruik een compacte promptstructuur:
Bouw daarna in kleine blokken (één endpoint of één scherm per keer) en her-schat na elk blok.
Stop na twee mislukte pogingen en verander de input, niet alleen de bewoording. Gebruik:
Vraag aan het einde van elke stap om een korte samenvatting van welke bestanden zijn aangepast zodat je ongewenste veranderingen snel ziet.