Posts

Kopen, bouwen of allebei?

2026-05-06T11:06:34Z

U wilt een nieuwe markt aanboren, kosten verlagen, of een proces automatiseren. Nieuwe software kan helpen, maar welke software past bij uw situatie?

Er zijn drie hoofdcategorieën: 1) standaardsoftware, 2) software as a service (SaaS), en 3) maatwerksoftware. Dit artikel bespreekt de voor- en nadelen van elk type en helpt u de juiste keuze te maken.

Een goed vertrekpunt is de vraag of het proces dat u wilt oplossen een concurrentievoordeel is of een standaardactiviteit. Als alle bedrijven in uw sector hetzelfde proces op dezelfde manier uitvoeren, is een pakketoplossing waarschijnlijk de juiste keuze. Als het proces juist onderscheidend is voor uw organisatie, is het de moeite waard om te overwegen de software die dat proces aantuurt zelf te bezitten.

Wanneer is standaardsoftware of SaaS de juiste keuze?

Als u een tekstverwerker, e-mailclient, of boekhoudpakket nodig heeft, is het al gedaan. Het aanbod is groot, de producten zijn volwassen, en de prijzen lopen uiteen van gratis tot zeer betaalbaar.

Steeds meer bedrijfssoftware valt in deze categorie, zoals enterprise content management, documentbeheer en CRM-software. Deze tools hebben een duidelijk doel en zijn daar doorgaans goed in.

Qua kosten is standaardsoftware kopen meestal goedkoper dan maatwerksoftware laten bouwen. Dat klopt vaak, maar er zijn nuances die dit beeld kunnen veranderen.

Dit is waar de meeste software-evaluaties eindigen. Het voldoet aan de eisen en het is goedkoper. Gewoon kopen en doorgaan, toch? Even niet zo snel.

Er zijn risico's aan standaardsoftware en SaaS die vaak over het hoofd worden gezien:

Ze bevatten vaak modules die u niet nodig heeft en missen soms functionaliteit die u wel nodig heeft. Extra modules kosten extra. Implementatie en aanpassing aan uw organisatie ook.
Ze werken in functionele silo's en komen vaak van meerdere leveranciers. U moet zeker weten dat integratie met uw bestaande systemen haalbaar is.
Ze geven u mogelijk niet de controle over uw eigen data die u nodig heeft.
Uw gebruikers zijn misschien minder enthousiast over uw keuze dan uzelf.

Laten we deze risico's nader bekijken en bepalen wanneer ze de balans richting maatwerksoftware doen doorslaan.

Precies wat u nodig heeft, niet meer en niet minder

Standaardsoftware kopen is de juiste keuze als het pakket volledig aansluit op uw bedrijfsprocessen. Maar in de praktijk koopt u vaak functionaliteit die u niet gebruikt en mist u functionaliteit die u wel nodig heeft. U zou uw bedrijfsvoering niet moeten aanpassen aan de software die u aanschaft.

De gebruikelijke oplossing is consultants inschakelen om het pakket te implementeren en aan te passen. Als de software grotendeels aansluit op uw eisen, kan dat goed werken. U wilt dan dat consultants de scherpe randjes bijvijlen, niet dat ze het systeem herschrijven. Ze configureren het voor uw organisatie en koppelen het eventueel aan bestaande systemen.

Op een gegeven moment, en dat moet vrij snel na de implementatie zijn, moeten de consultants klaar zijn en vertrekken. Als ze blijven terugkomen voor aanpassingen en integraties, bent u de rechtvaardiging voor kopen in plaats van bouwen al kwijt.

Hier zit het addertje onder het gras dat organisaties vaak verrast: die aanpassingen blijven niet staan. Wanneer de leverancier een nieuwe versie uitbrengt, moet elke aanpassing opnieuw worden beoordeeld, getest, en in veel gevallen herschreven om de upgrade te overleven. Organisaties die zwaar hebben gecustomised, besteden structureel ontwikkelcapaciteit aan het bijhouden van hun eigen afwijkende versie. Op dat moment heeft u geen software meer gekocht. U heeft een startpunt gehuurd en vaste medewerkers aangenomen om de kloof met de standaardversie te onderhouden. Maatwerksoftware kost meer bij de start, maar u betaalt niet permanent voor aanpassingen die u eigenlijk nooit had moeten hoeven maken.

Diepe integratie met uw bestaande systemen

Bij standaardsoftware loopt integratie met uw andere systemen uiteen van eenvoudig tot een volwaardig implementatieproject. Als u bijvoorbeeld CRM-software aanschaft en uw bestaande klantgegevens wilt importeren, zou dat standaard moeten werken. Pijnlijke integraties ontstaan wanneer u de data er niet uitkrijgt, of alleen via een leveranciers-API die per definitie niet is ontworpen om volledige export gemakkelijk te maken.

Als het nieuwe systeem onderdeel is van een groter proces, of als het de centrale databron wordt voor uw organisatie, zijn er veel integratiepunten voor data die in en uit het systeem stromen.

Bij maatwerksoftware zijn die integratiepunten ingebouwd omdat ze onderdeel zijn van de oorspronkelijke eisen. De software integreert diep met uw huidige systemen. Als het goed gedaan is, zijn de nieuwe APIs op een standaard manier gebouwd, zodat toekomstige applicaties er zonder extra werk gebruik van kunnen maken.

Hoe stabiel is die leverancier? Wat is uw exitstrategie?

De waardepropositie van standaardsoftware is de functionaliteit die u krijgt voor de prijs die u betaalt. Maar die waarde verdampt als de leverancier failliet gaat, wordt overgenomen, of de prijs verhoogt op het moment dat u te diep verweven bent om gemakkelijk te vertrekken. En hoe meer u heeft aangepast, hoe lastiger de overstap wordt. Dat is geen toeval.

