Archief - Q: Websites tarieven ?

Weldra ga ik via het school een bedrijfje opstarten. Één van onze deeltakken zal sites ontwerpen en maken inhouden.
De doel-klanten-groep zijn kleine zelfstandigen, particulieren, organisaties, ...

We gaan onderscheid maken tussen:

* Puur HTML / CSS
* Met basic PHP scriptjes (newsposts/gastenboek/mailform)
* Volledig ASP gecodeerde sites (webshop toestanden)

Gesorteerd van relatief weinig werk naar enorm veel werk.
Alle codes zelf geschreven, ontwerpen zelf gemaakt en zo. Eventueel hier en daar aangerijkt met flash en javascript. Nu heb ik absoluut geen idee wat de prijzen hiervoor zijn.

Alles is overigens volledig legaal en officieel. Daar het een onderneming zal zijn - zonder BTW nummer wel - maar met een speciaal statuut van de overheid en die shit. Dus een officiële factuur mogen we maken enzo, en zal ook rechtsgeldig zijn.

Van het simpelste, dus enkel HTML en CSS, heb ik een voorbeeld dat ik vorig jaar gemaakt heb. Namelijk: http://zimpath.meloen.be/
Wat zou zoiets mogen kosten ?

ik denk dat het gemakkelijkste is om het aantal uren op te tellen dat je er aan werkt en een vast bedrag per uur aanrekent
hoeveel dat dan is moet je zelf weten ...

mjah, hangt van je werksnelheid af eh...

Want aan zo'n ASP site / webshop volledig zelf schrijven ben je enorm lang bezig. Maar voor de tweede klant is het slechts een kopie nemen, en lichte aanpassingen doen. Dus daar zou je bv 500 tegenover 25 uur werken, voor hetzelfde...

Ik zou eerder de prijs bepalen a.d.h.v verschillende factoren i.p.v. uren:

- Aantal pagina's
- Graad van integratie graphics
- Graad van integratie codes
- Moeilijkheid van .../aard van codes
- Speciale eisen (Flash, extra onderhoud, ...)
- ... en zo verder

Ik denk dat je het best werkt met (redelijk nauwkeurige, liefst) prijsschatting op voorhand en na het werk een complete afrekening. Maar geef dus eerst adhv een prijsofferte de klanten een idee van wat ze mogen gaan betalen.

Dat dacht ik ook, maar wat vraagt men zo tegenwoordig voor een standaard html pagina, of voor een php nieuws script ofzo ?

ge zijt ni de enigste die daar atm zit over te denken

hangt er een beetje vanaf hoe 'ernstig' je het opneemt. als dat je hoofdberoep gaat worden, mag je €12.5/uur rekenen (bruto is dat dan €25/uur).
als het meer als hobby/bijverdienste is, misschien iets minder.

dan kun je een schatting maken van hoe lang je er aan zal zitten of hoe veel werk het is en een prijsschatting maken.

het hangt er natuurlijk van af of er veel werk in de layout moet worden gestoken, veel programmeerwerk, complexiteit van een database, etc. zulke zaken kun je pas op voorhand inschatten wanneer je al een tijdje bezig bent en meer ervaring hebt.

per pagina? ge hebt pagina's en PAGINA'S.

rekenen doe je in manuren. bepaal je tarief/uur (vergeet geen bedragen in dit tarief op te nemen die uw kosten dekken en uw toegevoegde waarde maken)

voor een exact geschikte prijs van zo ne webshop moet ge rekening houden met uw markt en marketing. hoeveel gade er kunnen aansmeren? tga ook maar om een tijdelijke onderneming als ik mij ni vergis (schoolse mini-onderneming).

als het tijdelijk is, is het geen selcht idee uit te rekenen:

((manuren om een webshop te maken *tarief) / aantal geschatte webshops) + een surpluske voor alles wat er minder vlot kan lopen.


btw: middenklas: enkele php scriptjes, luxe ding is dan weer me asp.
tis best da ge bij 1 taal blijft om het overzichtelijk te houden, hetzij php, hetzij asp

Ik zou persoonlijk niet in manuren tellen. Waarom? Als ge nog maar juist begint met iets, gaat ge ontzettend lang aan iets bezig zijn, dus gaat je prijs veel te hoog zijn tov concurrentie (met meer ervaring).
Ten tweede, hoe wilt ge dat controleren? Hoe gaat ge uw klant wijsmaken dat ge daar effectief 100 uur aan hebt gewerkt als het effectief maar 60 was?
Het is beter te werken met modules zoals hierboven vermeld. De klant heeft een beter zicht op de kostprijs, hij moet trouwens niet weten hoe lang gij aan iets bezig bent.

