Opstart in bijberoep - contracteisen 1e klant

[ruby01]

Dag mede-Tweakers,

Ik zoek even hulp hoe ik mijn huidige situatie het beste aanpak. Concreet zit ik in de volgende situatie:

Ik ben ingenieur van opleiding, maar niet in de IT. De passie ervoor is echter aanwezig en ik programmeer wel vaker kleinere zaken. Op mijn huidig/vorige werk ben ik 5%/100% bezig met software development.
Het programmeren kriebelede wel aangezien ik nu minder bezig ben met softwareontwikkeling. Toen ik een 2-tal jaar geleden bij een vriend was zag ik dat hij heel erg ouderwetse software moest gebruiken. Toen ik vervolgens hoorde dat ze er +- 75 €/maand voor moesten betalen dacht ik bij mezelf dat ik het evengoed zou kunnen doen en dat ik dit als bijberoep zou kunnen doen (ergo software as service aanbieden). Veel meer dan een database bijhouden en PDF'en genereren was het eigenlijk niet..

Nu, een 2-tal jaar later heb ik een product waarvan ik denk dat het rijp is voor de markt aangezien het dezelfde features heeft als mijn "concurrent", en daar bovenop heb ik nog extra features toegevoegd zodanig dat ik een meerwaarde kan brengen. Dezelfde vriend heeft mijn product gepitched bij zijn baas en die waren direct overtuigd. Duidelijk waren ze al langer op zoek naar een product dat volledig naar hun wensen was en door het beperkte aantal aanbieders zaten ze wat vast. Na enkele meetings komen er echter enkele zaken naar boven waarbij ik mij minder op mijn gemak bij voel:

• Ze willen de functies van verschillende bestaande programma's samenvoegen in hun nieuwe programma. Aangezien ik tot nu maar 1 programma nagebouwd heb moeten er nog heel wat features bijkomen (minstens dubbel de hoeveelheid werk in vergelijking met wat ik tot nu toe gedaan heb). Hierbij is er ook al een tijdslimiet vastgelegd aangezien hun duurste pakket in de zomer vernieuwd moet worden.
• Tot nu toe was er geen/weinig risico in de zin van dat mogelijke bugs niet kunnen leiden tot inkomstenverlies van mijn "klant". De nieuwe features die ze willen omvatten o.a. een agendasysteem voor hun klanten, mogelijkheid tot aankopen van merch, ect. Fouten hierbij kunnen dus zorgen voor geldverlies. Hierbij kwam de opmerking dat er in het toekomstige contract een opmerking moet komen dat kritieke bugs binnen de 24 uur opgelost moeten worden en dat gewone bugs binnen een nog te bepalen periode opgelost moeten worden. Indien dit niet zou gebeuren willen ze er een geldboete aan koppelen. Aangezien ik dit als bijberoep zou doen heb ik niet de mogelijkheid om bij eender welke bug direct alles te laten vallen uiteraard.
• Ik zag het altijd als "software as service", waarbij ik een dienst aanlever en waarbij ik gerust features op aanvraag wil toevoegen. Hierbij zou de broncode dus altijd bij mij blijven, met natuurlijk het risico van mijn klanten dat, als ik er ooit de brui aan geef, zij een ander pakket moeten zoeken. Hier doen ze al moeilijk over in de zin dat ze garanties willen dat ze altijd door kunnen gaan met een andere partner als ik/zij het niet meer zien zitten. Dit is natuurlijk volkomen begrijpbaar van hun kant uit.
  Bij software as service zou de klant dus een maandelijks bedrag betalen, maar als ik de code moet (kunnen) afgeven is dit meer programmeren op aanvraag, wat natuurlijk in een volledig ander prijsveld ligt volgens mij. Als ik echt code moet afgeven zie ik het meer als een loon dat ze zouden moeten betalen voor de uren die ik erin steek. De potentiële klant heeft echter al aangegeven niet veel te willen uitgeven. Ter vergelijking: nu geven ze in totaal 400€/maand uit aan verschillende pakketten samen.