SaaS-bedrijven zijn hier bijzonder goed in. Lage instapprijzen halen u aan boord. Integratie met uw systemen en jaren aan opgeslagen data verhogen uw overstapkosten. Bij contractverlenging onderhandelt u vanuit een zwakke positie.

Veel SaaS-platforms kennen ook geen standaard-API die concurrerende producten ondersteunen. Dat betekent dat uw exitplan een migratieproject vereist, niet alleen een beslissing. Voordat u een meerjarig contract tekent, moet u precies weten hoe u uw data terugkrijgt en in welk formaat. En test het. Voer de export uit in een niet-productieomgeving en controleer of het resultaat ook daadwerkelijk bruikbaar is. De meeste organisaties doen dit pas als het nodig is, en dat is precies het slechtste moment om te ontdekken dat het plan niet werkt.

Bij maatwerksoftware bezit uw organisatie de code en de data vanaf dag één. Er is geen leverancier om mee te onderhandelen en geen eigen formaat om uit te ontsnappen.

Waar staat uw data?

Bij standaardsoftware staat de data vaak in een eigen database. Zelfs als het een gangbaar formaat is, ondersteunen veel leveranciers geen directe queries op hun dataopslag, of berekenen ze extra voor rapportagetoegang.

Bij SaaS staat uw data in de cloud, op infrastructuur die u niet beheert en in een jurisdictie die u mogelijk niet heeft gekozen. Voor sommige organisaties is dat geen probleem. Voor enterprise-organisaties die opereren onder de AVG, sectorspecifieke regelgeving, of interne beveiligingseisen is het een reëel obstakel. Toezichthouders accepteren "de leverancier regelt dat" niet als antwoord wanneer er iets misgaat. U blijft verantwoordelijk voor uw data, ongeacht waar die zich bevindt.

Maatwerksoftware plaatst de data waar uw organisatie dat vereist, omdat opslaglocatie, toegangscontrole en compliancevereisten onderdeel zijn van de oorspronkelijke specificatie. U kunt een beveiligingsaudit doorstaan omdat u de antwoorden kent.

Draagvlak bij uw gebruikers

Het klassieke IT-inkoopproces is: eisen opstellen, het pakket zoeken dat het beste aansluit, en de technische beoordeling overdragen aan een specialist. Dat werkt prima voor de IT-kant van de afweging.

Het probleem ontstaat wanneer een pakket is gekozen en gebruikers te horen krijgen dat ze de volgende maandag in training zitten en de maandag daarna met het nieuwe systeem moeten werken. Als gebruikers niet betrokken zijn geweest bij de keuze, kunnen ze het systeem afwijzen of de implementatie ondermijnen.

Bij maatwerksoftware en maatwerkintegraties worden gebruikers vroeg betrokken bij de eisen, en het nieuwe systeem wordt gebouwd naar hun specificaties. Zij zijn de belangrijkste stakeholders en bepalen mede de toon voor een succesvolle adoptie in uw organisatie.

Conclusie

Software-inkoopbeslissingen kunnen net zo complex zijn als de problemen die ze moeten oplossen. Beslissers moeten de korte en lange termijn kosten en risico's afwegen van het kopen van standaard- of SaaS-software, het kopen en aanpassen ervan, of het volledig inzetten op maatwerksoftware. Het makkelijkste antwoord is niet altijd het beste antwoord als alle risico's worden meegewogen.

Neem contact op met Volare Software voor meer informatie over maatwerksoftware laten bouwen voor uw organisatie.

Wat is maatwerk software?

2023-04-18T14:20:03Z

Zeker, we verkopen software op maat, maar we zullen vaak de eerste zijn om off-the-shelf software aan te bevelen als dat beter past bij uw budget, bereik of tijdlijn. Off-the-shelf software is handig en kosteneffectief, maar soms voldoet het niet helemaal aan de unieke behoeften van uw bedrijf. In die gevallen kan softwareontwikkeling op maat de betere keuze zijn.

U vraagt zich misschien af: wat IS maatwerksoftware precies? En wat is het verschil met de social media-apps op uw telefoon of de tekstverwerker die u op uw werk gebruikt?

Simpel gezegd is maatwerksoftware een op maat gemaakte oplossing die speciaal is ontworpen voor de behoeften van uw bedrijf. In tegenstelling tot kant-en-klare software, die is ontworpen om te worden gebruikt door een breed scala van personen en organisaties, wordt maatwerksoftware gebouwd met uw specifieke bedrijfsprocessen, eisen en doelstellingen in gedachten.

Software op maat is in veel opzichten vergelijkbaar met het bouwen van een huis op maat. Net zoals een huis op maat wordt ontworpen om te voldoen aan de specifieke behoeften en eisen van de eigenaar, wordt software op maat ontwikkeld om te voldoen aan de unieke behoeften en eisen van een bedrijf. In beide gevallen is het eindresultaat een oplossing die is afgestemd op de exacte specificaties van de eigenaar en zijn individuele stijl en voorkeuren weerspiegelt. Net zoals een huis op maat een team van architecten, bouwers en ontwerpers vereist om de visie van de eigenaar tot leven te brengen, vereist de ontwikkeling van software op maat een team van ontwikkelaars, ontwerpers en projectmanagers om een oplossing te creëren die voldoet aan de specifieke behoeften van de klant. En net zoals een huis op maat het leven van de eigenaar zowel efficiënter als mooier kan maken, kan software op maat een enorme waarde toevoegen aan een bedrijf, de productiviteit verbeteren, processen stroomlijnen en groei stimuleren.

Bekijk het zo: de social media-apps die u op uw telefoon gebruikt, zijn ontworpen voor gebruik door een groot publiek, met functies en functionaliteit die zich richten op een breed scala aan gebruikers. Uw tekstverwerkingssoftware kan meer gespecialiseerde functies hebben, maar is nog steeds ontworpen om te worden gebruikt door een breed scala van industrieën en beroepen.

