De Verborgen Realiteiten van het Bouwen van SaaS-functies

Is uitbesteding de beste keuze?

Dus, je hebt een fantastisch idee voor een tool die je bedrijf kan verbeteren en je leven gemakkelijker maakt. Je bent ervan overtuigd dat het echt iets nieuws is en je bent klaar om te gaan bouwen.

Maar wacht even!

Voordat je begint met het schrijven van code en het samenstellen van een team van ontwikkelaars, zijn er enkele cruciale inzichten die je moet overwegen.In dit interview zit ik samen met de developers van Finqle: 

• Mike van Egmond, onze medeoprichter en CTO

• Farzad Ghanei, onze Technical lead, en

• Jelle van Wijhe, onze Technical Product Owner

Ze hebben het development-pad vaak bewandeld en delen hun ervaringen, uitdagingen en belangrijke lessen omtrent het ontwikkelen van software producten. 

Tegen het einde van dit artikel zal je zien waarom het uitbesteden van de software ontwikkeling waarschijnlijk niet de meest kostenbesparende strategie is voor jouw bedrijf.

Laten we beginnen met Finqle en hoe alles begon

Mike van Egmond, onze medeoprichter en CTO, besefte in 2015 dat bedrijven, zoals Temper, een manier nodig hadden om snellere betalingen aan freelancers te bieden.

Verschillende bedrijven bouwden op dat moment soortgelijke tools – oplossingen die nodig waren om betalingen tussen twee – of meer – partijen te garanderen.

De behoefte aan ons product kwam voort uit risicobeheer.

“Aanvankelijk boden we American Factoring aan, en al gauw wilden we onze dienst verbeteren door realtime uitbetalingen mogelijk te maken – zonder dat klanten werden overweldigd met facturen.

Toen we ons begaven in de uitzendbranche, merkten we dat de aard van de facturatie inherent een aanzienlijk risico met zich meebrengt. Wat gebeurt er als een klant plotseling failliet gaat? En wat als een factuur fouten bevat? Onze klanten kwamen steeds naar ons toe en vroegen om nieuwe functies – zoals KYC-controles en het afhandelen van creditnota’s.

We realiseerden ons dat in onze bedrijfstak het beheren van deze risico’s essentieel was. We hadden een gesloten systeem nodig dat alles dekte – van facturatie, tot betaling, tot risicobeheer.”

Dus, waar begin je met het bouwen van een softwaresysteem?

Mike legt uit:

“Je bepaalt eerst: wat zijn de essentiële zaken die je zelf moet bouwen en wat moet ik uitbesteden? En dan, zodra je deze essentiële zaken hebt, begin je met het schrijven van gebruikersverhalen.

Om prioriteiten te stellen, keken we naar de behoeften van de klant en de risicofactoren. Binnen een maand bouwden we ons Minimum Viable Product (MVP). Dit leidde tot de ontwikkeling van een van onze belangrijkste producten: Pay for Platforms, dat diverse klantbehoeften integreerde.

Elk bedrijf zou zich moeten richten op zijn kernfunctie – als een platform vraag en aanbod bij elkaar brengt, moet het zich niet richten op complexe facturatiestructuren en de daarmee gepaard gaande risico’s. Dat is niet de hoofdactiviteit van een platform, toch?

De regel is: je bouwt over het algemeen niets vanaf nul, tenzij je echt een hele goede reden hebt om dat te doen.

Voor ons was het hetzelfde. Onze kernfocus was – en is: facturatiestromen bouwen, deze facturen kopen en vervolgens de administratieve taken die daarmee gepaard gaan uitvoeren.”

Farzad voegt toe:

“Om dezelfde redenen dat partnerbedrijven onze diensten kunnen gebruiken, maken wij zelf ook veel gebruik van externe diensten van leveranciers. Dus we hoeven onze eigen hardware niet te beheren. Daardoor worden we afgeschermd van alle uitdagingen die daarmee gepaard gaan, dat doet iemand anders. Op deze manier kunnen we gebruikmaken van de nieuwste technologieën, wat een goede zaak is. Het helpt ons om snel vooruit te gaan.

In feite moet je voor elk softwareproject dat je wil uitvoeren, of het nu een SaaS is of een eindgebruikersproduct, hetzelfde proces volgen, het is een generiek proces. En de beslissingen die we tot nu toe hebben genomen, zijn afgestemd op onze tools en ja, ze kloppen – de kerndienst heeft zin, de database heeft zin omdat deze zorgt voor gegevensconsistentie en data-integriteit.”

Over naar het bouwen van een nieuwe functie