• Via via ben ik te weten gekomen dat de klant inderdaad niet zoveel zou willen uitgeven, maar de assistent ervan (die ervaring heeft in softwareontwikkeling) heeft het bovenstaande geldprobleem van software as service versus software op maat duidelijk gemaakt aan haar baas. Gevolg hiervan is dat ik gepaaid wordt met de optie dat we zouden kunnen samenwerken. Hierbij zou mijn eerste klant dus een partner worden en zij zouden instaan voor marketing/nieuwe klanten aanbrengen en ik zou dan instaan voor de ontwikkeling. Hierdoor zouden ze dus de code kunnen verkrijgen onder het mom van partnership, en tegelijk minder moeten betalen aangezien ze klanten aanleveren. De extra inkomsten van klanten zou dan nog via een te bepalen verdeelsleutel moeten verlopen.

Wat is jullie mening hierover? Is het normaal dat bugs verplicht binnen een bepaalde periode opgelost moeten worden? Het huidige pakket dat ze gebruiken zit vol met bugs die al maanden niet opgelost worden en in hun voorwaarden staat letterlijk dat ze er niet aansprakelijk voor zijn. En hoe zien jullie het op een financieel vlak? Vraag ik loon naar uren? Of puur een maandelijkse fee vergelijkbaar met de kosten die ze nu hebben?

Maak ik me teveel zorgen en moet ik de stap gewoon zetten, met de kans dat het snel groeit en dat ik volledig zelfstandig kan worden? Enerzijds zie ik dit als een kans aangezien ik zelf niet moet zoeken naar klanten en dat ik iets op mezelf kan uitbouwen, anderzijds lijkt het mij snel heel erg veel werk te zijn met een minimale return (in het begin?).

Alvast bedankt voor de feedback!

[eamelink]

Bedragen in de orde van 400 euro per maand zijn te klein voor bespoke software-ontwikkeling. Je hebt dan immers al gauw zo'n 25 klanten nodig om rond te komen, dus beperkte tijd voor een klant, en ook zeer beperkte mogelijkheden om iets specifiek te bouwen voor één klant.

Meegaan in hun wensen tot het vervangen van verschillende pakketten leidt al snel tot een roadmap waar zij wel, maar jij niet bij gebaat bent. Pas daar dus voor op.

Een SLA is niet gek, maar wat kan je verwachten bij een product van enkele honderden euro's per maand? Zorg dat je geen resultaatverplichting overeen komt, maar hooguit een inspanningsverplichting. En maximeer je vergoeding bij grove schending van de SLA op bijvoorbeeld één maand abonnementsgeld.

Met je launching customer afspreken dat zij een gebruiks- en of doorontwikkelrecht krijgen als jij de handdoek in de ring gooit, is niet gek, maar dan wel in ruil voor een daadwerkelijke investering van hun kant. En zorg dat de voorwaarden helder zijn - geen overdracht van het volledige IP, maar alleen een eigen gebruiksrecht, en alleen als jij daadwerkelijk stopt met je onderneming, niet als zij je niet meer aardig vinden.

Het is prima om een kickback-fee te geven als ze nieuwe klanten aanbrengen. Maar ook daar; boter bij de vis. Dus een normaal tarief betalen, en eventuele commissies of kickback-fees er vanaf trekken (of uitbetalen, als ze het heel goed doen ). Maar geen korting geven op basis van alleen de intentie om te werven voor je.

In z'n algemeenheid lijkt de klant te zoeken naar de voordelen van bespoke software development, maar dan tegen een fractie van de kosten. Dat is gevaarlijk voor jou. Zorg dus vooral dat je je focus houdt op de volgende klanten, want met een of enkele van zulke klanten heb je voor je het weet je handen vol, maar nog geen levensvatbaar bedrijf. Je zal de eerste 'as-a-service'-provider niet zijn die stiekem voor elke nieuwe klant custom development moet doen om de klant binnen te halen . Dat schaalt niet, en is al helemaal problematisch als we het hebben over klanten die enkele honderden euro's per maand opleveren.

Succes

[ Voor 6% gewijzigd door eamelink op 20-01-2022 20:38 ]

[ruby01]

eamelink schreef op donderdag 20 januari 2022 @ 20:37:
.En zorg dat de voorwaarden helder zijn - geen overdracht van het volledige IP, maar alleen een eigen gebruiksrecht, en alleen als jij daadwerkelijk stopt met je onderneming, niet als zij je niet meer aardig vinden.

Bedankt voor de feedback! Waarom zou je geen overdracht van de IP doen, maar alleen gebruiksrecht?