Aan de andere kant is het voorraadbeheersysteem of de software voor wagenparkbeheer die uw bedrijf gebruikt waarschijnlijk meer gespecialiseerd en afgestemd op de specifieke behoeften van uw bedrijf. Het kan beschikken over functies en functionaliteiten die u niet kunt vinden in kant-en-klare software, en het is ontworpen om uw bedrijf efficiënter en effectiever te laten werken.

Maatwerksoftware kan vele vormen aannemen, van desktopapplicaties tot mobiele apps en webgebaseerde systemen. Maar welke vorm het ook aanneemt, het doel van software op maat is om een oplossing te creëren die perfect bij uw bedrijf past.

Waarom zou u maatwerksoftware verkiezen boven kant-en-klare oplossingen? Het antwoord is eenvoudig: omdat de software is ontworpen op basis van de unieke behoeften van uw bedrijf, kan maatwerksoftware een niveau van functionaliteit, efficiëntie en productiviteit bieden dat niet kan worden geëvenaard door standaardoplossingen. En omdat de software specifiek voor uw bedrijf is ontworpen, kan deze gemakkelijker worden geïntegreerd met uw bestaande systemen en processen, waardoor u minder tijd en moeite hoeft te besteden aan het trainen van uw personeel in nieuwe software.

Bij Volare Software zijn we gespecialiseerd in het ontwikkelen van software op maat. We helpen bedrijven van alle groottes en industrieën om oplossingen te vinden die voldoen aan hun unieke behoeften. Als u moe bent van het gebruik van kant-en-klare software die gewoon niet helemaal past, neem dan vandaag nog contact met ons op voor meer informatie over hoe maatwerk software uw bedrijf naar een hoger niveau kan tillen.

Tien fouten die u moet vermijden bij het kiezen van een bedrijf dat software op maat ontwikkelt

2023-04-02T18:24:49Z

De juiste partner kiezen voor softwareontwikkeling op maat

De juiste softwareontwikkelingspartner kiezen is een van de meest bepalende beslissingen in een softwareproject. De verkeerde keuze kost tijd, geld en soms het project zelf. We bouwen al sinds 2009 enterprise software en hebben deze fouten van beide kanten van de tafel gezien.

Fout 1: Een bedrijf kiezen dat niet kan leveren wat je nodig hebt

Dit klinkt voor de hand liggend, maar veel bedrijven evalueren leveranciers op prijs of beschikbaarheid in plaats van op relevante ervaring. Vraag om voorbeelden van werk dat vergelijkbaar is met jouw project. Niet alleen logo's op een website, maar echte casestudies met resultaten. Een bedrijf dat soortgelijke problemen heeft opgelost, stelt betere vragen en neemt betere beslissingen gedurende het project.

Fout 2: Een bedrijf kiezen dat je na de lancering niet kan ondersteunen

Maatwerk software heeft onderhoud, beveiligingsupdates en verbeteringen nodig over tijd. Een leverancier die na de livegang verdwijnt, laat je achter met een systeem dat niemand meer begrijpt. Vraag hoe ze post-launch ondersteuning regelen voordat je tekent, niet erna.

Fout 3: Referenties en track record niet controleren

Je ontwikkelingspartner heeft toegang tot jouw bedrijfsprocessen, jouw gegevens en soms de informatie van jouw klanten. Controleer referenties. Lees onafhankelijke beoordelingen op Clutch of vergelijkbare platforms. Een bedrijf met niets te verbergen maakt dit gemakkelijk.

Fout 4: Vaste prijscontracten accepteren zonder de risico's te begrijpen

Als prijzen te goed of te precies klinken, vraag dan hoe ze omgaan met scopewijzigingen. Vaste prijscontracten vereisen dat alle vereisten vooraf worden gedefinieerd, wat bij een echt project vrijwel nooit haalbaar is. Wanneer vereisten veranderen, en dat zullen ze, verandert een vast prijscontract jouw leverancier in een tegenstander die discussieert over wat wel en niet in de oorspronkelijke specificatie stond. We hebben nooit op basis van een vaste prijs gewerkt, omdat we het nooit een goed resultaat voor de klant hebben zien opleveren.

Fout 5: De technologiestack niet controleren

Zorg ervoor dat de leverancier bouwt in technologieën die jouw organisatie kan ondersteunen en onderhouden. Als jouw IT-afdeling draait op Microsoft Azure en .NET, creëert een leverancier die een onbekend platform voorstelt een langetermijn onderhoudsprobleem. Vraag specifiek waarmee ze zullen bouwen en waarom.

Fout 6: Het belang van communicatie onderschatten

Je werkt maanden nauw samen met dit team. Slechte communicatie kost meer dan het bespaart. Zoek naar een leverancier die responsief is tijdens het verkoopproces, een duidelijk communicatieplan heeft voor het project en kan aantonen hoe ze klanten op de hoogte houden. Als ze moeilijk te bereiken zijn voor je tekent, zijn ze dat ook erna.

Fout 7: Intellectuele-eigendomsrechten niet verduidelijken

In de meeste Nederlandse en Europese contracten is de opdrachtgever eigenaar van alles wat in het kader van een werk-voor-huur-overeenkomst wordt geproduceerd. Ga daar niet van uit. Leg het schriftelijk vast en bevestig dat de leverancier jouw code, architectuur of bedrijfslogica niet voor andere klanten mag hergebruiken.

Fout 8: De ontwikkelingsmethodologie niet begrijpen

Vraag hoe de leverancier een project beheert van kickoff tot oplevering. Zie je regelmatig werkende software, of is er een lange stille periode gevolgd door een oplevering? Wij laten klanten aan het einde van elke sprint van twee weken werkende software zien, zodat er geen verrassingen zijn. Als een leverancier zijn proces niet duidelijk kan uitleggen, is dat een waarschuwingssignaal.

