Custom software laten bouwen is zinvol als je een werkproces wilt ondersteunen dat met bestaande oplossingen onvoldoende past. Dat kan een volledig platform zijn, maar ook een kleine aanvulling op je huidige administratie. Begin met het probleem en onderzoek de alternatieven. Hieronder lees je hoe je van die afweging naar een afgebakende opdracht en een bruikbare oplevering komt. De verdieping staat in onze gidsen over softwarekosten en code-eigendom.
Wat is custom software en wanneer past het bij je bedrijf?
Custom software is software die voor een specifieke opdracht wordt ontwikkeld. De functies volgen uit de taken die gebruikers moeten uitvoeren. Denk aan een intern aanvraagproces, een klantportaal of een rekenmodule die aansluit op gegevens uit een bestaand pakket. Hoe de juridische rechten worden geregeld, is een afzonderlijke afspraak; het woord maatwerk regelt dat niet vanzelf.
Onderzoek eerst waarom het huidige proces niet goed werkt. Moeten mensen gegevens opnieuw invoeren omdat systemen niet verbonden zijn? Ontbreekt een functie? Of zijn de werkinstructies onduidelijk? Alleen in het tweede geval is een nieuwe toepassing misschien het directe antwoord. Een instelling, koppeling of andere werkafspraak kan ook helpen.
Leg een bestaand pakket hetzelfde voorbeeld voor als een ontwikkelpartner. Laat zien welke taak een medewerker moet afronden, inclusief een afwijkend geval. Vergelijk hoeveel werk buiten het systeem overblijft en of je team met die werkwijze kan leven. Een pakket hoeft niet elk detail van je huidige proces te kopiëren om een passende keuze te zijn.
De vergelijking van AFAS en maatwerk laat zien hoe je configuratie, een aanvullende toepassing en een eigen systeem uit elkaar houdt. Er is geen universeel aantal gebruikers of transacties waarna maatwerk goedkoper wordt.
Hoe beschrijf je een opdracht die een ontwikkelaar kan begroten?
Schrijf op wat iemand moet kunnen afronden, met welke gegevens en onder welke voorwaarden. ‘Een dashboard met klantinformatie’ zegt nog weinig. Een planner die beschikbare medewerkers aan een aanvraag koppelt, moet bijvoorbeeld weten welke beschikbaarheid geldig is en wie een bestaande afspraak mag wijzigen.
Gebruik daarvoor een fictief voorbeeld: een verhuurbedrijf wil een aanvraag ontvangen, beschikbaarheid controleren en een reservering bevestigen. De eerste versie moet ook laten zien wat er gebeurt als het materiaal al gereserveerd is. Alleen de schermen voor een succesvolle aanvraag bouwen zou een groot deel van het dagelijkse werk overslaan.
| Onderdeel van de afbakening | Wat leg je vast? | Vraag bij het verhuurvoorbeeld |
|---|---|---|
| Gebruiker en taak | Wie voert welke handeling uit? | Mag de klant zelf reserveren of alleen een aanvraag doen? |
| Gegevens | Herkomst, betekenis en beheer | Welk systeem bepaalt de beschikbaarheid? |
| Rechten | Toegestane inzage en wijzigingen | Wie mag een bevestigde reservering aanpassen? |
| Uitzonderingen | Afwijzing, fouten en herstel | Wat gebeurt er bij een dubbele aanvraag? |
| Koppelingen | Uitwisseling en verantwoordelijkheden | Wanneer gaat de reservering naar de administratie? |
| Acceptatie | Waarmee toon je de werking aan? | Kunnen medewerkers normale én afwijkende aanvragen afhandelen? |
Spreek ook uit wat buiten de eerste versie valt. Een reservering bevestigen kan het doel zijn; een automatisch berekende bezorgroute is dan een aparte wens. Een duidelijke grens helpt om later bewust te kiezen in plaats van ongemerkt verder te bouwen.
Als een onderdeel nog onzeker is, onderzoek het eerst. Dat kan een korte technische proef zijn voor een koppeling of een gesprek over de gegevens die beschikbaar zijn. Onderzoek moet een vraag beantwoorden die de aanpak kan veranderen. Het aantal pagina’s in het einddocument is daarvoor geen goede maatstaf.
Hoe houd je grip op budget en planning?
Vraag een voorstel waarin de prijs gekoppeld is aan de afgesproken werking. Laat eenmalige kosten voor bouw en ingebruikname apart zetten van hosting, externe diensten en beheer. Tel ook jouw interne inzet mee: iemand moet gegevens controleren, voorbeelden aanleveren en keuzes maken.
Bij TopDevs spreken we vooraf een vaste prijs af voor de afgebakende opdracht. Dat maakt het belangrijk om nieuwe wensen als nieuwe beslissingen te behandelen. Bespreek wat een wijziging doet met de prijs en planning, of welk ander onderdeel daardoor moet wachten. Een vaste prijs betekent niet dat iedere toekomstige wens al is inbegrepen.
Een planning heeft afhankelijkheden. Denk aan toegang tot een extern systeem, een testbestand of akkoord op een werkwijze. Vraag wie die aanlevert en wat er gebeurt als dat niet op tijd lukt. Zo kun je onderscheid maken tussen ontwikkelwerk dat achterloopt en werk dat niet kan starten door een open vraag.
Beoordeel voortgang aan bruikbare stappen, niet alleen aan een percentage ‘klaar’. Een ingevoerd formulier, opgeslagen aanvraag en terugvindbare bevestiging geven je meer inzicht dan losse schermbeelden. Laat tussentijds ook zien hoe een fout wordt hersteld. Dat is onderdeel van de werking, geen detail voor na oplevering.
Hoe verlopen ontwerp, bouw en acceptatie?
Gebruik een ontwerp om beslissingen over het werkproces te nemen. Kan een medewerker zien wat nog ontbreekt? Is duidelijk waarom een aanvraag is afgewezen? Een klikbaar ontwerp kan dat gesprek ondersteunen, maar bewijst nog niet dat berekeningen, rechten of koppelingen werken.
Laat vervolgens een samenhangend stuk van het proces bouwen en toetsen. In het verhuurvoorbeeld gaat het om een aanvraag die van ontvangst tot beoordeling komt. De precieze volgorde hangt af van de risico’s. Als de beschikbaarheidskoppeling onzeker is, kan het verstandig zijn die eerst te onderzoeken voordat alle schermen worden uitgewerkt.
Acceptatie betekent dat je samen controleert of het afgesproken werk bruikbaar is opgeleverd. Leg vóór de eindoplevering vast welke voorbeelden je daarvoor gebruikt en wie namens je bedrijf akkoord kan geven. Maak onderscheid tussen een fout ten opzichte van de afspraak en een nieuwe wens die tijdens het testen ontstaat.
De leverancier hoort ook de technische controles te kunnen toelichten. Het Secure Software Development Framework van NIST beschrijft beveiliging als onderdeel van het ontwikkelproces. Vraag hoe de partij controleert op toegangsrechten, kwetsbare onderdelen en herstel. Een testpercentage of een gekozen framework is op zichzelf geen bewijs dat jouw belangrijkste taken goed werken.
Wat moet je regelen rond gegevens en koppelingen?
Bepaal welk systeem voor welke gegevens leidend is. Als twee toepassingen hetzelfde klantadres kunnen wijzigen, moet duidelijk zijn hoe verschillen worden opgelost. Een koppeling die technisch verbinding maakt, beantwoordt die inhoudelijke vraag nog niet.
Vraag hoe de toepassing omgaat met onderbrekingen. Kan een verwerking opnieuw worden geprobeerd zonder een dubbele factuur of reservering te maken? Ziet iemand welke aanvragen nog wachten? In onze uitleg over software koppelen staat hoe je zulke afspraken concreet maakt.
Maak bij migratie een controleplan. Het gaat niet alleen om het aantal overgezette regels, maar ook om hun betekenis: horen documenten nog bij de juiste klant en komen totalen overeen? Laat medewerkers relevante voorbeelden bekijken. Spreek af wanneer gegevens worden overgezet en hoe wijzigingen in het oude systeem tijdens die overgang worden verwerkt.
Geef testgebruikers alleen toegang tot wat ze voor hun taak nodig hebben. Een geslaagde proef met één beheeraccount zegt weinig over wat een klant of medewerker later kan zien. Bespreek daarnaast welke gegevens in een testomgeving thuishoren en wie die mag gebruiken.
Hoe kies je techniek zonder zelf ontwikkelaar te worden?
Vraag om uitleg in gevolgen voor je bedrijf. Welke onderdelen hangen van een externe dienst af? Wie kan de toepassing onderhouden? Waar zitten grenzen als het gebruik verandert? De naam van een framework geeft op zichzelf geen antwoord op die vragen.
Een ontwikkelaar kan bijvoorbeeld voorstellen bepaalde taken bij een beheerde dienst onder te brengen. Dat kan werk schelen, maar brengt voorwaarden, tarieven en een afhankelijkheid mee. Zelf beheren verplaatst dat werk naar jouw team of beheerpartner. Laat beide routes op dezelfde taken en gewenste ondersteuning vergelijken.
Leg de keuze en aannames vast. Daarmee kan een volgende ontwikkelaar begrijpen waarom iets zo is gebouwd en wanneer die keuze opnieuw moet worden bekeken. Een bekende techniek blijft onderhoud vragen; een specialistisch onderdeel is niet automatisch ongeschikt als de kennis en overdracht goed zijn geregeld.
Voor sommige processen is no-code in plaats van maatwerk een passende route. Vraag ook dan hoe je gegevens exporteert, wie wijzigingen beheert en wat er gebeurt bij een limiet of prijswijziging.
Wat laat de Mastone-case zien?
Voor Mastone bouwden we een platform rond woninggegevens. Het team beheert de portefeuille en gebruikt WWS-berekeningen; investeerders hebben een eigen portaal en online brochures worden opgebouwd uit dezelfde pandgegevens. Berekenen, presenteren en delen komen daarmee samen in één toepassing.
Die case illustreert hoe functies rond een gezamenlijk gegevensmodel kunnen worden gebouwd. Ze bewijst niet dat ieder vastgoedbedrijf een eigen platform nodig heeft of dat standaardsoftware zulke functies niet kan bieden. Onderzoek voor jouw situatie welke onderdelen ontbreken en welke bestaande systemen je wilt behouden.
Vraag een ontwikkelpartner bij een case naar de relevante overeenkomst met jouw opdracht. Is dat een vergelijkbare taak, een vergelijkbare koppeling of een vergelijkbare manier van gegevensbeheer? Eenzelfde branche is een aanknopingspunt, maar geen bewijs dat de eerdere oplossing direct past.
Welke afspraken zijn nodig na de eerste oplevering?
Wijs iemand aan die de toepassing inhoudelijk beheert. Die persoon verzamelt vragen van gebruikers, beslist welke aanpassingen nodig zijn en controleert of de werkwijze nog klopt. Technisch onderhoud en verantwoordelijkheid voor de inhoud zijn verschillende taken, ook als dezelfde partij daarbij helpt.
Spreek bij ondersteuning af wanneer iemand bereikbaar is en hoe incidenten worden ingedeeld. Maak onderscheid tussen de eerste reactie en herstel. Bespreek ook updates, back-ups en wie een terugzetactie uitvoert. Het NCSC adviseert herstelplannen en back-ups te oefenen. Voor jouw toepassing wil je weten of een herstelproef daadwerkelijk lukt en welk werk daarna nog nodig is.
Bij TopDevs is en blijft de maatwerkcode van jou. Daarnaast heb je voor een overdracht documentatie, gegevens en toegang tot de gebruikte diensten nodig. Leg vast welke onderdelen van derden worden gebruikt en welke voorwaarden daarvoor gelden. Een ander beheerteam moet kunnen onderzoeken wat er nodig is om verder te werken.
Waar continuïteit afhankelijk blijft van een leverancier, kun je ook software escrow onderzoeken. Dat vraagt een concrete beoordeling van het risico en de afgesproken regeling. Het vervangt geen werkende herstelprocedure.
Hoe begin je concreet?
Kies één proces dat nu moeite kost en beschrijf de gewenste uitkomst. Verzamel gewone voorbeelden én uitzonderingen, noteer de betrokken systemen en benoem wie namens je team keuzes maakt. Onderzoek vervolgens wat bestaande software al afdekt en welk deel eventueel gebouwd moet worden.
Wil je maatwerk software laten maken, dan bespreken we die afbakening voordat we de opdracht begroten. Je hoeft nog geen technische oplossing te hebben gekozen. Plan een gesprek om je proces en mogelijke eerste versie door te nemen.
