• 0

Contract opstellen voor ontwikkeling app

Goedenmorgen,

 

Ik ben Daan. 17 Jaar en een student. Ik bedacht afgelopen week een idee voor een bepaalde iPhone/Android app. Na wat research is dit idee nog niet eerder uitgevoerd, en omdat ik denk dat er veel potentie inzit, wil ik het zelf gaan ontwikkelen.

Ofja, de ontwikkeling laat ik aan een ingehuurde ontwikkelaar over. En hier zit dan meteen mijn vraag.

 

Ik wil een contract opstellen, waarin staat dat ik altijd alle rechten behoud voor de app, over de betalingtermijn etc, etc. Maarja, ik heb geen flauw idee, hoe en waar ik moet beginnen.

 

Ook wil ik graag dat in het contract komt te staan dat hij het idee niet voor zichzelf mag gaan gebruiken. Een soort geheimhoudingsverklaring dus.

 

Kunnen jullie mij misschien op weg helpen? Want ik kom er echt niet uit.

 

Groeten,

Daan

 

[titel aangepast - mod]

Link naar reactie

Aanbevolen berichten

18 antwoorden op deze vraag

  • 0

Bedankt voor de reactie. Ik neem aan dat je met "follow up'' bedoeld wat er na het opstellen van het contract gebeurd?

 

Ik ben van plan om het zo te doen.

 

De ontwikkelaar krijgt 10% van de winst, met een nader te bespreken maximum. Ook moeten alle bugs(fouten) die erin zitten, kostenloos worden verholpen. Dit soort dingen wil ik in een contract zetten. Het komt misschien door mijn leeftijd, maar ik zie door de bomen het bos niet meer, helaas.

Link naar reactie
  • 0

Ik wil een contract opstellen, waarin staat dat ik altijd alle rechten behoud voor de app, over de betalingtermijn etc, etc. Maarja, ik heb geen flauw idee, hoe en waar ik moet beginnen.

 

Ook wil ik graag dat in het contract komt te staan dat hij het idee niet voor zichzelf mag gaan gebruiken. Een soort geheimhoudingsverklaring dus.

 

Over het idee beschermen is al het e.e.a. gezegd.

 

De concrete uitwerking van het idee is een ander verhaal. De applicatie (zijn broncode, user interface, logo etc.) wordt beschermd door het auteursrecht. Maar let op: dat ligt standaard bij de maker. De ontwikkelaar dus (behalve misschien een user interface, als jij die ontwerpt of voorschrijft). Het is dus zaak in het contract te regelen dat het auteursrecht aan jou wordt overgedragen.

Link naar reactie
  • 0

De ontwikkelaar krijgt 10% van de winst, met een nader te bespreken maximum. Ook moeten alle bugs(fouten) die erin zitten, kostenloos worden verholpen.

 

Je mag het natuurlijk proberen, maar als ontwikkelaar zou ik je hartelijk uitlachen :) Dat wil zeggen, als je bedoelt dat hij alleen maar 10% van de winst krijgt, en niet ook een vergoeding op basis van bijvoorbeeld uren x tarief. Wat is jouw bijdrage eigenlijk voor de resterende 90%?

Link naar reactie
  • 0

Ik wil een contract opstellen, waarin staat dat ik altijd alle rechten behoud voor de app, over de betalingtermijn etc, etc. Maarja, ik heb geen flauw idee, hoe en waar ik moet beginnen.

 

Ook wil ik graag dat in het contract komt te staan dat hij het idee niet voor zichzelf mag gaan gebruiken. Een soort geheimhoudingsverklaring dus.

 

Over het idee beschermen is al het e.e.a. gezegd.

 

De concrete uitwerking van het idee is een ander verhaal. De applicatie (zijn broncode, user interface, logo etc.) wordt beschermd door het auteursrecht. Maar let op: dat ligt standaard bij de maker. De ontwikkelaar dus (behalve misschien een user interface, als jij die hebt ontworpen of voorschrijft). Het is dus zaak in het contract te regelen dat het auteursrecht aan jou wordt overgedragen.

 

Het beschermen is duidelijk inderdaad. Ik wil ook in het contract vermelden, dat ik alle rechten op de app krijg.

 

