Een softwarebedrijf starten met een eerste klantopdracht wordt beheersbaarder als je onderzoek, bouw en onderhoud apart beschrijft. Kies één probleem, leg het gewenste gedrag van de software vast en spreek af hoe de klant oplevering beoordeelt. Zo kun je beginnen zonder direct een volledig platform of onbeperkte doorontwikkeling te beloven.
Deze gids behandelt software op opdrachtbasis. Een eigen abonnementenproduct vraagt daarnaast een product- en verkoopbegroting. Voor rechtsvorm, kosten en administratie kun je terug naar een eigen ICT-bedrijf starten.
1. Kies een probleem met een herkenbaar einde
“Ons werk automatiseren” is geen afgebakende opdracht. “Goedgekeurde orders eenmaal per dag naar het boekhoudpakket sturen, met een foutenoverzicht” is veel beter te onderzoeken. Je kunt benoemen welke invoer nodig is en welk resultaat zichtbaar moet worden.
Beschrijf ook wie de software gebruikt, wie eigenaar is van het proces en wie wijzigingen goedkeurt. Betrek degene die nu het handwerk doet. Een directeur kan het doel kennen terwijl alleen een medewerker de uitzonderingen kan uitleggen.
Vraag naar bestaande leveranciers, contracten en technische toegang. Ga niet uit van een beschikbare koppeling voordat je de documentatie en toegangsvoorwaarden hebt gecontroleerd.
2. Verkoop eerst onderzoek bij grote onzekerheid
Gebruik dit eigen fasemodel. De resultaten zijn voorbeelden, geen voorgeschreven contractvorm.
| Fase | Wat onderzoek of lever je? | Beslissing aan het einde |
|---|---|---|
| Probleem en gegevens | Werkwijze, uitzonderingen en benodigde informatie | Is het probleem voldoende duidelijk? |
| Technische proef | Koppeling met testgegevens en foutscenario | Is de gekozen aanpak uitvoerbaar? |
| Eerste bruikbare versie | Eén afgebakende werkstroom | Voldoet de levering aan de acceptatiecriteria? |
| Overdracht en beheer | Documentatie, toegang en onderhoudsafspraken | Wie draagt welke verantwoordelijkheid? |
De onderzoeksfase moet zelfstandig waarde opleveren, bijvoorbeeld een uitvoeringsadvies dat de klant ook met een andere ontwikkelaar kan bespreken. Spreek vooraf af of de vervolgfase een aparte opdracht is.
Voor iedere fase benoem je duur, prijsgrondslag en benodigde medewerking. KVK licht toe hoe een overeenkomst en de bijbehorende afspraken werken. Bevestig de gekozen inhoud schriftelijk voordat je begint.
3. Schrijf acceptatiecriteria als zichtbaar gedrag
Maak voor het ordervoorbeeld een korte acceptatielijst. Een geldige testorder verschijnt eenmaal in het doelsysteem. Een ontbrekend veld geeft een bruikbare foutmelding. Een herhaalde verwerking veroorzaakt geen dubbele order. Alleen bevoegde gebruikers kunnen de verwerking starten.
Leg vast welke testgegevens je gebruikt, wie de test uitvoert en hoe afwijkingen worden vastgelegd. Bepaal ook welke browsers, omgevingen of versies worden ondersteund. Een algemeen woord als “gebruiksvriendelijk” is zonder toelichting moeilijk gezamenlijk te beoordelen.
Gebruik tijdens ontwikkeling waar mogelijk synthetische testgegevens. Zijn echte persoonsgegevens nodig, onderzoek dan vooraf de bevoegdheden, beveiliging en verwerkersafspraken.
4. Bereken de prijs met expliciete aannames
Fictief voorbeeld: onderzoek kost 8 uur, bouw 24 uur en testen plus overdracht 8 uur. Bij een intern tarief van € 90 gaat het om 40 × € 90 = € 3.600 exclusief eventuele btw. Dit is een rekenvoorbeeld, geen gangbare prijs voor een softwarekoppeling.
Een onbekende koppeling, ontbrekende gegevens of een trage beoordeling kan extra tijd vragen. Spreek af hoe je daarmee omgaat. Bij een vaste prijs moet duidelijk zijn welke aannames en grenzen bij dat bedrag horen. Bij urenwerk moet de klant kunnen volgen wat je uitvoert en welke budgetafspraak geldt.
Bereken je uitgangspunt met het tariefmodel voor een startend IT-bedrijf. Maak bij een wijzigingsverzoek eerst het effect op prijs, planning en tests zichtbaar en vraag vervolgens akkoord.
5. Bespreek broncode, gebruiksrechten en onderdelen
Noteer wat de klant krijgt: toegang tot een repository, een uitvoerbare toepassing, documentatie of een gebruiksrecht. Behandel overdracht van broncode en rechten als afzonderlijke onderwerpen. Betalen voor ontwikkeltijd beantwoordt niet iedere vraag over intellectueel eigendom.
KVK beschrijft hoe intellectueel eigendom werk kan beschermen. Laat afspraken voor maatwerk, bestaande eigen modules en onderdelen van derden aansluiten op hun daadwerkelijke rechten en licenties.
Bewaar een overzicht van gebruikte bibliotheken, externe diensten en licentievoorwaarden. Spreek af wie abonnementen betaalt en wat er gebeurt wanneer een externe dienst verandert of stopt.
6. Maak onderhoud een bewuste vervolgkeuze
Definieer het onderscheid tussen een fout ten opzichte van de afgesproken oplevering en een nieuwe wens. Leg vast hoe meldingen worden behandeld en welke termijn of vergoeding geldt. Een project afronden en structureel beheer organiseren zijn verschillende werkzaamheden.
Het NCSC publiceert beveiligingsrichtlijnen voor webapplicaties. Gebruik relevante onderdelen om beveiligingswerk expliciet te maken in ontwikkeling, testen en beheer. De aanwezigheid van een checklist bewijst niet dat je toepassing volledig veilig is.
Je volgende stap is een opdrachtkaart invullen met probleem, invoer, uitvoer, drie acceptatiecriteria en uitsluitingen. Gebruik die kaart in een klantgesprek en maak er daarna een voorstel van met de offertegenerator. Voor dat gesprek helpt de aanpak voor eerste ICT-klanten.
Veelgestelde vragen over de eerste softwareopdracht
Moet ik eerst een volledig eigen softwareproduct bouwen?
Nee. Opdrachtwerk kan een manier zijn om betaalde problemen te leren kennen. Gebruik klantcode, gegevens of ideeën niet automatisch voor een eigen product; onderzoek de gemaakte afspraken en rechten.
Kan ik een vast bedrag offreren voordat alles bekend is?
Dat kan alleen met een bewuste omgang met onzekerheid. Een aparte onderzoeksfase kan helpen. Beschrijf de aannames bij een vaste prijs en maak een wijzigingsprocedure begrijpelijk.
Hoort hosting automatisch bij ontwikkeling?
Nee. Benoem wie hosting koopt, accounts beheert, updates uitvoert en incidenten afhandelt. Als jij hosting levert, moeten de prijs, verantwoordelijkheden en beëindiging daarvan duidelijk zijn.
Bronnen en afbakening
Gecontroleerd op 16 oktober 2026. Het fasemodel en de bedragen zijn eigen fictieve voorbeelden voor zakelijke softwareopdrachten.