Je hebt een tool in gedachten die je bedrijfsactiviteiten zal stroomlijnen. Je bent klaar om je concept tot leven te brengen en je hebt misschien zelfs een globaal idee van hoe het zou moeten werken.

Het lijkt eenvoudig. Je stelt een team van ontwikkelaars samen, stelt je project-tijdlijn in en, voilà! Je tool is klaar om te worden uitgevoerd.

Maar zoals we snel zullen ontdekken, komt er veel meer kijken bij softwareontwikkeling dan je in eerste instantie verwacht. 

Het gaat niet alleen om het schrijven van regels code

Onze CTO Mike weet als geen ander dat softwareontwikkeling niet alleen draait om het schrijven van regels code. Het gaat erom dat je het ingewikkelde web van technologieën, frameworks en afhankelijkheden begrijpt:

“Terwijl je een nieuwe systeemarchitectuur bouwt, zul je altijd meer complexiteit ontdekken dan je in eerste instantie verwacht.”

Versla Excel niet

Denk niet dat je Excel kunt verslaan. Denk eerst na voordat je iets bouwt. Dit is wat Jelle, onze Technische Producteigenaar als geen ander weet:

“Vroeg in mijn carrière werkte ik samen met een enorm slimme ontwikkelaar. Hij had twee masterdiploma’s en een Ph.D. in de natuurkunde – je weet wel, zo’n man. En hij had ook zijn eigen bedrijven. Ik sprak met hem over het starten van een nieuw project. Hij vertelde me: wanneer je van plan bent om een nieuw project om te starten, houd dan eerst in gedachten: probeer nooit iets te bouwen wat een Excel-sheet kan doen.

Hiermee bedoelde hij dat als er al een tool bestaat om de taak uit te voeren – en als je niets meer biedt dan wat een Excel-sheet kan doen – dan heeft het geen zin om het te bouwen. Bij het bouwen van software, is dit vrijwel hetzelfde.”oel dat als het gaat om het bouwen van software, het een beetje hetzelfde is.

De Balans tussen snelheid en stabiliteit.

Ondernemers willen graag snel functies leveren om inkomsten te genereren. Tegelijkertijd is het belangrijk om te blijven testen.

Mike:

“In het begin richtten we ons op het leveren van functies en het verdienen van geld, wat leidde tot beperkte testdekking. Naarmate Finqle groeide, realiseerden we ons het belang van schaalbaarheid en begonnen we met het “refactoren” en het introduceren van tests.

Het is altijd een evenwichtsoefening tussen snelheid en stabiliteit. Het ontwikkelen van software is niet iets eenmaligs; het is een continu proces. Het verwaarlozen van schaalbaarheid, testen en onderhoud kan leiden tot technische schulden op de lange termijn.”

En zoals Farzad grapt:

“Een softwareproject eindigt pas als de ontwikkelaar sterft.”

Het domino-effect: Wat als onderhoud geen prioriteit heeft?

Mike:

“Moderne software vertrouwt vaak op talloze afhankelijkheden, en wanneer je iets nieuws bouwt is er altijd kans op onbedoelde gevolgen.”

Jelle:

“Denk maar aan het bijwerken van documentatie. Toen ik voor het eerst begon, moest ik de documentatie bijwerken. Het leek in eerste instantie op een eenvoudige taak. Maar de externe software die we gebruikten om deze te genereren had intussen verschillende updates ondergaan. Een van de softwarecomponenten was verouderd. Dus, wat een schijnbaar eenvoudige taak leek, veranderde in een dagvullende taak om alles weer aan de praat te krijgen.”

Farzad:

“Verandermanagement neemt ongeveer 20% tot 30% van de inspanning van een ontwikkelaar in beslag en is een erkende kostpost in de industrie. Echter, deze kosten staat niet vast; het is afhankelijk van verschillende factoren. Sommige maanden besteed je er meer tijd aan, terwijl het andere keren minder is.”

Hoewel het kosteneffectief lijkt om de ontwikkeling intern te beheren, kunnen de verborgen kosten snel oplopen. Dit kan invloed hebben op je resultaten en de groei van je bedrijf belemmeren.

Mike:

“Overweeg dit: de tijd die jouw team besteedt aan softwareontwikkeling is tijd die je niet kan besteden aan de kernactiviteiten van jouw bedrijf.”

De waarheid over testen

Testen is een essentieel – maar vaak onderschat – aspect van softwareontwikkeling. Het gaat niet alleen om het schrijven van code; het gaat erom ervoor te zorgen dat de code correct, efficiënt en veilig werkt.