De ontwikkelaar stemde met dit idee in, hij vond het een prima plan ,en vroeg me vervolgens een contract op te stellen.

 

Mijn bijdrage is eigenlijk de rest, het publiceren van de app, website maken, reclame maken etc. Het is alleen de ontwikkeling die ik uitbesteed.

 

Link naar reactie
  • 0

Hoe staat je uren inzet tegenover die van de developer? Lees eens over hoe start-ups e.d. werken, daar kan je veel van leren qua samenwerking. In veel gevallen is een kromme verhouding reden tot ergernis en laat het uiteindelijk nergens op uitlopen.

Bezoekhetziekenhuis.nl: Eenvoudig bezoeken plannen aan de patiënt en communiceren met patiënt, familie en vrienden. ! Maak een account aan als een familielid in het ziekenhuis ligt en je kunt gezamenlijk de bezoektijden inplannen.

Link naar reactie
  • 0

Ook moeten alle bugs(fouten) die erin zitten, kostenloos worden verholpen.

Met alle respect, maar dit doet geen verstandige ontwikkelaar.

Dit zou betekenen dat hij tot in lengte van dagen kan worden aangesproken op zijn werk, nog afgezien van het feit dat de discussie of iets een bug is of juist niet tot ellelange discussies kan leiden.

In principe is een bug een afwijking van de specificaties. Als je die al 100% eenduidig weet op stellen (en dat lukt vaak al niet; en dan begint de discussie als hij een eenvoudige variant kiest en jij de complexe variant in gedachten had) heb je als ontwikkelaar ook te maken met afhankelijkheden. Als er een bug in iPhone OS zit, en hij daardoor een tijdrovende work around moet bedenken, is dat dan zijn risico of jouw risico?

 

Link naar reactie
  • 0

bedankt voor de reacties. Ben maar gewoon begonnen met de opzet van het contract. heb alleen moeite met de layout en de zinsopbouw: Hieronder het contract.

 

 

NAAM WEGGEHAALD is de opdrachtgever

NAAM WEGGEHAALD is de ontwikkelaar.

De applicatie en alles wat daar omheen zit blijft eigendom van de opdrachtgever. De applicatie zal onder naam van de opdrachtgever worden uitgebracht.

Aan de ontwikkelaar zal 10 % van de omzet worden uitbetaald, met een maximum van €1000,-

De opdrachtgever heeft altijd het recht het project te stoppen, als de app niet volledig functioneert of er problemen zijn met de ontwikkelaar. In dit geval hoeft er niks te worden betaald. Wel moet er een geldige reden zijn om het project te stoppen.

Als er een applicatie update moet worden uitgevoerd, wordt er per update een bedrag betaald van €65 per uur.

Voor, tijdens en na het ontwikkelen van de applicatie mag de ontwikkelaar niet met eenzelfde soort applicatie bezig gaan. Ook niet als het project wordt geannuleerd.

De ontwikkelaar mag geen details over de applicatie prijsgeven aan derden als de applicatie nog niet in de Apple App Store staat.

Bugs(fouten in de software) worden er kostenloos uitgehaald. Dit hoort bij het correct opleveren van de Applicatie.

 

Link naar reactie
  • 0

De applicatie en alles wat daar omheen zit blijft eigendom van de opdrachtgever.

 

Dat klopt niet. Het auteursrecht op de programmatuur ligt namelijk bij de programmeur, de opdrachtnemer. Het kan niet ergens blijven waar het niet is. Wat je wilt is het auteursrecht laten overdragen aan de opdrachtgever.

 

Aan de ontwikkelaar zal 10 % van de omzet worden uitbetaald

 

Je moet nauwkeuriger afbakenen wat in dit geval onder omzet wordt verstaan. Dat kan de eindafnemersprijs zijn, of de netto omzet na aftrek van belastingen, marge van het verkoopkanaal, kosten van het betalingssysteem e.d.

 

De opdrachtgever heeft altijd het recht het project te stoppen, als de app niet volledig functioneert of er problemen zijn met de ontwikkelaar. In dit geval hoeft er niks te worden betaald. Wel moet er een geldige reden zijn om het project te stoppen.

 

Dit roept de vraag op: wat zijn geldige redenen, anders dan de in eerste zin genoemde redenen? Als die er niet zijn, waarom dan de laatste zin toevoegen?

 