[ybos]

Verschillende pakketten samenvoegen betekend ook tijdswinst en betere effecientie. Ze betalen nu 400 per maand, dat kan dus prima naar 600 per maand als je daar een goed verhaal bij hebt (paar uurtjes interne winst per MAAND doordat er niet meer geswitcht hoeft te worden en de meerprijs is al terugverdiend).
Zij proberen je ook uit, neem een graag of niet instelling aan.
Zij leggen nu eisen op tafel, je kan het ook andersom doen. Ik wil dit en dat (uiteraard reeel) en anders maar niet, blijven zij maar tobben met meerdere pakketjes toch

[retoohs]

Ik zou focus houden op een markt / doelgroep i.p.v. een enkele klant. De eerste klant is belangrijk omdat je feedback nodig hebt over je product en ze zullen ook de eerste bugs van gebruikers gaan vinden. Alleen moet die klant dan wel een vertegenwoordiging zijn van de doelgroep, het moet dus geen maatwerk software gaan worden. Maatwerk software ondersteunen en ontwikkelen is de tijd absoluut niet waard voor een paar honderd euro per maand.

[Furion2000]

Bijberoep, je bent alleen en 2 jaar gedaan over de eerste service. (niet negatief bedoelt, maar om in context te zetten met de rest)

Ik denk dat het juist is om dan het als een service oplossing te zien die ze kunnen afnemen en nooit toezeggingen doen over termijnen van nieuwe features/services. Zelfs niet over het mee mogen bepalen van de features, want wat als het je niet lukt?

Erg knap overigens om dit te bereiken in je eentje en je kunt als je hiermee verder wil misschien uitbreiden en het met meer mensen gaan 'dragen' zodat je wel kunt voldoen aan bepaalde wensen. Ik kan mij alleen ook zomaar indenken dat dit je eerste product is en dat je nog 100 volgende ideeën hebt. Als je dus toezegt naar je eerste klant, kun je die misschien op je buik schrijven. Velen onderschatten onderhoud, helemaal als onder tijdsdruk nieuwe features toegevoegd worden.

Sowieso slim om nooit 'samen te voegen' en zo'n agenda los uit te leveren, laat het goed kunnen 'praten' met je andere service (modules/microservices).

Alles omvattend; vooral als je net begint moet het leuk blijven en als je 'het leed van klanten' aan gaat dan beter het leed delen met iemand!

[ Voor 9% gewijzigd door Furion2000 op 21-01-2022 10:16 ]

[Bolletje]

Voor dit geld - 400 per maand - moet je hier niet aan beginnen is mijn mening voor een enkel bedrijf.

Er zit veel risico - ook wat je misschien nog niet ziet - dat op jou wordt afgewenteld. Je zit hierbij in een positie dat je net begint, dat je geen backup (andere persoon) hebt die het kan opvangen, de complicaties die kunnen opkomen bij het volledig in productie nemen etc.
De potentiele impact van een bug en/of downtime gaat al snel oplopen in dit soort gevallen (uren verlies/niet beschikbaar X uurtarief, inhuur van externe partij, mislopen van een deal, compliance/audit gerelateerd)

Vanuit het bedrijfsperspectief willen ze het contractueel de continuïteit vastleggen. Of dat de beste manier is een tweede. Het oplossen van kritische bugs binnen een bepaalde termijn is dan wel gebruikelijk. Kijk uit met de vergelijking trekken met hun huidige/oude softwarepakket, dat die ook bugs heeft die zijn opgelost. Dit komt ook veel voor, maar je weet niet hoe dat contractueel is vastgelegd, inclusief assessment van de leverancier uit of het kritisch is. Let er op dat je een zakelijke overeenkomst hebt, maar dat het voor jou een significante privé impact kan hebben.

Als je er mee doorgaat, en je komt tot het punt dat ze sowieso de gebruikersrechten willen hebben, zorg dan ervoor dat zijn niet de IPR hebben voor commerciële exploitatie bij derde partijen.
Ook waarborgen dat de data toegankelijk is en/of geëxporteerd kan worden. Als jij er niet bent of de software werkt niet naar behoren, dat ze nog bij de data kunnen.

Je kan het nog beter omschrijven als 'software as is'

[ Voor 11% gewijzigd door Bolletje op 21-01-2022 13:09 ]