Fout 9: Geen duidelijk contract tekenen

Een gedetailleerd contract beschermt beide partijen. Het moet scope, betalingsvoorwaarden, wijzigingsbeheer, intellectueel eigendom, aansprakelijkheid, vertrouwelijkheid, geschillenbeslechting en post-launch ondersteuning omvatten. Als een van deze onderwerpen vaag is in het contract dat je bekijkt, vraag dan om verduidelijking voor je tekent. Ons artikel over tien rampen om te vermijden in je volgende contract voor softwareontwikkeling op maat beschrijft in detail waar je op moet letten.

Neem contact met ons op om jouw project te bespreken, of lees meer over onze softwareontwikkeling op maat.

Wat kost softwareontwikkeling op maat?

2018-08-06T06:00:00Z

Overweeg je maatwerk software te laten ontwikkelen?

Wil je een idee van de kosten voordat je een kennismakingsgesprek plant? In dit artikel leggen we uit hoe maatwerk software geprijsd wordt, welke factoren de kosten bepalen en wat je bij verschillende projectgroottes kunt verwachten.

Hoeveel kost softwareontwikkeling op maat?

De kosten van maatwerk software hangen af van teamgrootte, projectduur en complexiteit. Op basis van onze ervaring sinds 2009 hanteren we de volgende indicaties:

Kleine projecten, zoals MVP's, kleine DevOps-trajecten of cloudmigraties, starten vanaf €25.000 voor één fulltime ontwikkelaar gedurende één tot twee maanden.
Middelgrote projecten, zoals webapplicaties met meerdere modules, API-integraties of databaseplatforms, lopen van €50.000 tot €200.000 en duren doorgaans drie tot zes maanden met één of twee ontwikkelaars.
Grote enterprise-projecten met meerdere systemen, complexe integraties of regelgevingsvereisten kunnen meer dan €250.000 kosten en lopen van zes maanden tot meerdere jaren met teams van drie tot vijf ontwikkelaars.

Wat bepaalt de kosten?

De grootste kostenfactoren zijn teamgrootte en projectduur. Daarnaast verhogen de volgende zaken de complexiteit en daarmee de kosten:

Koppelingen met externe systemen. Elke API-verbinding met een extern systeem, of het nu gaat om een betaalverwerker, een ERP of een overheidsgegevensbron, vergroot de scope en het testoppervlak.
Betrokkenheid van bestaande systemen. Migreren of integreren met een bestaand systeem zonder goede documentatie of met inconsistente data kost aanzienlijk meer tijd dan nieuwbouw.
Wet- en regelgeving. Projecten in de zorg, financiële sector, defensie of overheid brengen compliance-overhead mee die invloed heeft op de architectuur, het testen en de documentatie.
Prestaties en schaalbaarheid. Een systeem dat duizenden transacties per minuut moet verwerken, vraagt een andere architectuur dan een systeem dat er tientallen verwerkt.
Complexiteit van de gebruikerservaring. Een consumentgerichte applicatie met een verzorgde interface en mobiele optimalisatie kost meer tijd dan een intern systeem voor getraind personeel.

Wat is er inbegrepen in het maandtarief?

Bij Volare Software omvat ons maandtarief ontwikkeling, codereview, geautomatiseerd testen, deployment en projectcommunicatie. We brengen geen aparte kosten in rekening voor sprintplanning, architectuurbeslissingen of voortgangsrapportages. Je betaalt voor een team en dat team levert werkende software.

Waarom we geen vaste prijscontracten aanbieden

Vaste prijscontracten vereisen dat alle eisen vooraf bekend en gedocumenteerd zijn. In de praktijk veranderen de eisen bij elk project, vaak ingrijpend. Een vast prijscontract plaatst je leverancier in de positie dat hij moet betogen dat jouw nieuwe wens niet in de oorspronkelijke specificaties stond. Dat is slecht voor het project en slecht voor de samenwerking.

Wij werken liever met transparante time-and-materialsovereenkomsten waarbij we het maandelijkse teamtarief vastleggen en een bandbreedte voor de totale doorlooptijd opgeven. Jij bepaalt hoeveel scope je oppakt en kunt het team op elk moment aanpassen of het traject pauzeren.

De belangrijkste software eerst opleveren

We werken met een agile ontwikkelproces waarbij de modules met de hoogste bedrijfswaarde als eerste worden gebouwd. Zo beschik je vroeg in het traject over werkende, inzetbare software, wat het risico vermindert en je in staat stelt het product te valideren bij echte gebruikers voordat het project is afgerond.

Neem vandaag nog contact met ons op voor meer informatie over onze softwareontwikkeling op maat.

De kracht van aangepaste software ontsluiten: is het de investering waard?

2023-08-08T17:49:16Z

Is softwareontwikkeling op maat de investering waard?

Maatwerk software kost meer vooraf dan kant-en-klare alternatieven. Voor veel organisaties is die kostprijs gerechtvaardigd. Voor andere niet. Dit artikel legt uit wanneer softwareontwikkeling op maat een sterk rendement op investering oplevert en wanneer niet.

Wanneer maatwerk software financieel zinvol is

Maatwerk software is de investering waard wanneer een of meer van de volgende voorwaarden van toepassing zijn:

Jouw proces is een concurrentievoordeel. Als de manier waarop je opereert jou onderscheidt van concurrenten, beschermt software die rond dat proces is gebouwd dat voordeel. Standaard software dwingt je te werken zoals jouw leverancier het heeft ontworpen, wat betekent dat je op dezelfde manier werkt als elk ander bedrijf dat dat product gebruikt.
Je betaalt voor functies die je niet gebruikt. Enterprise SaaS-producten rekenen voor mogelijkheden die zijn gebouwd voor de breedst mogelijke markt. Als je 20% van een platform gebruikt en voor 100% betaalt, verbeteren de economische voordelen van maatwerk software aanzienlijk over een horizon van drie tot vijf jaar.
Je hebt een integratieprobleem. Veel organisaties draaien op een combinatie van systemen die niet met elkaar communiceren. Maatwerk software, of een aangepaste API-laag, kan die systemen verbinden en het handmatige werk van het verplaatsen van gegevens ertussen elimineren.
Je bent je huidige systeem ontgroeid. Systemen die zijn gebouwd voor een kleinere versie van jouw bedrijf worden uiteindelijk beperkingen. Maatwerk software kan worden ontworpen om mee te groeien met jouw groei in plaats van elke paar jaar een migratie te forceren.