En "er problemen zijn met de ontwikkelaar" is veel te vaag. Daar zul je je denk ik nooit met succes op kunnen beroepen.

 

Als er een applicatie update moet worden uitgevoerd, wordt er per update een bedrag betaald van €65 per uur.

 

Een bedrag per uur betaal je per uur, niet per update. In het contract zul je moeten definiëren wat een "applicatie-update" is.

 

Voor, tijdens en na het ontwikkelen van de applicatie mag de ontwikkelaar niet met eenzelfde soort applicatie bezig gaan. Ook niet als het project wordt geannuleerd.

 

Dat lijkt me een veel te ruime uitsluiting. Als ontwikkelaar zou ik zoiets nooit tekenen.

 

De ontwikkelaar mag geen details over de applicatie prijsgeven aan derden als de applicatie nog niet in de Apple App Store staat.

 

Maar dit zou ik juist ruimer en algemener stellen. Waarom zou hij wel details mogen prijsgeven als de applicatie eenmaal in de App Store staat?

 

En definieer "details". Valt broncode eronder?

 

Bugs(fouten in de software) worden er kostenloos uitgehaald. Dit hoort bij het correct opleveren van de Applicatie.

 

Hier zei wimj al wat over. Een (juridisch) ervaren ontwikkelaar zou dit nooit zo onbegrensd tekenen. Typische ICT-contracten bevatten op dit punt heel andere bepalingen, waarmee de ontwikkelaar zich indekt.

 

In de praktijk levert dit na verloop van tijd waarschijnlijk discussie op over wat wel en niet een bug is, en of een bug die maanden na dato wordt gemeld nog wel tot de oplevering kan worden gerekend. Dat kan leiden tot conflicten, en als je dan met het contract in de hand naar de rechter gaat, dan zal die een redelijke invulling en inperking moeten geven aan vage, ruime en onbegrensde clausules. De uitkomst daarvan is onzeker, en daarom kun je de clausules misschien beter zelf maar redelijk begrenzen, dan weet je tenminste waar je aan toe bent.

Link naar reactie
  • 0

bedankt Rene! Ja, ik vind dit zoo moeilijk! Dus sorry als ik wat domme vragen stel/dingen doe.

 

na het publiceren in de app store, is het idee toch al bekend, dan mag ie er wel over praten. Toch?

 

Ik heb hier een verbeterd contract, die met jou punten is verbeterd.

 

 

NAAM WEGGEHAALD is de opdrachtgever

NAAM WEGGEHAALDis de ontwikkelaar.

Het auteursrecht zal worden overgedragen aan de opdrachtgever.

Aan de ontwikkelaar zal 10 % van de netto omzet worden uitbetaald, met een maximum van €1000,-

De opdrachtgever heeft altijd het recht het project te stoppen, als de app niet volledig functioneert of er problemen zijn met de ontwikkelaar. In dit geval hoeft er niks te worden betaald.

Als er een applicatie update moet worden uitgevoerd, wordt er een bedrag betaald van €65 per uur. Een applicatie update kan bevatten:

-Bugfixes

-Nieuwe functionaliteiten

- Het uitbreiden of verbeteren van bestaande functionaliteiten.

 

Voor, tijdens en na het ontwikkelen van de applicatie mag de ontwikkelaar niet met een applicatie bezig gaan die dezelfde (unieke) functionaliteiten bied.

De ontwikkelaar mag geen details over de applicatie prijsgeven aan derden als de applicatie nog niet gepubliceerd is in de Apple App Store. Onder details wordt verstaan:

-praten over het idee met derden.

-Het vertonen van logo’s of previews aan derden

 

De broncode mag niet, op geen enkele wijze openbaar worden gemaakt.

 

De applicatie moet 2 maanden na de start zijn opgeleverd.

 

Link naar reactie
  • 0

Ik vind dat er nog veel te veel mis is met dit contract. Met name de vaagheid, ongedefinieerde begrippen, tegenstrijdigheden, onbegrensdheden, open eindjes etc. Met onze adviezen kom je er zo te zien niet helemaal uit. Ik denk dat je beter met dit conceptcontract langs een ict-jurist kunt gaan, die kan een deugdelijk contract voor je opstellen.

 