bvb: klant heeft bep. probleem, op te lossen door 5 minuten werk. Gaat ge hem laten betalen voor die 5 minuten (5 euro?) of voor het oplossen van zijn dringend probleem dat zooo belangrijk was (100 euro om maar iets te zeggen..)

Langs de andere kant, het is voor u een extra motivatie om iets snel af te werken, kunt ge meerdere zaken doen en meer verdienen. Ipv uren te rekken om meer te kunnen krijgen.

Anendel zei:

Ik zou persoonlijk niet in manuren tellen. Waarom? Als ge nog maar juist begint met iets, gaat ge ontzettend lang aan iets bezig zijn, dus gaat je prijs veel te hoog zijn tov concurrentie (met meer ervaring).

Klik om te vergroten...

't Ja, dat hangt van je prijs/uur af. Daarom kan iemand met meer ervaring een beter prijs/uur aanrekenen. Dus deze vlieger gaat niet op.

Anendel zei:

Ten tweede, hoe wilt ge dat controleren? Hoe gaat ge uw klant wijsmaken dat ge daar effectief 100 uur aan hebt gewerkt als het effectief maar 60 was?

Klik om te vergroten...

Wie moet dat controleren? De klant niet, die heeft zijn budget gekregen(groot budget), of er is een aantal uur afgesproken(klein budget). De enigste die er wat aan heeft ben je zelf. Om je productieviteit te berekenen. Of je overhead hebt of dat je winst maakt. En kan je pas evalueren na een paar projecten.

Anendel zei:

bvb: klant heeft bep. probleem, op te lossen door 5 minuten werk. Gaat ge hem laten betalen voor die 5 minuten (5 euro?) of voor het oplossen van zijn dringend probleem dat zooo belangrijk was (100 euro om maar iets te zeggen..)

Klik om te vergroten...

minimum tijdsblok(bv een half uur) bepalen in contract misschien? Voor de klant is trouwens alles dringend

Anendel zei:

Langs de andere kant, het is voor u een extra motivatie om iets snel af te werken, kunt ge meerdere zaken doen en meer verdienen. Ipv uren te rekken om meer te kunnen krijgen.

Klik om te vergroten...

Je kan dus pas van algemene prijzen spreken, als je weet wat je waard bent per uur. Na genoeg ervaring met budgeten en timetracking weet je ongeveer wat je waard ben per uur en weet je ook hoelang je aan een project ongeveer werkt. Dan kan je dus een offerte maken met een algemene prijs. Na het project evalueer je de uren en kijk je of je winst/verliest gemaakt hebt.
Als je pas begint en daar nog geen idee van hebt werk je best met uur tarieven naar de klant toe. Maar professioneel is iets anders. De meeste offertes voor projecten waar met uur tarief gewerkt wordt vallen meteen uit de boot.

greetz.

vandaar dat ervaring belangrijk is om te weten hoe lang je aan iets bezig bent.
in het begin kun je beter uitrekenen in manuren, maar na verloop van tijd krijg je er een beter zicht op en kun je op voorhand beter inschatten hoeveel het gaat kosten.

En hopen dat je klanten niet op de hoogte zijn van de concurrentie, want dan ga je niet veel verdienen.

Anendel zei:

Het is beter te werken met modules zoals hierboven vermeld. De klant heeft een beter zicht op de kostprijs, hij moet trouwens niet weten hoe lang gij aan iets bezig bent.

Klik om te vergroten...

had het dan ook over bv heto nderdeel webshop, wat een module is.
ge ga ook ni rechtreeks manuren aanrekenen aank lant he; manuren is uwe kost, da gebruikt ge om een idee te krijgen wa u da "kost" in manuren.

vadaar die formule. voor modules glijk die webshop.

voor andere pagina's hangt da af van klant tot klant. als alles in standaardprijzen staat, wil da zegen da ge ni echt het "mass costumisation" paradigma nastreeft

DJ_Trash zei:

btw: middenklas: enkele php scriptjes, luxe ding is dan weer me asp.

Klik om te vergroten...

Wat heeft de kwaliteit van de scripts nu in godsnaam te maken met de taal die je gebruikt? Juist ja, niks. Je kan in beide crappy en goede code schrijven, het ene doet niet onder voor het andere (nu ja, ASP doet redelijk onder aangezien PHP meer gestandariseerde libs gebruikt en ASP z'n COM componenten - op enkele uitzonderingen na - niet echt ingeburgerd zijn).

BTW Misschien bedoel je "mass customization" hierboven? Niet gooien met termen die je niet eens kan neerschrijven, maar jah, marketingmannetjes doen niks anders. Ze moeten nu eenmaal lucht kunnen verkopen .