Wanneer kant-en-klare software de betere keuze is

Maatwerk software is niet altijd het juiste antwoord. Als jouw behoeften goed worden bediend door een bestaand product, is kopen sneller en goedkoper dan bouwen. We zullen je dat rechtstreeks vertellen als dat van toepassing is op jouw situatie. We hebben het eerder gedaan.

Het duidelijkste signaal dat kant-en-klare software de juiste keuze is, is wanneer jouw proces overeenkomt met wat het product doet. Als je boekhoudsoftware nodig hebt, koop dan boekhoudsoftware. De markt voor algemene bedrijfstools is volwassen en concurrerend.

Hoe je over de kosten moet nadenken

De initiële kosten van maatwerk software zijn reëel. Dat geldt ook voor de doorlopende kosten van een systeem dat niet past, van handmatige oplossingen, van gegevens die op drie verschillende plaatsen staan en van een concurrerend proces dat iedereen kan repliceren door hetzelfde product te kopen dat jij gebruikt.

De juiste vergelijking is niet maatwerk software versus de licentiekosten van een kant-en-klaar product. Het is maatwerk software versus de totale kosten van het alternatief, inclusief implementatie, aanpassing, integratiewerk, training en de kosten van de beperkingen die je accepteert.

Wat je van Volare Software kunt verwachten

We werken op trajecten van 3 tot 12 maanden met teams van één tot vijf ontwikkelaars. We geven je een schatting als bandbreedte na een kennismakingsgesprek en we committeren ons aan de maandelijkse teamkosten. Je kunt het team op- of afschalen en je kunt het traject pauzeren als jouw prioriteiten veranderen.

Neem contact met ons op voor een vrijblijvend kennismakingsgesprek, of lees meer over onze softwareontwikkeling op maat.

Voordelen van het inhuren van een bedrijfsgericht softwareadviesbureau op maat

2024-04-28T19:49:26Z

Wat maakt een consultancybureau voor maatwerk software effectief?

Technische vaardigheid is belangrijk bij de ontwikkeling van maatwerk software, maar het is niet genoeg op zichzelf. De bureaus die de meeste waarde leveren, zijn de bureaus die jouw bedrijf net zo goed begrijpen als de codebase. Dit artikel beschrijft waarom bedrijfsinzicht de belangrijkste factor is bij het kiezen van een partner voor softwareontwikkeling op maat.

Software die past bij jouw bedrijf, niet andersom

Standaard software is gebouwd voor de algemene markt. Maatwerk software is gebouwd voor jouw specifieke processen, concurrentievoordelen en integratiebehoeften. Maar zelfs maatwerk software kan tekortschieten als het team dat het bouwt niet de tijd neemt om te begrijpen hoe jouw bedrijf daadwerkelijk werkt.

Een businessgericht consultancybureau begint met de vraag waarom voordat het vraagt hoe. Welk probleem los je op? Hoe ziet succes eruit zes maanden na de lancering? Wie zijn de mensen die dit systeem dagelijks gebruiken? De antwoorden op die vragen bepalen elke architectuurbeslissing, elke functieprioriteit en elke afweging die tijdens het project wordt gemaakt.

Domeinervaring vermindert risico

Een consultancybureau dat ervaring heeft in jouw branche of met vergelijkbare vraagstukken, brengt patroonherkenning mee die een puur technisch team niet heeft. Ze weten welke integraties lastig zijn, welke compliancevereisten invloed hebben op het datamodel en welke functies eenvoudig lijken maar dat niet zijn. Die ervaring verkort de ontdekkingsfase, vermindert het aantal kostbare late wijzigingen en levert software op die werkt zoals jouw bedrijf werkt.

Zakelijke afstemming gedurende het hele project, niet alleen bij de start

Vereisten veranderen bij elk project. Een businessgericht consultancybureau behandelt dat niet als een probleem dat via contracttaal beheerd moet worden. Ze behandelen het als normaal en bouwen daar een proces omheen. Bij Volare Software gebruiken we agile ontwikkeling met korte iteraties, zodat nieuwe informatie en veranderende prioriteiten kunnen worden verwerkt zonder de planning of het budget te verstoren.

Lange termijn denken boven kortetermijnoplevering

Een consultancybureau dat jouw bedrijf begrijpt, denkt na over wat er gebeurt nadat het project is afgerond. Is de software onderhoudbaar? Kan jouw interne team het overnemen? Is de architectuur flexibel genoeg om mee te groeien met jouw bedrijf? Dit zijn geen bijzaken. Het zijn ontwerpbeslissingen die op dag één worden genomen.

Neem contact met ons op om jouw project te bespreken met een consultancybureau dat sinds 2009 business-gedreven enterprise software bouwt.

Hoe we agile software ontwikkelen

2023-08-12T11:43:25Z

Hoe wij agile software ontwikkelen

We volgen een agile softwareontwikkelingsproces dat in meer dan 17 jaar van het opleveren van enterprise-projecten is verfijnd. Dit artikel beschrijft hoe wij werken, van initiële planning tot productie-deployment.

Stories en bugfixes