Om maar eens iets te noemen... je kunt wel in een contract zetten "dit of dat mag niet", maar wat als het toch gebeurt? Dan ben je van de rechter afhankelijk om een redelijke consequentie of vergoeding te verzinnen. Dat kun je misschien beter zelf regelen.

 

Heeft de ontwikkelaar nog niet met zijn algemene voorwaarden gewapperd?

Link naar reactie
  • 0

Als ik het contract wat je nu in gedachten hebt doorlees vallen me

een aantal zaken op.

 

1) Alle risico's liggen bij de ontwikkelaar. Heel simpel gezegd:

jij hebt een naar ik aanneem een briljant idee. Vervolgens mag iemand

daar het echte werk voor gaan doen, en zijn verdiensten zijn

sterk gemaximeerd. En jij zit lekker achterover en casht.

Mocht het misgaan dan wacht je op het volgende idee, en

de ontwikkelaar heeft X uren voor niets gewerkt.

 

2) Juridisch rammelt het aan alle kanten.

Wat gebeurt er bijvoorbeeld met de rechten als jij besluit de applicatie

ontwikkeling te stoppen omdat er bugs in zitten? Wie

is dan eigenaar van de applicatie die wellicht al voor

80% af is? Krijgt de ontwikkelaar dan iets vergoed?

Een bug in de applicatie kan geen reden zijn om

het project direct te stoppen (en niets te betalen): de ontwikkelaar

moet wel een kans krijgen om een en ander te herstellen.

 

3)

Is de ontwikkelaar verplicht om de updates uit te voeren,

ook al wordt hij er voor betaald? En als hij dat besluit

niet te doen, hoe staat het dan met de betaling van

de uitgebreide versie. De ontwikkelaar vindt het vast

lullig als hij geen tijd meer heeft, en iemand anders

twee kleine aanpassingen maakt en de oorspronkelijke

ontwikkelaar kniets meer krijgt.

 

Ik sluit me aan bij de andere spreker: neem een

jurist in de hand, of probeer op een andere manier

een voorbeeld contract te krijgen.

 

Zaken die minimaal in zo'n contract staan zijn:

1) Omschrijving van de applicatie.

2) Tijdpad.

3) Acceptatiecritria. Hierin leg je bijvoorbeeld vast

dat na oplevering jij twee weken de tijd hebt om

te testen. Hierin wordt ook vastgelegd wat een bug

is, en met name dat jij een bug reproduceerbaar

moet documenteren.

4) Rechten en plichten van beide partijen.

5) Ontbinding

 

 

Link naar reactie
  • 0

Hoi Wim,

 

Bedankt voor je reactie.

 

Wat bedoel je precies met tijdspad? Ik heb er al instaan dat de applicatie 2 maanden na de start moet zijn opgeleverd. Of moet dit preciezer?Heb nu hetvolgende:

 

 

Daan NAAM WEGGEHAALD is de opdrachtgever

NAAM WEGGEHAALD is de ontwikkelaar.

Het auteursrecht zal worden overgedragen aan de opdrachtgever.

Aan de ontwikkelaar zal 10 % van de netto omzet worden uitbetaald, met een maximum van €1000,-

De opdrachtgever heeft altijd het recht het project te stoppen, als de applicatie niet naar behoren functioneert(De applicatie doet niet waar die voor is gemaakt, of niet goed.) of er een geschil is met de ontwikkelaar. In dit geval hoeft er niks te worden betaald.

Als er een applicatie update moet worden uitgevoerd, wordt er een bedrag betaald van €65 per uur. Een applicatie update kan bevatten:

-Bugfixes

-Nieuwe functionaliteiten

- Het uitbreiden of verbeteren van bestaande functionaliteiten.

 

Voor, tijdens en na het ontwikkelen van de applicatie mag de ontwikkelaar niet met een applicatie bezig gaan die dezelfde (unieke) functionaliteiten bied.

Wanneer de ontwikkelaar de applicatie niet besluit uit te werken, mag de ontwikkelaar niet met een applicatie bezig gaan die dezelfde (unieke) functionaliteiten bied.