Mike:

“Hadden we meer tests moeten opnemen? Ik denk dat er verschillende fasen zijn waar een bedrijf doorheen gaat.

De eerste fase is gericht op het toevoegen van zoveel mogelijk functies. Bij Finqle waren we vanaf het begin zelfvoorzienend. We deden veel met minder. Weet je, als je nog klein bent heb je twee mensen die aan iets werken – je bouwt, je bouwt, je bouwt.

Het gaat in die fase niet alleen om de complexiteit, maar het betekent ook dat je niet veel testdekking hebt. Uiteindelijk kan wat je bouwt een monster worden – omdat je je vooral richt op functies en het verdienen van geld.

En dan ga je door naar de tweede fase waarin je dingen schaalbaar moet maken. Dit betekent dat je ofwel dingen moet herzien – iets nieuws moet bouwen – of je moet beginnen met testen. Het enige wat je in gedachten moet houden is dat wanneer je iets verandert, je bijna zeker weet dat er iets anders kapot zal gaan.

Onvoorziene complexiteiten kunnen zich op onverwachte manieren voordoen en leiden tot tijds- en kostenbesparingen als onderhoud over het hoofd wordt gezien.”

Jelle vervolgt:

“Dus de ongelukkige realiteit, vind ik, is dat testen gewoon erg arbeidsintensief en tijdrovend is, zowel het schrijven van tests op het softwareniveau, de integratietests, maar ook het daadwerkelijk testen. Dat kost allemaal veel tijd.”

En zoals Mike al zei – als je nog klein bent als bedrijf, en je hebt slechts drie, vier mensen rond een bureau zitten, heeft iedereen min of meer hetzelfde cognitieve idee van de software in hun hoofd. En zodra je bedrijf zich begint uit te breiden, en je team groter wordt en er meer mensen aan werken, dan is dat cognitieve model in ieders hoofd niet meer genoeg om de juiste soort problemen die je zou kunnen introduceren met nieuwe functies, te anticiperen.

En dit kan vrij plotseling gaan spelen. En in dat opzicht zou je, in een ideale wereld, solide moeten testen, zowel op het softwareniveau als op het menselijke niveau. Maar de realiteit is dat het in de meeste gevallen zeer moeilijk te bereiken is omdat je zakelijke belangen en burn-down grafieken je in het gezicht staren.”

Mike:

“Ik heb bedrijven gezien die solide en voortdurende tests uitvoeren, maar failliet gaan, omdat ze geen geld hebben verdiend. Testen is essentieel, maar het is arbeidsintensief en tijdrovend. Het is cruciaal om de juiste balans te vinden voor jouw specifieke situatie.”

Bedrijfsdoelen versus Softwarekwaliteit

Een van de meest uitdagende aspecten van SaaS-ontwikkeling is het in evenwicht brengen van bedrijfsdoelen met softwarekwaliteit. Als ondernemer wil je snel gaan en verkopen, maar je ontwikkelaars hebben tijd nodig om ervoor te zorgen dat de software stabiel, veilig en schaalbaar is. De spanning tussen snelheid en stabiliteit kan ontmoedigend zijn.

Mike:

“Bedrijven willen snel gaan en verkopen, terwijl techniek tijd nodig heeft om kwaliteit te waarborgen. Zowel bedrijven als techniek kunnen gefrustreerd raken.

Herstructureren wordt noodzakelijk wanneer het onderhoud van het huidige systeem de voortgang belemmert. Het uitbesteden van niet-kernfuncties en het kopen van software kan deze last verlichten.

Klanten vragen soms om add-ons of nieuwe functies. Het is belangrijk om hier goed mee om te gaan.

Jelle:

“Het is soms een uitdaging om iets te bouwen en tegelijkertijd aan de behoeften van jouw klanten te voldoen. Hoe algemener je probeert te zijn, hoe gevaarlijker het is om te vertrouwen op wat een enkele klant zegt dat ze willen.

Soms moet je alternatief aanbieden en soms moet je gewoon nee zeggen – omdat het op dat moment geen zin heeft om de middelen te besteden aan die specifieke wens voor jouw bedrijf.

Heel vaak zien we dat er een reden is om nee te zeggen, omdat het geen deel moet uitmaken van de software. En heel vaak, als je dat aan jouw klant kunt uitleggen, komen ze uiteindelijk tot het inzicht dat het waar is.

In mijn rol als producteigenaar vraag ik klanten vaak waarom ze iets nodig hebben. Dit helpt om het onderliggende probleem bloot te leggen en ervoor te zorgen dat we aan hun werkelijke behoeften voldoen.”