Het bedrijf, meestal via één productmanager, is primair verantwoordelijk voor het schrijven van nieuwe stories. De inhoud moet voldoende zijn voor de auteur om later te herinneren waar het over ging wanneer om details wordt gevraagd. Zodra een story in de werkcyclus aan de beurt komt, werkt het team met de relevante stakeholders om vragen te stellen, concrete voorbeelden uit te werken en indien nodig een ontwerp te maken. Deze gesprekken verduidelijken de reden voor de functie en vormen een sterke motivatie voor het team.

Prioritering

De productmanager beheert de backlog en stelt prioriteiten. Het team levert schattingen van de inspanning om die beslissingen te ondersteunen, maar de productmanager bepaalt wat er als volgende wordt gebouwd. Dit houdt het team gefocust op bedrijfswaarde in plaats van technische voorkeur.

Iteraties

We werken in sprints van twee weken. Aan het begin van elke sprint bekijkt het team de bovenste items in de backlog, bevestigt de scope en committeert zich aan een set stories voor die iteratie. Aan het einde van elke sprint demonstreren we werkende software aan stakeholders. Er zijn geen verrassingen aan het einde van een lang project, omdat stakeholders elke twee weken voortgang zien.

Werk bijhouden

We gebruiken een Kanban-stijl bord om stories door hun fases te volgen: gereed, in uitvoering, in review, klaar. Stories worden pas als klaar gemarkeerd nadat ze codereview en geautomatiseerd testen hebben doorstaan. Dit houdt de definitie van klaar consistent en voorkomt dat halfafgemaakt werk zich opstapelt.

Codereview

Elke wijziging gaat door peer codereview voordat deze wordt samengevoegd. Codereview gaat niet alleen over het opsporen van bugs, hoewel het dat ook doet. Het gaat om kennisdeling, het handhaven van consistentie in de codebase en het vroegtijdig opsporen van ontwerpproblemen voordat ze kostbaar zijn om op te lossen.

Geautomatiseerd testen

We schrijven geautomatiseerde tests voor bedrijfslogica en integratiepunten. Het doel is niet 100% dekking om de dekking zelf. Het doel is een testset die het team het vertrouwen geeft om snel wijzigingen aan te brengen zonder bestaand gedrag te breken.

Deployment

We gebruiken CI-CD-pipelines zodat elke samenvoeging naar de hoofdbranch een geautomatiseerde build en deployment naar de ontwikkelomgeving activeert. Releases naar productie zijn een bewuste beslissing, geen handmatig proces. Dit vermindert het deploymentrisico en houdt omgevingen consistent.

Wat dit voor jou betekent

Je ziet aan het einde van elke sprint van twee weken werkende software. Je kunt prioriteiten wijzigen tussen sprints. Je weet precies wat er is opgeleverd en wat het heeft gekost. Er zijn geen lange periodes van stilte gevolgd door een grote onthulling.

Neem contact met ons op voor meer informatie over hoe wij werken, of bekijk onze agile DevOps automatiseringen service voor hoe we deze werkwijzen toepassen op DevOps en pipeline-werk.

Tien rampen om te vermijden in uw volgende contract voor softwareontwikkeling op maat

2023-04-02T20:39:06Z

Wat het contract goed moet regelen

Een contract voor softwareontwikkeling op maat is niet zomaar papierwerk. Het bepaalt wie wat bezit, wie waarvoor verantwoordelijk is en wat er gebeurt als het misgaat. We hebben genoeg projecten meegemaakt om te weten dat een slecht opgesteld contract problemen veroorzaakt die geen enkele goede wil kan oplossen. Hier zijn tien dingen die je voor ondertekening goed moet regelen.

1. Geen opzeggingsclausule

Als de leverancier niet levert, kun je dan het contract beëindigen? Zonder een duidelijke opzeggingsclausule heb je daar mogelijk geen juridische grond voor. Zorg dat je contract je de mogelijkheid geeft om de samenwerking te beëindigen als je niet tevreden bent, en wees specifiek over welke omstandigheden dat recht activeren.

2. Onduidelijke scope en geen gedefinieerd proces

Scopedocumenten zijn op zichzelf niet voldoende. De leverancier zal jouw vereisten anders interpreteren dan jij bedoelde, en zonder een gedefinieerd ontwikkelingsproces is er geen mechanisme om dat vroeg te ontdekken. Je contract moet specificeren hoe werk wordt opgesplitst in iteraties, hoe je de voortgang beoordeelt en hoe wijzigingen worden verwerkt. Een proces dat je elke twee weken werkende software laat zien, biedt veel meer bescherming dan een gedetailleerd specificatiedocument.

3. Vage betalingsvoorwaarden

Duidelijke betalingsvoorwaarden beschermen beide partijen. Vage voorwaarden leiden tot geschillen over wanneer betaling verschuldigd is, wat een voltooide mijlpaal inhoudt en wat er gebeurt als een van beide partijen te laat is. Leg dit voor de start van het project concreet vast.

4. Geen intellectuele-eigendomsclausule

Wie is eigenaar van de code? In de meeste Nederlandse en Europese contracten is de opdrachtgever eigenaar van alles wat in het kader van een werk-voor-huur-overeenkomst wordt geproduceerd. Ga daar niet van uit. Leg het schriftelijk vast. Specificeer ook dat de leverancier jouw code niet opnieuw mag gebruiken voor andere klanten.

5. Geen aansprakelijkheidsclausule

Als de leverancier gebrekkige code levert die schade veroorzaakt aan jouw bedrijf of klanten, is hij dan aansprakelijk? Leveranciers willen hun aansprakelijkheid beperken, vaak tot de waarde van het contract. Zorg dat een eventueel aansprakelijkheidsplafond hoog genoeg is om jouw daadwerkelijke risicoBlootstelling te dekken.

6. Geen geheimhoudingsovereenkomst

Je leverancier heeft toegang tot jouw processen, jouw gegevens en soms de informatie van jouw klanten. Een geheimhoudingsovereenkomst moet doorlopen na het einde van het project, doorgaans ten minste een jaar, en moet alle teamleden aan de kant van de leverancier omvatten.