De ontwikkelaar mag geen details over de applicatie prijsgeven aan derden als de applicatie nog niet gepubliceerd is in de Apple App Store. Onder details wordt verstaan:

-praten over het idee met derden.

-Het vertonen van logo’s of previews aan derden

 

De broncode mag niet, op geen enkele wijze openbaar worden gemaakt zonder schriftelijke toestemming van de opdrachtgever.

 

De applicatie moet 2 maanden na de start van het project zijn opgeleverd.

Bij oplevering heeft de opdrachtgever maximaal 7 dagen de tijd om de applicatie te testen. Als er na 7 dagen geen reactie is, mag de ontwikkelaar aannemen dat de applicatie naar behoren werkt.

 

Handtekening voor akkoord:

NAAM WEGGEHAALD

 

------------------------------

Daan NAAM WEGGEHAALD

------------------------------

 

Link naar reactie
  • 0

Ik denk toch echt dat je een deskundige dit contract zult moeten laten opstellen.

Voor wat betreft het tijdpad: inderdaad staan daar nu een aantal zaken van in het contract

Maar niet alle. Stel dat je een bug vindt, dan wil je ook dat deze binnen een zekere

periode zijn opgelost.

Voor wat betreft de twee maanden: wat is de start van het project?

Als het contract getekend wordt? Als jij dan eerst nog een nauwkeurige specificatie

moet maken, en daardoor de eerste 3 weken opslokt krijg je een heel andere

situatie als die waarin je duidelijke specificaties heb gemaakt (en die op maakbaarheid

hebt laten beoordelen) die op de start van het project klaar liggen.

 

Daarnaast zijn er nog een redelijk aantal opmerkingen gegeven door diverse mensen, die

niet overgenomen zijn in je concept contract. Dat mag je natuurlijk doen, dus ik zal

niet in herhaling vallen. Maar het geeft me geen positief gevoel over dit contract.

 

Laat ik dan nog maar eens een puntje noemen. In een software traject krijg je

*altijd* te maken met wijzigingen. Zaken die je vergeten bent (je

hebt een mooi adres scherm gemaakt maar je bent vergeten dat je internationale

ambities hebt, dus het land moet ook kunnen worden opgegeven), of gewoon

zaken die achteraf niet handig zijn (simpel voorbeeld: je kleurstellingen

zijn onleesbaar). Daarnaast kunnen er onduidelijkheden zitten in de specs,

waardoor de ontwikkelaar vragen gaan stellen.

Hoe ga je hier mee om?

 

Wellicht zie ik allemaal spoken: mijn ervaring met dit soort contracten ligt

veel meer op de 100K plus projecten; maar het zijn wel allemaal zaken

waarmee je te maken kan krijgen.

 

Heb je trouwens wel eens gesproken met de ontwikkelaar over de contractvorm?

 

Wellicht heeft iemand hier een voorbeeld contract?

Link naar reactie
  • 0

Bedankt voor je reactie!

 

De ontwikkelaar vertelde dat ik een contract moest maken, en deze op moest sturen.

 

Hmm, ja, ik moet maar is iemand in gaan huren denk ik. Toch bedankt voor de reacties!

ik probeer en stunt nog even verder, en laat alles vervolgens checken.

 

Groeten,

Daan

Link naar reactie
Gast
Dit topic is nu gesloten voor nieuwe reacties.
Hide Sidebar
  • Wil je onze Nieuwsflits ontvangen?
    Deze verzenden we elk kwartaal.

  • Wie is er online?
    6 leden, 175 Gasten

  • Breng jouw businessplan naar een higher level!

    Op dit forum worden alle onderwerpen m.b.t. ondernemerschap besproken.

    • Stel jouw ondernemersvragen
    • Antwoorden/oplossingen van collega ondernemers
    • > 75.000 geregistreerde leden
    • > 100.000 bezoekers per maand
    • 24/7 bereikbaar / binnen < 6 uur antwoord
    •  Altijd gratis

  • Ook interessant:

    Ook interessant:

×
×
  • Nieuwe aanmaken...

Cookies op HigherLevel.nl

We hebben cookies geplaatst op je toestel om deze website voor jou beter te kunnen maken. Je kunt de cookie instellingen aanpassen, anders gaan we er van uit dat het goed is om verder te gaan.