Farzad:

“Elke oplossing is een keuze, en we willen klanten helpen geïnformeerde keuzes te maken. Door te focussen op probleemverklaringen in plaats van onmiddellijke oplossingen, kunnen we meerdere opties verkennen, hun voor- en nadelen evalueren en de beste beslissing nemen.”

Het is als een doktersafspraak

Farzad vervolgt:

“Een tastbare vergelijking is een bezoek aan de dokter. Wanneer je een arts bezoekt, moet je je symptomen delen, en de arts zal jouw probleem diagnosticeren en passende medicatie voorschrijven. Softwareontwikkeling is analoog aan de cliënt-patiëntrelatie. Als klant verwacht je niet dat je vertelt welke specifieke pil je wilt; in plaats daarvan moet je jouw symptomen beschrijven, en de developer zal de beste oplossing bepalen om je te helpen.

Prioriteren van functies kan uitdagend zijn, vooral wanneer klanten specifieke ideeën hebben. Het is echter essentieel om te communiceren waarom een bepaalde aanpak niet ideaal is voor hun langetermijndoelen of ons kernbedrijf. Soms realiseren ze zich dat hun oorspronkelijke verzoek mogelijk niet de beste oplossing is.

Als ontwikkelaar wil je snel oplossingen vinden. Maar om op de lange termijn te plannen, moeten we langetermijndoelen boven kortetermijnoplossingen stellen, wat een leerproces kan zijn.”

Jelle:

“De uitspraak ‘Kom naar me toe met oplossingen, niet met problemen’, is niet van toepassing op softwareontwikkeling. Vaak is het beter om te beginnen met probleemverklaringen om de juiste oplossingen te vinden. Problemen vertegenwoordigen echte behoeften, terwijl oplossingen geïdealiseerd kunnen zijn of gebaseerd op onvolledige informatie.”

Mike:

“Goede communicatie is heel belangrijk om klanten te helpen en ervoor te zorgen dat we onze belangrijkste doelen behalen. Het betekent ook de juiste balans vinden tussen wat klanten nodig hebben en wat we als bedrijf willen bereiken.

Uitbesteden is niet alleen een kwestie van geld besparen, maar ook van tijd besparen en problemen voorkomen, zodat je werk succesvol blijft. Het inhuren van extra teams kan wel werken, maar het brengt eigen uitdagingen met zich mee. Het is essentieel om belangrijke kennis intern te behouden en je te richten op je kernactiviteiten in plaats van te veel uit te breiden.

We geven de voorkeur aan het focussen op wat we het beste doen: factureringsstromen bouwen en risico beheren. Het stelt ons in staat om een robuuste en betrouwbare service aan onze klanten te bieden. Daarom besteden we sommige van onze functies ook uit, omdat we ons willen blijven richten op wat belangrijk voor ons is: de beste facturatie-architecten zijn.”

Farzad:

“Als het niet tot jouw kernactiviteiten behoort, wil je het niet zelf bouwen. Want het zijn eigenlijk extra kosten voor een bedrijf als ze software moeten onderhouden dat niet echt hun kernactiviteit is. Het is slechts een bijproduct, een nutsfunctie, een ondersteunend systeem dat ze nodig hebben voor hun kernactiviteit.”

Auto's versus treinen

Om een metafoor te trekken, vergelijkt Farzad deze situatie met de keuze tussen het gebruik van een auto of de trein voor transport.

“Een auto biedt gemak en controle, maar gaat gepaard met verschillende kosten zoals belastingen, brandstof en parkeren. Aan de andere kant wordt een trein, zoals Software as a Service, gedeeld door veel gebruikers, wat de kosten verdeelt. De belangrijkste kosten zijn niet alleen de initiële ontwikkeling, maar ook de doorlopende onderhouds- en operationele kosten, zoals serveronderhoud en hardware.”

Jelle:

“Onzichtbare complexiteit zich kan manifesteren in de kleinste dingen en uiteindelijk tijd en middelen.”

Mike:

“Natuurlijk kun je intern een extra team inhuren, maar bedenk dit: je kunt waarschijnlijk gemakkelijk communiceren met hun API-servers of wat dan ook. Maar je hebt geen controle over de standaardinstelling in die applicatie, de documentatie, enzovoort. Dus misschien, wanneer je het overhandigd krijgt, kom je erachter dat de code echt onleesbaar of slecht is. Geloof me, dan heb je wat werk te doen.

