Maatwerksoftware laten bouwen: de complete gids voor ondernemers

"Software laten bouwen is geen techniekvraag. Het is een reeks beslissingen die je zelf moet nemen."

Wie voor het eerst software laat bouwen, krijgt snel te maken met woorden als MVP, sprint, backend en API. Je kunt je daar makkelijk door laten afschrikken en het over laten aan degene die het bouwt. Dat is de fout. Bijna alles wat bepaalt of een project slaagt, is geen technische keuze: wat moet het doen, voor wie, en wat laat je weg? In deze gids loop ik de beslissingen langs in de volgorde waarin je ze neemt.

Kort antwoord: begin met de vraag of het maatwerk moet zijn. Bepaal dan wat in een eerste versie zit (en wat niet), kies een bouwer op basis van afbakening en overdracht in plaats van op prijs, en regel voor de start wie de code en de gegevens bezit en wie het onderhoudt. Bij mij kost een eerste versie tussen 5.000 en 15.000 euro excl. btw tegen een vaste projectprijs en staat die doorgaans in twee tot drie weken.

Inhoudsopgave

1. Beslissing 1: moet het maatwerk zijn?
2. Beslissing 2: wat zit in de eerste versie?
3. Beslissing 3: wat kost het en hoe lang duurt het?
4. Beslissing 4: met wie bouw je?
5. Beslissing 5: van wie is het?
6. Beslissing 6: wie houdt het draaiend?
7. Hoe een goed traject eruitziet
8. Zes fouten die ik vaak zie

Beslissing 1: moet het maatwerk zijn?

Maatwerk is niet automatisch beter. Het is duurder om te maken en je moet het onderhouden. Kies het alleen als er een reden is.

Hoe je tussen bouwen, kopen en no-code kiest, werk ik uit in bouwen, kopen of no-code: een beslismodel. Een goed voorbeeld van die afweging in een andere sector staat in vrijwilligersplatform: bouwen of kopen.

Een test die ik zelf gebruik: kun je in twee zinnen zeggen wat het systeem voor wie moet oplossen? Lukt dat niet, dan is het nog niet tijd om te bouwen, maar om te verduidelijken.

Beslissing 2: wat zit in de eerste versie?

Dit is de belangrijkste beslissing, en het is een weglaat-beslissing. Een eerste versie (vaak MVP genoemd, minimum viable product) is niet een halve versie van alles. Het is een complete versie van het minimale.

Zo bepaal je het:

1. Schrijf op wie het gaat gebruiken en wat die persoon wil bereiken. Eén zin per gebruiker.
2. Kies het ene pad dat het meest oplevert. Bijvoorbeeld: een lid meldt zich aan, ziet een overzicht en kan zich inschrijven voor een activiteit.
3. Zet alles wat daar niet voor nodig is op een lijst voor later. Hoe lastig ook.
4. Leg het vast, met je akkoord. Alles wat niet op die lijst staat, valt buiten de eerste versie.

Hoe je dit uitwerkt, met voorbeelden van wat je kunt schrappen, staat in MVP of volledige app: wat bouw je eerst?. Hoe een drie weken durend traject eruitziet, lees je in zo bouw ik een werkende app in drie weken.

Beslissing 3: wat kost het en hoe lang duurt het?

De prijs van software hangt af van zes dingen. Elke daarvan is een keuze, geen vast gegeven.

Bij mij kost een eerste werkende versie tussen 5.000 en 15.000 euro excl. btw, tegen een vaste projectprijs, en staat die doorgaans binnen twee tot drie weken. Extra wensen die niet in de afgesproken versie zitten, gaan naar een tweede fase met een eigen prijs. Een uitgebreidere uitleg staat in wat kost een app laten bouwen.

Een vaste prijs werkt alleen als de inhoud vast is. Daarom is beslissing 2 zo belangrijk: wie de eerste versie niet scherp afbakent, betaalt later in tijd of geld. Een bureau hanteert vaak een ander model, met een langer traject en een rapport vooraf. Dat past bij grotere organisaties met meerdere afdelingen die moeten instemmen. Voor een MKB-bedrijf of stichting met één beslisser is het vaak te zwaar.

Beslissing 4: met wie bouw je?

De keuze voor een bouwer bepaalt hoe het project loopt. Let op deze dingen, in deze volgorde:

1. Kan hij je eerste versie scherp afbakenen? Een goede bouwer schrapt met je mee, een minder goede zegt overal ja op.
2. Wie bouwt er echt? Praat je met degene die bouwt, of met een accountmanager die doorgeeft?
3. Wat is er te zien tijdens het bouwen? Iets werkends elke week, geen presentatie.
4. Wat gebeurt er bij oplevering? Training, documentatie, overdracht.
5. Wat gebeurt er als hij ophoudt? Kun je er zonder hem mee verder?

Een uitgebreide lijst vragen vind je in een bouwpartner kiezen: twaalf vragen voor je tekent. Mijn eigen werkwijze staat bij de Rapid Solution Studio.

Beslissing 5: van wie is het?

Dit regel je vóór de start, op papier. Drie dingen:

• De code. Wie is eigenaar, of krijg je een gebruiksrecht? Mag een andere partij er later aan doorbouwen?
• De gegevens. Zijn die van jou, en kun je ze exporteren in een bruikbare vorm?
• Onderdelen van derden. Software bestaat voor een groot deel uit bibliotheken en diensten van anderen. Welke licenties zijn dat, en welke abonnementen lopen er op jouw naam?

Als je hierover niets afspreekt, kun je later afhankelijk zijn van de bouwer. De details staan in eigenaar van de code en data bij maatwerksoftware.

Beslissing 6: wie houdt het draaiend?

Software is niet af bij oplevering. Er zijn updates, beveiligingspatches, bugs en nieuwe wensen. Reken op onderhoud en spreek vooraf af:

• wie er reageert als er iets stukgaat, en binnen welke tijd;
• wat het kost, per maand of per keer;
• hoe je een nieuwe wens aanvraagt en prijst;
• wat er gebeurt als de bouwer niet beschikbaar is.

Een volledige uitwerking staat in software na oplevering: onderhoud, documentatie en een uitweg.

Hoe een goed traject eruitziet

Een voorbeeld van een traject met een vaste duur van drie weken:

Hoe AI het bouwen versnelt, en wat dat wel en niet betekent, staat in bouwen met AI: hoe een app in weken kan en waar de grenzen zitten.

Zes fouten die ik vaak zie

1. Beginnen met een lijst functies in plaats van een probleem. Je krijgt dan alles wat je bedacht hebt, en niet wat je nodig hebt.
2. Alles in één keer willen. Een eerste versie die te groot is, wordt niet af.
3. Geen eigenaar aan jouw kant. Iemand moet beslissen, snel, en testen.
4. Eigendom niet regelen. Je merkt het pas als je wilt overstappen.
5. Onderhoud vergeten. Na een jaar is er niemand die weet hoe het werkt.
6. Gegevens niet opschonen voor je overgaat. Slechte data in een nieuw systeem blijft slechte data. Zie CRM voor een stichting: wat je echt nodig hebt voor een voorbeeld.

Wil je weten wat er eerst moet en wat later kan bij een groter bedrijfssysteem? Lees bedrijfssysteem laten bouwen: wat eerst en wat later. En heb je subsidie of fiscaal voordeel in gedachten, kijk dan bij subsidie voor AI en digitalisering in het MKB.

Hulp nodig?

Wil je weten of jouw idee past in een eerste versie van twee tot drie weken? In een gesprek van dertig minuten bakenen we dat samen af. Bekijk de Rapid Solution Studio of plan een gesprek via contact. Wil je eerst zien wat ik eerder bouwde? Kijk bij de showcases.

Gerelateerde artikelen

• Bouwen, kopen of no-code: een beslismodel
• MVP of volledige app: wat bouw je eerst?
• Een bouwpartner kiezen: twaalf vragen voor je tekent
• Software na oplevering: onderhoud, documentatie en een uitweg
• Bouwen met AI: hoe een app in weken kan en waar de grenzen zitten
• Vrijwilligersplatform: bouwen of kopen
• Wat kost een app laten bouwen

Bronnen en verder lezen

• MKB Digitaal, informatie over digitalisering voor het MKB
• Ondernemersinformatie van KVK, voor het kader rond ondernemen
• Rijksoverheid, Ondernemen en innovatie

Dit artikel is geschreven door Vincent van Munster van WeAreImpact. Hij bouwt web-apps en portalen voor ondernemers en organisaties in de Rapid Solution Studio.