7. Geen geschillenbeslechtingsmechanisme

Als er een geschil ontstaat, is naar de rechter stappen langzaam en duur. Leg in het contract vast hoe geschillen worden opgelost, of via bindende arbitrage, mediation of een ander mechanisme. Dit is veel eenvoudiger overeen te komen voor een geschil dan erna.

8. Geen non-solicitatieclausule

Wat gebeurt er als de leverancier jouw medewerkers wegkaapt, of jij die van hen? Een non-solicitatieclausule legt de regels voor beide partijen vast en vermindert het risico op ongemakkelijke situaties tijdens of na het project.

9. Geen belangenconflictclausule

Werkt de leverancier aan hetzelfde vraagstuk voor een van jouw concurrenten? Een belangenconflictclausule verplicht hen dit te melden en geeft je verhaal als het zonder melding gebeurt.

10. Geen ondersteuningsovereenkomst

Het project is klaar en de software draait in productie. Er duikt een bug op. Wie lost dat op? Leg de verantwoordelijkheden van de leverancier na de livegang vast voor je tekent, niet erna. Bepaal of je een doorlopende ondersteuningsovereenkomst wilt, een garantieperiode of een overdracht aan je interne team, en leg dat vast.

Neem contact met ons op voor meer informatie over hoe we onze softwareontwikkeling op maat trajecten structureren.

Moet je met een offshore team in zee gaan voor je softwareontwikkelingsproject op maat?

2023-04-02T18:25:24Z

Offshore, nearshore of lokaal: wat telt er echt voor jouw project

Kosten zijn meestal de eerste reden waarom bedrijven een offshore ontwikkelteam overwegen. Tarieven in India, Oost-Europa of Zuidoost-Azië zien er op papier aantrekkelijk uit vergeleken met Nederlandse of West-Europese tarieven. Maar de totale kosten van een softwareproject zijn niet alleen het uurtarief. Ze omvatten ook de kosten van miscommunicatie, herwerk, management-overhead en vertraagde oplevering. Dit artikel beschrijft wat je moet afwegen bij deze beslissing.

De werkelijke kosten van offshore ontwikkeling

Offshore teams rekenen doorgaans minder per uur. Dat voordeel neemt af als je de volgende factoren meeneemt:

Tijdzoneverschillen. Een verschil van 5 tot 8 uur tussen een Nederlandse klant en een offshore team betekent dat een vraag die je aan het einde van jouw dag stelt, pas aan het begin van de volgende dag wordt beantwoord. Op een complex project telt die dagelijkse vertraging bij elke uitwisseling snel op.

Communicatie-overhead. Specificaties helder genoeg opschrijven voor een team met een andere culturele en taalkundige context dan die van jou, kost meer tijd en zorgvuldigheid dan de meeste klanten verwachten. Misverstanden die in een gesprek van vijf minuten opgelost zouden worden, kunnen uitlopen op omwegen van een week.

Managementvereisten. Offshore trajecten vereisen doorgaans meer actief projectmanagement aan de kant van de klant. Als je geen toegewijde interne persoon hebt om de relatie te beheren, kunnen de besparingen verdwijnen in de tijd van je eigen team.

Wanneer offshore werkt

Offshore ontwikkeling werkt goed wanneer het werk duidelijk gedefinieerd, herhaalbaar is en weinig heen-en-weer communicatie vereist. Onderhoudstaken, goed gespecificeerde functie-toevoegingen en QA-werk zijn voorbeelden waarbij het tijdzoneverschil en de communicatie-overhead beheersbaar zijn.

Het werkt minder goed voor projecten die ontdekking, evoluerende vereisten of nauwe samenwerking met zakelijke stakeholders vereisen. Die projecten profiteren van een team dat snel kan reageren en zonder wrijving kan communiceren.

Het nearshore alternatief

Een nearshore team werkt in een vergelijkbare of overlappende tijdzone, deelt een vergelijkbare bedrijfscultuur en communiceert zonder taalbarrière. Voor Nederlandse en Europese klanten betekent dat Nederland en omliggende landen.

Volare Software is gevestigd in Hilversum en bedient al sinds 2009 enterprise klanten in Nederland, Europa en de Verenigde Staten. Ons team werkt in CET, wat volledige overlap geeft met de werkdag in West-Europa. We werken in het Nederlands en Engels en passen hetzelfde agile proces toe op elk project, zodat je aan het einde van elke sprint van twee weken werkende software ziet.

We zijn niet de goedkoopste optie. We zijn de optie die het risico vermindert dat het project mislukt of twee keer zo lang duurt als gepland.

Neem contact met ons op om jouw project te bespreken en te kijken of onze aanpak de juiste keuze is, of lees meer over onze softwareontwikkeling op maat.

Het belang van luisteren naar gebruikers tijdens het ontwerpproces

2023-04-02T18:46:50Z

Waarom gebruikersfeedback betere software oplevert

Als we diep in een project zitten, is het makkelijk om vertrouwen te krijgen in onze eigen aannames over wat gebruikers nodig hebben. De producteigenaar heeft een duidelijke visie. De ontwikkelaars begrijpen de technische beperkingen. Maar geen van die perspectieven is hetzelfde als zitten met de mensen die de software dagelijks zullen gebruiken. Gebruikersfeedback tijdens het ontwerpproces is geen luxe. Het is een van de betrouwbaarste manieren om te voorkomen dat je het verkeerde bouwt.

Gebruikers weten dingen die jij niet weet

De mensen die het werk doen dat jouw software ondersteunt, hebben context die niemand in het ontwikkelteam heeft. Ze weten welke delen van het huidige proces pijnlijk zijn, welke oplossingen ze zelf hebben bedacht en welke uitzonderlijke situaties elke week terugkomen. Die kennis verschijnt niet in een eisendocument tenzij iemand ernaar vraagt.

