Prijzen bepalen

De vraag die bijna iedereen in het begin laat struikelen: wat vraag ik hiervoor. Te laag, en je werkt je kapot voor te weinig. Te hoog zonder onderbouwing, en je verliest het vertrouwen voordat je bent begonnen. De fout die de meeste beginners maken, is prijzen op basis van uren.

Hoeveel tijd heb ik erin gestoken, dus dat reken ik door. Het probleem daarmee is dat een systeem dat je dankzij Claude Code in een paar uur bouwt, voor de klant net zoveel waarde kan hebben als iets dat een traditioneel bureau in drie weken zou bouwen. Reken je op uren, dan beloon je jezelf voor traagheid, en straf je jezelf voor efficiëntie. Prijs daarom op waarde, niet op uren.

Kijk naar wat het probleem het bedrijf nu kost, en prijs een fractie van die waarde. Terug naar het verbouwingsbedrijf uit Module 4: stel dat ze door trage reacties elke maand een goede aanvraag verliezen aan een snellere concurrent, en zo'n project is voor dit bedrijf al snel een paar duizend euro waard. Als je systeem er per maand zelfs maar één extra aanvraag binnenhaalt die anders verloren was gegaan, is de waarde voor het bedrijf vele malen hoger dan wat jij ervoor vraagt. Een prijs van pakweg tweehonderdvijftig euro per maand voor onderhoud, plus een eenmalig opstartbedrag, is dan een vanzelfsprekende investering, ongeacht hoeveel uur jij er daadwerkelijk in hebt gestoken.

Een simpele structuur die voor de meeste eerste projecten werkt: een eenmalig bedrag voor het bouwen en live zetten, en een klein vast bedrag per maand voor onderhoud en hosting. Dat eenmalige bedrag baseer je op de waarde die je net hebt berekend, niet op een uurtarief. Het maandelijkse bedrag is meestal bescheiden, het dekt de tijd die je in Video 4.5 hebt gezien: een paar minuten per maand aan controle en bijsturen. De praktische conclusie: bereken eerst wat het probleem het bedrijf nu kost, prijs een deel van die waarde, en vraag niet aan jezelf hoeveel uur je erin hebt gestoken, maar aan het bedrijf hoeveel het probleem ze waard is om opgelost te hebben.