1 tip zorg dat alles 100% klip & klaar in een contract staat over wat betreft hun van jou verwachten.
Juist omdat je zelf al zegt dat de partij het ook zelf kan maken voorzie ik een risico dat jij je best doet voor van alles en nog wat en dat hun het uiteindelijk niet goed genoeg vinden en even tig delen gaan herschrijven en hiervoor xx uur op jouw betaling in korting berekenen (want dan heb jij het naderhand niet goed aangeleverd en jij mag dan niet meer inzien waar het werk in is gaan zitten etc en dan zit jij klem)
Ik zou gewoon heel simpel zeggen : Specificeer maar hoe jullie het aangeleverd willen hebben, zet er een vaste prijs bij en ik kijk wel of ik het in die vorm kan leveren.
Dan zitten namelijk alle involledige specificaties / herbouw stukken allemaal aan hun kant als jij het oplevert zoals gevraagd, terwijl wat jij nu zegt is dat jij alles wel gaat verzinnen en dat hun altijd kunnen zeggen dat het niet goed / goed genoeg was.
Dus wat is bijv panklare logica, is dat in de vorm van library's die hij gewoon moet kunnen linken, of is dat pseudo code waar de programmeur 100 uur in moet steken om het om te zetten naar daadwerkelijke code, of is dat source waar de programmeur daarna allerlei commentaar op kan geven (niet zijn coding style, niet zoals hij het wenst, hij herschrijft het wel in 50 uur).
Zolang je geen duidelijke overeenstemming hebt over wat jij gaat leveren (en wat de inspanning van hun programmeur moet zijn) kan je het bijna niet over een prijs gaan hebben, aangezien de prijs normaliter ook afhankelijk is van wat hun moeten doen, moet hun programmeur er 100 uur insteken dan praat je over een andere prijs dan wanneer hij enkel wat library's moet linken.
Als je bijv naar Alex) zijn voorstel kijkt, goede documentatie aanleveren van public methods is wmb wel genoeg als je library's aanlevert, maar weer niet als je source gaat aanleveren (dan moet in principe "alles" gedocumenteerd zijn).
Maar unit tests heb ik weer minder aan als het om library's gaat en meer als het om source gaat.
Alex) heeft het over een API (ok het is een ruim begrip maar toch) maar wil de klant dit wel, of wil die liever copy-pasten (met een fatsoenlijke API is het redelijk irrelevant dat de klant code kan herschrijven, als hij iets binnen de API gaat herschrijven dan moet hij ook alle documentatie aanpassen en had hij het waarschijnlijk sneller vanaf scratch kunnen bouwen)
Oftewel : Informeer wat de klant wil en denk mee met de klant maar ga niet voor de klant dingen bedenken