Bij Volare Software behandelen we vroege gesprekken met gebruikers als onderdeel van het ontwerpproces, niet als een goedkeuringsstap aan het einde. Een gebruiker laten werken met een prototype of een vroege werkende iteratie en observeren wat hij doet, vertelt ons in een uur meer dan weken van specificaties schrijven.

Feedback helpt je scope te verkleinen, niet alleen toe te voegen

Een van de nuttigste dingen die gebruikersfeedback doet, is je vertellen wat je moet weglaten. De meeste softwareprojecten beginnen met meer functies dan ze nodig hebben. Gebruikers vertellen ons consistent welke delen van het voorgestelde ontwerp ze daadwerkelijk zouden gebruiken en welke delen goed klinken in een vergadering maar niet weerspiegelen hoe ze werken. Die informatie maakt de software kleiner, sneller te bouwen en gemakkelijker te gebruiken.

Niet alle feedback is bruikbaar, maar alles is nuttig

Sommige gebruikersfeedback is duidelijk en direct. Sommige is tegenstrijdig. Sommige weerspiegelt wat een gebruiker vandaag wil in plaats van wat hij over zes maanden nodig heeft. Een deel van onze taak is feedback in context te interpreteren, af te wegen tegen de productdoelen en aanbevelingen terug te brengen naar de producteigenaar.

We behandelen gebruikersfeedback niet als een stemsysteem waarbij het populairste verzoek wint. We behandelen het als gegevens die ontwerpbeslissingen ondersteunen, genomen door mensen die zowel de behoeften van de gebruiker als de technische beperkingen begrijpen.

Wanneer gebruikers te betrekken

Hoe eerder hoe beter. Feedback op een schets of een eenvoudig prototype is goedkoop om op te handelen. Feedback op een afgewerkte functie is duur. We proberen een vorm van gebruikersinput te krijgen voordat grote ontwerpbeslissingen worden vastgelegd, en opnieuw nadat de eerste werkende iteratie beschikbaar is.

Neem contact met ons op voor meer informatie over onze aanpak van web app ontwikkeling en gebruikersgerichte vormgeving.

Vijf stappen om ervoor te zorgen dat uw webapplicatie veilig is.

2023-04-18T14:27:52Z

Beveiliging bouw je in, je plakt het er niet achteraf op

Beveiliging van web apps is geen eindchecklist voor de lancering. Tegen de tijd dat je pre-launch tests uitvoert, zijn de beslissingen die bepalen hoe veilig je applicatie is al genomen. De architectuur, het datamodel, de gekozen externe services, de manier waarop authenticatie werkt - dat alles lag maanden eerder vast. Dit artikel beschrijft vijf praktijken die we gedurende het hele ontwikkelproces toepassen om web apps veilig te houden.

1. Versleutel al het verkeer

Elk verzoek tussen jouw gebruikers en jouw applicatie moet via HTTPS verlopen. Dit versleutelt gegevens onderweg en voorkomt dat ze kunnen worden gelezen als ze worden onderschept. SSL/TLS-certificaten zijn gratis beschikbaar via de meeste hostingproviders en cloudplatforms. Er is geen goede reden om productieverkeer via HTTP te laten lopen.

2. Versleutel gevoelige gegevens in opslag, en sla ze niet op als dat niet nodig is

Als je applicatie wachtwoorden opslaat, moeten ze worden gehasht met een modern algoritme zoals bcrypt of Argon2, nooit opgeslagen als leesbare tekst of met omkeerbare encryptie. Voor andere gevoelige gegevens zoals betalingsinformatie of identiteitsdocumenten, is de eerste vraag of je ze überhaupt hoeft op te slaan. Gegevens die je niet bewaart, kunnen niet worden gestolen. Als je ze wel moet opslaan, versleutel ze dan op veld- of rijniveau, niet alleen op schijfniveau.

3. Voer beveiligingsscans uit

Geautomatiseerde beveiligingsscanners testen je draaiende applicatie op veelvoorkomende kwetsbaarheden, waaronder injectie-aanvallen, gebrekkige authenticatie en blootgestelde gevoelige gegevens. Het regelmatig uitvoeren hiervan, en zeker voor elke grote release, ontdekt problemen die codereview alleen mist. Veel scanners zijn beschikbaar als onderdeel van een CI-CD-pipeline, zodat de scan automatisch bij elke build plaatsvindt.

4. Voer statische codeanalyse uit

Statische analysetools onderzoeken je broncode zonder deze uit te voeren. Ze identificeren patronen die verband houden met bekende kwetsbaarheidsklassen: SQL-injectie, cross-site scripting, onveilige deserialisatie en andere. Het integreren van een statisch analysetools in je ontwikkelworkflow betekent dat deze controles bij elke commit plaatsvinden in plaats van als eenmalige oefening.

5. Controleer je beveiligingsheaders

HTTP-beveiligingsheaders vertellen browsers hoe ze zich moeten gedragen bij het laden van jouw applicatie. De Content-Security-Policy header beperkt welke resources de browser laadt, wat het aanvalsoppervlak voor cross-site scripting verkleint. De Strict-Transport-Security header dwingt HTTPS af. X-Frame-Options voorkomt dat je pagina's worden ingebed in iframes op andere domeinen. Deze zijn eenvoudig te configureren en maken een meetbaar verschil in de beveiligingspositie van je applicatie.

Beveiliging is een van de gebieden waar de kosten van het oplossen van problemen aanzienlijk toenemen naarmate de tijd verstrijkt. Problemen die tijdens de ontwikkeling worden ontdekt, zijn goedkoop op te lossen. Problemen die in productie worden ontdekt, zijn dat niet.

Neem contact met ons op voor meer informatie over hoe we beveiliging inbouwen in ons web app ontwikkeling proces.