Mensen denken dat software wordt gebouwd en dat het dan klaar is. Het draait ergens. Maar het ding is dat dit deel van de software dat we schrijven – laten we zeggen één pagina – wel 30 pagina’s met afhankelijkheden kan hebben, omdat de frontend is gebouwd op React. React bevat open-source bibliotheken, en in het bouwproces halen we eigenlijk packages op van misschien 20/30 verschillende locaties, zodat we die ene pagina kunnen bouwen.

Hoeveel geld zou u kunnen besparen?

• Uurtarief voor een softwareontwikkelaar: $50/uur

• Uurtarief voor onderhoud: $30/uur

• Initiële ontwikkelingstijd: 200 uur

• Jaarlijkse onderhoudstijd: 60 uur

• SaaS-add-on-kosten: $500/jaar

*Dit is een voorbeeldberekening 

De kracht van specialisatie

Uitbesteden stelt je in staat om te profiteren van de expertise van professionals. Ze begrijpen de complexiteiten van softwarearchitectuur, testen, schaalbaarheid en onderhoud. Ze kunnen door het complexe landschap navigeren, waardoor jij je kunt concentreren op jouw kernbedrijf.

Jelle praat over zijn team:

“Ik denk dat nieuwsgierigheid vitale eigenschappen zijn voor onze technische teams. Het is cruciaal dat teamleden oprecht geïnteresseerd zijn in het begrijpen van delen van de software die niet direct verband houden met hun dagelijkse taken. Mijn team richt zich bijvoorbeeld op onze tool Pay for Platforms, maar we vertrouwen op kernservices die door het team van Farzad worden geleverd. Als mijn teamleden niet nieuwsgierig zouden zijn naar hoe die systemen werken, zou dat leiden tot problemen. Natuurlijk kan niet iedereen alles weten – het helpt om beter te kunnen anticiperen op problemen en potentiële gevolgen van wijzigingen.”

Het pad naar succes

In de wereld van SaaS-functieontwikkeling is het pad naar succes is bezaaid met uitdagingen, complexiteiten en verborgen kosten.

Hoewel het idee om je functie intern te bouwen verleidelijk kan zijn, is de slimme keuze uitbesteding.

Het is een strategische zet die je niet alleen tijd en geld bespaart, maar ook zorgt voor het succes van jouw SaaS-functie.

Mike:

“Plannen voor de lange termijn vereist het in evenwicht brengen van directe behoeften met toekomstige doelstellingen. We voeren vaak discussies om verder te denken dan onze huidige producten en om te visualiseren waar we naartoe willen. Dit houdt in dat we ons einddoel in abstracte termen begrijpen en vervolgens de stappen bepalen om daar te komen.

Naarmate de technologie evolueert, verandert ook het landschap van SaaS-ontwikkeling. Aanbieders van uitbestedingen blijven op de hoogte van opkomende technologieën, zoals AI en machine learning, die jouw SaaS-functie kunnen verbeteren zonder in te boeten aan vertrouwen en beveiliging.”

Jelle:

“Over het algemeen, sprekend vanuit persoonlijke ervaring, denk ik dat mensen veel comfortabeler zijn geworden met het beheren van hun geld met partijen die niet per se alleen hun bank zijn. Je hebt bijvoorbeeld je Apple-portemonnee, je hebt je bankapplicatie, en mensen handelen op eToro. Mensen hebben hierdoor een heel andere relatie met hun geld. Op deze manier merken wij ook dat bedrijven ons vertrouwen om het facturatie gedeelte voor hen te regelen.”

Finqle gaat verder dan wat op het eerste gezicht lijkt.

Farzad:

“Veel kernaspecten zoals gegevensbeveiliging, naleving van branchestandaarden en schaalbaarheid zijn inherent aan ons bedrijf.

Bijvoorbeeld, wij bieden API’s die klanten kunnen integreren in hun systemen, en we bieden ook gebruikersinterfaces waarmee ze direct kunnen verbinden met Finqle. Deze API’s, of ze nu voor de front-end of gebruikersgerichte toepassingen zijn, vertrouwen op hun beurt op de interne API’s die we niet direct aan klanten blootstellen. In plaats daarvan kunnen klanten ermee communiceren via onze producten, zoals Pay for Platforms. In wezen delen al deze producten gemeenschappelijke uitdagingen zoals schaalbaarheid, beveiliging en onderhoudskosten, en klanten die onze API’s gebruiken profiteren indirect van deze zorgen.”

Nieuwe inzichten verzameld?

Voordat je je volledig stort in de wereld van softwareontwikkeling, overweeg de voordelen van uitbesteding.

Dit interview is geleid door Daphne Datema op 14 oktober in Amsterdam