# Riotbyte > Senior engineers die op CTO-niveau meedenken en als product team bouwen. Geen freelancer, geen B-team. Eén partner van strategie tot productie. Riotbyte B.V. is een software-agency en technisch partner voor Nederlandse scaleups, gevestigd in Rotterdam. We zijn CTO en product team voor founders zonder eigen tech-team, bouwen full-stack web-, mobile- en AI-producten, en vervangen handmatige workflows door software die meegroeit. Contact: info@riotbyte.com (Aert van Nesstraat 45, 10th Floor, 3012 CA Rotterdam, Netherlands). ## Navigation - [Home](https://riotbyte.com/) - [Cases](https://riotbyte.com/cases/): overzicht van klantcases - [Team](https://riotbyte.com/team/): founders en mensen - [Tech](https://riotbyte.com/tech/): technologieën die wij inzetten - [Technisch partner](https://riotbyte.com/technisch-partner/) - [Softwareproducten](https://riotbyte.com/software-producten/) - [Procesoptimalisatie](https://riotbyte.com/proces-optimalisatie/) --- ## Services ### Technisch partner Slug: `technisch-partner`. URL: https://riotbyte.com/technisch-partner/ Voor ambitieuze ondernemers zonder eigen tech-team is Riotbyte de strategische partner die als verlengstuk van je organisatie het product bouwt, schaalt en op CTO-niveau meedenkt over richting en prioriteiten. Geen freelancer, geen standaard bureau. We bouwen niet vóór je, maar mét je. Jij hebt de visie. Wat ontbreekt is de technisch partner om die te realiseren Geen klankbord, geen tegenspraak: Software keuzes, infrastructuur, hires: de beslissingen die je nu neemt bepalen wat je over drie jaar nog kunt veranderen. Intern is er niemand om ze tegen af te wegen, en externe leveranciers bouwen wat je vraagt zonder kritisch mee te denken. Te groot voor freelance, te klein voor agency: Freelancers groeien niet met je mee en wachten op jouw input. Bureaus leveren wat je vraagt, want hoe meer scope, hoe meer omzet. Niemand die zegt dat een feature niet gebouwd hoeft te worden of dat een keuze je later duur komt te staan. Jij bent de bottleneck voor elke beslissing: Elke prioriteit, elk besluit, elke release hangt aan jouw aandacht. Zonder tech-team dat zichzelf stuurt, schaalt jouw tijd niet mee met de ambitie. Vier manieren waarop wij als partner anders zijn dan een leverancier Wij durven te zeggen wat een leverancier niet zegt: Andere leveranciers bouwen zonder nadenken wat er gevraagd wordt. Tegengas geven kost ze omzet, want elke extra feature is extra factureerbare uren. Onze prikkel ligt elders: als de aanpak niet klopt of een keuze je later duur komt te staan, overleggen we dat en kiezen we voor een andere aanpak. We denken mee als CTO, niet alleen als ontwikkelaar: Code is het resultaat, niet het startpunt. We helpen productbeslissingen nemen, prioriteiten stellen en de roadmap sturen. We schuiven aan bij gesprekken met partners, klanten en investeerders, en wegen mee wat daar speelt in de keuzes die we samen maken. Strategie en uitvoering bij één vaste partner: Versnipperde verantwoordelijkheid betekent dat jij continu moet coördineren. Bij ons heb je één vast aanspreekpunt en een team dat alles omvat: strategie, architectuur, code, infrastructuur en onderhoud. Geen accountmanagers, je praat direct met de mensen die er verstand van hebben en met de mensen die het werk uitvoeren. Een team dat vanaf dag één levert: Wij draaien direct mee, met een team dat elkaar al kent en een werkwijze die staat. Geen werving, geen inwerkperiode. Ons team bestaat uit seniors met jarenlange ervaring die kritieke vraagstukken direct herkennen en zelfsturend met passende oplossingen komen. "Wat hij zocht was geen nieuwe leverancier, maar een technisch partner." Toen Michon van der Salm ons benaderde, lag er een MVP en een grote ambitie. Wat ontbrak was iemand die niet alleen bouwt wat gevraagd wordt, maar ook kritisch meedenkt over wat er gebouwd zou moeten worden. Inmiddels kan Michon zich volledig richten op wat OfficeR in de markt wil zijn: hij kent zijn markt, haalt partijen binnen en bepaalt de richting. Alles wat techniek raakt ligt bij ons. We schuiven aan bij gesprekken met data-partners, denken mee over de roadmap, en zorgen dat de keuzes van vandaag passen bij waar OfficeR over een jaar wil staan. Geen tickets afwerken, maar meedenken op ondernemingsniveau. - Wanneer je alleen extra handen zoekt, geen strategische tegenkracht. - Wanneer je technische beslissingen liever volledig zelf neemt. - Wanneer het bij één opdracht moet blijven, zonder langere betrokkenheid. - Wanneer er geen ruimte is om mee te denken over product en richting. --- ### Softwareproducten Slug: `software-producten`. URL: https://riotbyte.com/software-producten/ Wil je een digitaal product bouwen of moderniseren? Dan zijn wij het team dat denkt vanuit het probleem en bouwt voor de lange termijn. Geen wegwerpcode, geen vendor lock-in, geen leverancier die oplevert en verdwijnt. Van idee tot productie, drie momenten waarop het vastloopt Bouwen begint voordat het probleem helder is: Het idee voelt logisch, dus de mouwen gaan omhoog. Geen gesprek met gebruikers, geen scherpe probleemdefinitie, alleen aannames. Drie maanden later staat er een product dat past bij je eigen verhaal, niet bij dat van je gebruiker. Ontwikkeling duurt langer dan verwacht: Het was twee maanden, het werd een halfjaar. Releases kruipen, mijlpalen schuiven, en ondertussen lanceert de concurrent wel. Tegen de tijd dat een feature live staat, is de markt alweer verder. De software schaalt niet meer mee: Legacy frameworks, opgestapelde technical debt, performance-problemen. Wat ooit een dag werk was, kost nu drie weken, en migreren schuift voor zich uit. Hoe we een product bouwen dat over vijf jaar nog staat We beginnen bij het probleem, niet bij de feature list: Bouwen wat gevraagd wordt is makkelijk. Bouwen wat nodig is, dat is de moeite waard. Discovery is geen kick-off-fase maar een doorlopend ritme, zodat je een jaar later niet staat met een product dat de verkeerde vraag beantwoordt. Eén team voor product, design en engineering: We bedenken het product samen met jou en je gebruikers, en hetzelfde team ontwerpt en bouwt het ook. Je schakelt direct met de specialisten, zonder de overhead van project managers en account managers, en zonder kennis die onderweg verloren gaat. Wat we opleveren blijft werken en groeit met je mee: Software die je over vijf jaar nog kunt uitbreiden zonder vanaf nul te beginnen. Beproefde technologieën, tests die regressies vangen, en een architectuur die meegroeit, zodat elke goede ontwikkelaar er morgen op verder kan bouwen. Migratie en modernisering, met een duidelijk pad: Niet alles is nieuwbouw. Bestaande software moderniseren is vaak slimmer dan vanaf nul beginnen. Stap voor stap, scherm voor scherm, terwijl je product gewoon door blijft draaien. We beginnen met begrijpen wat er staat en waarom, voordat we iets vervangen. "Nederland is wereldwijd het eerste land waar dealers realtime data uitwisselen met de fabriek." Volkswagen koos Nederland als eerste land ter wereld waar dealers direct met de fabriek mochten koppelen. De oude route stuurde elke paar minuten de complete historie opnieuw naar de fabriek, alleen vanuit de dealer, zonder dat fabrieksinformatie terugkwam in het DMS waar de monteurs in werken. Wij ontwierpen en bouwden de pilot, samen met de softwareleverancier en zijn ontwikkelaars. De architectuur hangt aan de werkorder: het moment waarop een handeling in het DMS wordt geregistreerd, is het moment waarop de fabriek het ziet, en andersom. Alleen wijzigingen stromen door, in beide richtingen. "Wat begon als een modernisering werd een meerjarig partnerschap." Factua's facturatie- en incassoplatform deed wat het moest doen, maar de codebase eronder was in tien jaar zo dichtgeslibd dat uitbreiden bijna niet meer ging. Eén wijziging kon op drie andere plekken effect hebben. We hebben scherm voor scherm gewerkt: eerst begrijpen wat er stond, dan het nieuwe design inbouwen, en tegelijk de onderlaag ordenen voor de toekomst. Wat begon als een modernisering werd een meerjarig partnerschap waarin features die op het oude systeem onmogelijk waren, nu op de roadmap staan. - Wanneer je een bureau zoekt dat bouwt wat je vraagt zonder te zoeken naar het probleem erachter. - Wanneer je een vastgelegde scope wil afwerken zonder ruimte om onderweg bij te sturen. - Wanneer je een kant-en-klare template of low-code-oplossing zoekt in plaats van maatwerk. - Wanneer prijs het belangrijkste criterium is, niet de waarde op lange termijn. --- ### Procesoptimalisatie Slug: `proces-optimalisatie`. URL: https://riotbyte.com/proces-optimalisatie/ Lopen je processen vast of zitten ze de groei in de weg? Wij digitaliseren niet wat er is, maar denken het proces samen met je opnieuw door. We werken samen met de mensen die het werk dagelijks doen en bouwen in stappen die met de organisatie meegroeien. Drie signalen dat het proces de groei remt Kosten stijgen lineair mee met de groei: Elke nieuwe klant, order of dossier betekent extra handen. Het proces schaalt niet mee, alleen het team groeit, en je marges staan onder druk. Bus-factor: afhankelijk van die ene collega: De kennis zit in het hoofd van één of twee mensen. Gaan ze met vakantie, dan stokt het werk. Stappen ze op, dan ben je maanden bezig om de boel weer op de rit te krijgen. Geen overzicht en data overal verspreid: Spreadsheets, gedeelde mailboxen en losse tools die niet met elkaar praten. Niemand weet precies wat de status is, rapportages spreken elkaar tegen, en informatie komt te laat om er nog op te kunnen sturen. Hoe we je helpen om het proces weer op de rit te krijgen We digitaliseren niet wat er is, maar wat er moet zijn: Een bestaand proces klakkeloos digitaliseren reproduceert oude inefficiëntie in een nieuw jasje. Wij gaan in gesprek met de medewerkers en gebruikers die het werk dagelijks doen, en werken samen met hen uit hoe het proces er écht uit zou moeten zien. Stap voor stap waarde leveren: Geen twee jaar wachten op een nieuw systeem. We splitsen elk traject in kleine milestones die zelfstandig waarde opleveren, zodat het werk vandaag al makkelijker wordt en je gaandeweg kunt bijsturen op basis van wat in de praktijk werkt. Routinewerk in de software, denkwerk bij de mensen: Repetitieve stappen, controles en foutgevoelig handmatig werk handelen we in software af. Medewerkers houden tijd en hoofdruimte over voor het werk waar hun ervaring écht het verschil maakt: klantcontact, oordeelsvorming, uitzonderingen. Eén bron van waarheid, in plaats van vijf spreadsheets: In plaats van losse lijstjes, mailboxen en geheugen brengen we alle informatie samen op één plek. Iedereen kijkt naar dezelfde cijfers, beslissingen rusten op dezelfde feiten, en de status van het werk is in één oogopslag zichtbaar. "Een proces dat afhankelijk was van één persoon, draait nu zelfstandig." De research data repository van TU Delft, waar onderzoekers wereldwijd hun onderzoeksdata delen, kampte met stabiliteitsproblemen die wekelijks om aandacht vroegen, ook 's avonds. Eén ontwikkelaar hield het in de gaten en sprong bij. Het werkte, maar het team wist: zo kan het niet blijven. Nu draait het platform zonder dat er iemand op hoeft te letten. De server herstelt zelf van drukke momenten. Wat ooit avonden per maand aan ongeplande inzet kostte, vraagt nu geen aandacht meer. En onder elke codewijziging staat een geautomatiseerde controle: een vangnet dat eerder ontbrak. - Wanneer de oplossing intern al bedacht is en je iemand zoekt om die uit te voeren. - Wanneer je een leverancier zoekt die jouw bestaande proces één-op-één digitaliseert zonder vragen te stellen. - Wanneer je het hele proces in één keer wil omzetten, zonder ruimte om in stappen te leren en bij te sturen. - Wanneer de mensen op de werkvloer geen ruimte krijgen om mee te denken over hoe het systeem zou moeten werken. --- ### Fractional CTO Slug: `fractional-cto`. URL: https://riotbyte.com/fractional-cto/ Technische beslissingen stapelen op, maar een fulltime CTO aannemen is te vroeg of te duur. Freelancers wachten op input in plaats van mee te denken. Een consultant adviseert maar bouwt niet. Riotbyte vult de rol van fractional CTO in én levert het team dat de strategie uitvoert, direct inzetbaar, zonder fulltime hire. Drie signalen dat je nu een fractional CTO nodig hebt Technische keuzes worden gemaakt zonder strategisch overzicht: Je bouwt, maar niemand bewaakt of de keuzes van nu de groei straks niet in de weg zitten. Technical debt stapelt op, beslissingen over de architectuur worden uitgesteld en niemand durft te zeggen dat iets niet gebouwd hoeft te worden. Je bent de bottleneck voor elke technische beslissing: Elke prioriteit, elke keuze over technologie, elk gesprek met een potentiële partner: het belandt op jouw bord. Zonder technisch leiderschap in je team schaalt jouw tijd niet mee met de ambitie van het bedrijf. Freelancers zijn te licht, een groot bureau te omslachtig: Freelancers groeien niet met je mee en wachten op jouw input. Bureaus leveren wat je vraagt, want hoe meer scope, hoe meer omzet. Niemand die zegt dat een feature niet gebouwd hoeft te worden, of dat een keuze je later duur komt te staan. Waarom een fractional CTO bij Riotbyte anders werkt dan een consultant Je eerste CTO, zonder de hire: Werving van een senior CTO duurt vier tot zes maanden, inwerken nog eens drie. Riotbyte draait direct mee, als parttime CTO en met een team dat al weet hoe het werkt. Geen vacature, geen onboarding, geen maanden wachten voor er iemand bijdraagt. Niet alleen strategie, maar ook uitvoering: De meeste fractional CTO's adviseren en verdwijnen. Riotbyte denkt op CTO-niveau mee én bouwt het product dat uit die strategie volgt. Je hoeft niet te schakelen tussen een adviseur en een development team: technisch leiderschap en uitvoering zitten bij één vaste partner. Directe toegang, geen overhead: Je schakelt direct met seniors die verstand van zaken hebben en met de mensen die het werk uitvoeren. Geen accountmanagers, geen projectmanagers ertussen. Wat je zegt, bereikt meteen degene die het oppakt. We zeggen wat een leverancier niet durft: Elke feature bouwen die gevraagd wordt is makkelijk. Zeggen dat iets niet gebouwd hoeft te worden, of dat een keuze je over twee jaar duur komt te staan, kost een leverancier omzet. Onze belangen liggen anders: we bouwen wat het bedrijf vooruithelpt, niet wat de factuur vergroot. "Wat hij zocht was geen nieuwe leverancier, maar een technisch partner." Toen Michon van der Salm ons benaderde, lag er een MVP en een grote ambitie. Wat ontbrak was iemand die niet alleen bouwt wat gevraagd wordt, maar kritisch meedenkt over wat er gebouwd zou moeten worden. Riotbyte vult voor OfficeR de rol van fractional CTO in: van roadmap tot uitvoering, van investeerdersgesprek tot architectuurkeuze. Inmiddels kan Michon zich volledig richten op wat OfficeR in de markt wil zijn. Alles wat techniek raakt ligt bij ons. Veelgestelde vragen over een fractional CTO inhuren Wat is een fractional CTO? Een fractional CTO, ook wel fractionele CTO of technische co-founder genoemd, is een externe technisch leider die op parttime of projectbasis de CTO-rol invult. Hij of zij denkt mee op strategisch niveau over technologie, product en architectuur, zonder de vaste kosten van een fulltime aanstelling. Voor scaleups die technisch leiderschap nodig hebben maar nog niet klaar zijn voor een fulltime hire, is een fractional CTO vaak de meest praktische keuze. Wat is het verschil tussen een fractional CTO en een interim CTO? Een interim CTO inhuren doe je voor een tijdelijke overbrugging, meestal bij een vertrek of een acute crisis. Een fractional CTO is een structurele oplossing: die groeit mee met het bedrijf en is betrokken zolang de situatie dat vraagt. Het verschil zit in continuïteit. Bij Riotbyte is de betrokkenheid altijd langetermijngericht, geen tijdelijke opvulling. Wanneer heb je een fractional CTO nodig? Wanneer technische beslissingen te lang blijven liggen, wanneer je als founder elke sprint zelf moet aansturen, of wanneer je development team mist wat het nodig heeft om zelfstandig goede keuzes te maken. Dat is het moment. Niet wanneer het al misgaat, maar liever al daarvoor. Wat is CTO as a service? CTO as a service is een andere term voor hetzelfde concept als een fractional CTO: technisch leiderschap op abonnementsbasis, zonder fulltime hire. De term benadrukt de flexibiliteit: je schaalt de betrokkenheid op of af op basis van wat het bedrijf op dat moment nodig heeft. Wat kost een fractional CTO? De kosten hangen af van de omvang van de betrokkenheid, de complexiteit van de technische vraagstukken en of er ook een development team bij zit. Bij Riotbyte is de fractional CTO-rol altijd gekoppeld aan een team dat ook uitvoert. We bespreken dat in een eerste gesprek, zonder verplichtingen. Wanneer wij niet de juiste keuze zijn Liever vooraf helder dan halverwege teleurgesteld. Herken je jezelf in een van deze punten, dan zijn wij waarschijnlijk niet de juiste partij. - Wanneer je een consultant zoekt die adviseert zonder bij de uitvoering betrokken te zijn. - Wanneer je technische beslissingen volledig zelf wil blijven nemen. - Wanneer het bij één opdracht moet blijven, zonder structurele betrokkenheid. - Wanneer je al een sterke CTO in huis hebt en alleen development capaciteit zoekt. --- ### Webapplicaties Slug: `webapplicatie-laten-maken`. URL: https://riotbyte.com/webapplicatie-laten-maken/ De meeste briefings beginnen met een lijst. Functionaliteiten, schermen, integraties. Wat er zelden in staat is waarom. Wat het systeem moet oplossen, voor wie, en wat er misgaat als het niet werkt. Riotbyte begint daar. Niet bij de lijst, maar bij het probleem dat de webapplicatie moet oplossen. Van dat gesprek tot productie, door hetzelfde team. Wat er misgaat als je een webapplicatie laat ontwikkelen Bureaus bouwen wat gevraagd wordt, niet wat nodig is: Een lijst met functionaliteiten is geen probleemomschrijving. Het is een vertaling, en die vertaling is bijna altijd onvolledig. Bureaus die puur op specificaties werken bouwen wat er staat, vragen niet door en sturen niet bij. Na lancering blijkt wat er mist, wat niet klopt voor echte gebruikers, en welke features niemand gebruikt. Tegen die tijd is de leverancier al verder. De lijst groeit, het probleem blijft: Zonder helder beeld van het onderliggende probleem groeit de scope bij elke sprint. Er komen features bij, randgevallen worden toegevoegd en de eerste versie wordt steeds groter. Het gevolg: een webapplicatie laten bouwen duurt langer dan gepland, kost meer dan begroot, en lost bij lancering nog steeds niet op wat het had moeten oplossen. Na lancering weet niemand meer waarom iets zo gebouwd is: De developers die de keuzes gemaakt hebben zijn weg. Wat achterblijft is een systeem vol beslissingen zonder context. Elke aanpassing kost meer tijd dan het zou moeten, omdat niemand meer weet waarom iets zo werkt. Een webapplicatie laten ontwikkelen bij een partij die daarna verdwijnt is geen project, het is een risico. Hoe Riotbyte een webapplicatie maken aanpakt We beginnen bij het probleem, niet bij de oplossing: Voordat we ook maar één scherm ontwerpen of één regel code schrijven, willen we begrijpen wat er eigenlijk opgelost moet worden. Daarom starten we met een kort, betaald discovery traject, waarin we samen het probleem scherp krijgen en de eerste milestone bepalen. Hoe dat werkt en wat het kost, lees je in onze blog. Eerste versie snel live, daarna bouwen op basis van wat je leert: We werken in milestones. De eerste versie van de webapplicatie gaat zo snel mogelijk live, met de functionaliteit die er op dat moment echt toe doet. Niet alles in één keer, geen big bang. Livegang is het moment waarop je voor het eerst echte feedback krijgt van echte gebruikers. Alles wat daarna komt, bouwen we op basis van wat je leert. Eén team van het eerste gesprek tot deployment: Het team dat het probleem begrijpt, bouwt ook de oplossing. Geen overdracht van discovery naar development, geen andere partij voor design of infrastructuur. Geen kennis die verloren gaat tussen disciplines. Eén vast team dat verantwoordelijk is van architectuurkeuze tot release, en dat ook na livegang betrokken blijft. We zeggen wat niet gebouwd hoeft te worden: Elke feature bouwen die gevraagd wordt is makkelijk. Terugduwen kost een leverancier omzet. Wij doen het toch. Als iets niet bijdraagt aan het oplossen van het probleem, zeggen we het. Als een keuze je over twee jaar duur komt te staan, zeggen we het. Dat is niet altijd wat je wil horen, maar het is wel wat je nodig hebt. "Wat hij zocht was geen bureau dat bouwt wat gevraagd wordt, maar een partner die meedenkt over wat er gebouwd zou moeten worden." OfficeR wilde een platform bouwen voor kantoorverhuur: huurders en verhuurders die elkaar direct kunnen vinden. De vraag leek concreet, maar het model achter het platform was complexer dan het op het eerste gezicht leek. Riotbyte startte met een discovery traject om het kernprobleem scherp te krijgen, definieerde de eerste milestone en had de eerste versie binnen twee maanden live. De samenwerking stopte daar niet. Het platform wordt actief doorgebouwd op basis van wat gebruikers doen. Veelgestelde vragen over een webapplicatie laten maken Wat kost een webapplicatie laten maken? De kosten lopen sterk uiteen: van een afgebakende eerste versie tot een platform dat in de tonnen loopt. Een eerlijk bedrag noemen kan pas als we je vraag kennen. Daarom bepalen we de prijs in een kort, betaald discovery traject, met een onderbouwde inschatting in plaats van natte-vinger-werk. Wat dat kost en wat het inhoudt, lees je in onze blog: [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Hoe lang duurt het om een webapplicatie te laten bouwen? We starten met een discovery traject van maximaal twee weken om het probleem en de architectuur scherp te krijgen. De doorlooptijd van de eerste werkende versie bepalen we daar samen met de scope van de eerste milestone, zodat je voor de bouw weet wat je kunt verwachten. Wat is het verschil tussen een webapp laten maken en een website laten maken? Een webapplicatie is interactief: gebruikers loggen in, voeren data in, voeren processen uit en zien uitkomsten. Een website is primair informatief. Als er gebruikers zijn die iets moeten kunnen doen in het systeem, is het een webapplicatie. Kunnen jullie ook een bestaande webapplicatie verbeteren of uitbreiden? Ja. We beginnen dan met een technische review van de bestaande codebase om te begrijpen waar de grenzen zitten. Daarna definiëren we samen de eerste milestone. Bestaande software moderniseren of uitbreiden is een groot deel van het werk dat we doen. Wat als ik al een plan of specificaties heb uitgewerkt? We nemen dat mee als startpunt. We toetsen wel of de aanpak klopt voor het probleem dat je wil oplossen. Soms blijkt een keuze in het plan later duur te worden. Als we dat zien, zeggen we het. Wanneer wij niet de juiste keuze zijn Liever vooraf helder dan halverwege teleurgesteld. Herken je jezelf in een van deze punten, dan zijn wij waarschijnlijk niet de juiste partij. - Wanneer je een fixed price offerte wil voor een volledig uitgewerkte scope. We werken met milestones en eerlijke schattingen, niet met vaste prijzen voor een onbekend vraagstuk. - Wanneer je op zoek bent naar 'even snel een MVP' zonder gesprek over wat er na lancering moet gebeuren. Dat gesprek is bij ons altijd onderdeel van het traject. - Wanneer je al een volledig uitgewerkt plan hebt en alleen uitvoering zoekt. We denken altijd mee over het probleem achter de oplossing. Als je dat niet wil, zijn wij de verkeerde partij. - Wanneer je extra development capaciteit zoekt voor een intern team. We nemen eigenaarschap over het product, we werken niet in bij bestaande teams. --- ### Mobiele apps Slug: `app-laten-maken`. URL: https://riotbyte.com/app-laten-maken/ De meeste bureaus bouwen wat je vraagt. Ze nemen je lijst met features, maken een offerte en gaan aan de slag. Wat ze niet doen is nadenken over of die lijst de juiste is. Of de platformkeuze klopt. Of er na lancering iemand is die meedenkt over wat er beter kan. Riotbyte werkt anders. Wij denken mee over wat er gebouwd moet worden, niet alleen over hoe. Van de eerste vraag tot de App Store, door hetzelfde team. Wat er misgaat als je een app laat ontwikkelen zonder iemand die meedenkt De platformkeuze wordt gemaakt door iemand die niet meedenkt: iOS of Android, native of cross-platform: dit zijn keuzes die bepalen hoeveel je betaalt, hoe lang het duurt en hoe makkelijk je de app later kunt doorontwikkelen. De meeste bureaus maken deze keuze op basis van wat ze zelf bouwen, niet op basis van wat jij nodig hebt. Er wordt niet meegedacht. Er wordt uitgevoerd. Je betaalt twee keer voor hetzelfde: Een native iOS-app en een native Android-app zijn twee aparte projecten. Twee codebases, twee teams, twee keer testen, twee keer uitrollen. Voor veel bedrijven is dat onnodig. Wie eerlijk meedenkt over de aanpak, komt bijna altijd uit op cross-platform. Dat kost een fractie, zonder dat gebruikers het verschil merken. Na lancering denkt niemand meer mee: De app staat live, het bureau is klaar. Wat achterblijft is een codebase die je zelf moet begrijpen, onderhouden en doorontwikkelen. Geen partij die meedenkt over wat de volgende stap is. Geen team dat weet waarom dingen zijn zoals ze zijn. Een app laten maken bij een partij die daarna verdwijnt is geen project afronden. Het is een nieuw probleem introduceren. Hoe Riotbyte een mobiele app laten maken aanpakt Meedenken begint voor de eerste regel code: Voordat we ook maar een scherm ontwerpen, willen we weten voor wie de app is en hoe die gebruikt wordt. Op basis daarvan denken we mee over de platformkeuze. Soms is dat native. Vaker is dat cross-platform. Die vraag beantwoorden we voor je tekent, niet erna. Cross-platform: één codebase, iOS en Android tegelijk: Riotbyte bouwt cross-platform apps met React Native en Flutter. Eén codebase die op beide platforms werkt, met de look and feel van een native app. Voor de meeste zakelijke apps is dit de betere keuze: sneller, goedkoper in onderhoud, en makkelijker door te ontwikkelen. Ja, wij raden cross-platform aan en wij bouwen cross-platform. Dat is geen toeval, maar ook geen eigenbelang: Discord, Tesla en Microsoft Teams draaien op React Native. Het werkt. Wanneer native wél de juiste keuze is: Als een app diepe hardware-integratie nodig heeft, zwaar leunt op platform-specifieke features zoals AR of geavanceerde camerafunctionaliteit, of als performance op de absolute grens moet zitten, dan is native de betere keuze. We zeggen dat ook, ook als het betekent dat het project groter en duurder wordt. Meedenken betekent soms ook zeggen wat je niet wil horen. Eén team dat blijft meedenken na lancering: Hetzelfde team dat de platformkeuze maakt, bouwt de app, regelt de uitrol naar de App Store en Google Play, en blijft meedenken in de doorontwikkeling. Na livegang kijken we samen wat gebruikers doen, wat ze niet doen, en wat de volgende milestone wordt. Geen overdracht, geen kennis die verloren gaat. Van eerste gesprek tot App Store: hoe een app traject bij Riotbyte verloopt Discovery: platformkeuze, architectuur en eerste milestone: We beginnen niet met een offerte maar met vragen. Voor wie is de app? Hoe wordt die gebruikt? Wat moet het systeem oplossen? Op basis van dat gesprek denken we mee over de platformkeuze en de aanpak. Maximaal twee weken, betaald, met een concreet resultaat. Lees meer in [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Bouw: eerste versie zo snel mogelijk live: We werken in milestones. De eerste versie bevat alleen wat er op dat moment echt toe doet. Geen big bang, geen maanden wachten. Snel live, dan leren. Lancering: App Store en Google Play: Wij regelen de uitrol naar beide platforms. App Store Connect, Google Play Console, review-processen: dat is ons werk, niet het jouwe. Doorontwikkeling: blijven meedenken na livegang: Na lancering kijken we wat gebruikers doen en wat ze niet doen. De volgende milestone bouwen we op basis van die data. Livegang is het begin, niet het eindpunt. Native of cross-platform: wat past bij jouw app? Native Wat het is: Een aparte app voor iOS én een aparte app voor Android, elk gebouwd in de programmeertaal van het platform. Wanneer de juiste keuze: Als de app diepe hardware-integratie nodig heeft, zwaar leunt op platform-specifieke features of absolute top performance vereist. Wat het kost: Hoger, omdat je twee codebases bouwt en onderhoudt. Doorlooptijd: Langer, omdat alles twee keer gebouwd en getest wordt. Cross-platform Wat het is: Eén codebase die op zowel iOS als Android werkt, gebouwd met React Native of Flutter. Wanneer de juiste keuze: Voor vrijwel alle zakelijke apps. Gebruikers merken geen verschil met native. Wat het kost: Lager, één codebase betekent minder bouw- en onderhoudswerk. Doorlooptijd: Korter, één keer bouwen is één keer testen. React Native of Flutter: we denken mee over welk framework bij jouw app past React Native: Ontwikkeld door Meta, uitgebracht in 2015. Gebruikt door Discord, Tesla, Microsoft Teams en Shopify. Gebouwd op JavaScript en TypeScript, wat betekent dat veel developers het al kennen. Grote community, veel bestaande componenten, en bewezen schaalbaarheid voor complexe applicaties. De juiste keuze als je app dicht op de native platformen moet zitten en je een groot ecosysteem aan libraries wil hebben. Flutter: Ontwikkeld door Google. Gebruikt een eigen taal, Dart, en rendert de volledige UI zelf in plaats van native componenten te gebruiken. Dat geeft meer controle over de look and feel en zorgt voor volledige visuele consistentie tussen iOS en Android. Snellere rendering voor grafisch intensieve apps. De juiste keuze als visuele consistentie en UI-controle zwaarder wegen dan ecosysteem. Veelgestelde vragen over een app laten maken Wat kost een app laten maken? De kosten van een app laten maken hangen sterk af van de platformkeuze en de complexiteit. Cross-platform is vrijwel altijd goedkoper dan twee native apps, maar een eerlijk bedrag noemen kan pas als we je vraag kennen. Dat bepalen we in een kort, betaald discovery traject. Meer daarover: [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Wat is het verschil tussen een native app en een cross-platform app? Een native app wordt apart gebouwd voor iOS en Android, in de programmeertalen van het platform zelf. Een cross-platform app gebruikt één codebase voor beide platforms. Frameworks zoals React Native en Flutter zorgen ervoor dat de app er op beide platforms native uitziet en aanvoelt, terwijl je de ontwikkel- en onderhoudskosten halveert. Wanneer kies je voor native development? Wanneer de app zwaar leunt op platform-specifieke hardware, zoals geavanceerde AR, intensief camerawerk of bluetooth-integratie op de absolute grens van wat het platform toestaat. En wanneer performance het absolute hoofddoel is. In alle andere gevallen is cross-platform bijna altijd de betere keuze. We denken dat graag met je door. Hoe lang duurt het om een mobiele app te laten ontwikkelen? Een eerste versie van een cross-platform app hebben wij gemiddeld in tien tot twintig weken live in de App Store en Google Play. We starten met een [discovery traject](/blog/wat-is-een-discovery-traject/) van maximaal twee weken om het probleem en de architectuur scherp te krijgen. De doorlooptijd van de eerste werkende versie bepalen we daar samen met de scope van de eerste milestone, zodat je voor de bouw weet wat je kunt verwachten. Kunnen jullie zowel iOS als Android? Ja. We bouwen cross-platform apps die op beide platforms werken vanuit één codebase. Als native iOS of Android toch nodig is, hebben we daar ook ervaring mee. Wat is het verschil tussen een app laten maken en een webapplicatie laten maken? Een mobiele app staat geïnstalleerd op het apparaat, werkt offline en heeft toegang tot hardware zoals de camera, locatie en push-notificaties. Een [webapplicatie](/webapplicatie-laten-maken/) draait in de browser. Voor veel zakelijke use cases is een webapplicatie de betere keuze. We helpen je die afweging maken voor je een traject start. Wanneer wij niet de juiste keuze zijn Liever vooraf helder dan halverwege teleurgesteld. Herken je jezelf in een van deze punten, dan zijn wij waarschijnlijk niet de juiste partij. - Wanneer je een app nodig hebt met zeer specialistische hardware-integratie die native development vereist en je geen cross-platform alternatief overweegt. We denken dat eerlijk met je door, ook als dat betekent dat wij niet de beste keuze zijn. - Wanneer je een fixed price offerte wil voor een volledig uitgewerkte scope. We werken met milestones en eerlijke schattingen, niet met vaste prijzen voor een onbekend vraagstuk. - Wanneer je al een volledig uitgewerkt technisch plan hebt en alleen uitvoering zoekt. We denken altijd mee over de platformkeuze en architectuur. Als je dat niet wil, zijn wij de verkeerde partij. - Wanneer je een consumentenapp wil bouwen zonder zakelijk bedrijfsprobleem als vertrekpunt. Wij richten ons op apps voor bedrijven die een concreet probleem willen oplossen. --- ### Software as a Service Slug: `saas-laten-ontwikkelen`. URL: https://riotbyte.com/saas-laten-ontwikkelen/ Je hebt een idee voor een SaaS product, misschien al validatie vanuit de markt. De verleiding is groot om alles meteen te bouwen: gebruikersbeheer, billing, dashboards, integraties. Maar elke maand die je bouwt zonder betalende klant is een maand die je budget verbrandt. Riotbyte ontwikkelt SaaS platforms als maatwerk platform, met één vast team dat product, design en engineering combineert. We beginnen bij het probleem dat jouw klant heeft, niet bij de featurelijst. Eerste versie snel live, dan itereren op wat echte gebruikers doen. Waarom SaaS ontwikkelen zo vaak begint met de verkeerde stap Je bouwt maandenlang aan features die niemand heeft gevraagd: De meeste SaaS producten starten met een lange lijst: onboarding flow, rolbeheer, rapportages, koppelingen met tools die klanten misschien ooit willen. Na zes maanden is er een platform met twintig features, maar geen tien betalende gebruikers. Het probleem is niet de kwaliteit van de code. Het probleem is dat er gebouwd werd vanuit aannames in plaats van vanuit een concreet klantprobleem. Elke feature die niemand gebruikt is weggegooid geld. De technische basis houdt het niet vol zodra het product aanslaat: Wat werkt voor tien gebruikers valt om bij driehonderd. Single-tenant opgezet terwijl multi-tenant nodig was. Geen scheiding tussen klantdata. Een database die prima draait tot er echt load op komt. Zodra de eerste grotere klant binnenkomt, blijkt dat de architectuur niet meegroeit. Op dat moment heb je twee opties: noodgrepen plegen of grote delen opnieuw bouwen. Beide kosten meer dan het in één keer goed doen. Na lancering ben je overgeleverd aan een partij die het product niet begrijpt: Het bureau dat je SaaS platform bouwde behandelt het als een afgesloten project. Maar een SaaS product is nooit af. Gebruikers willen nieuwe functionaliteit, de markt verandert, concurrenten komen met features die je moet beantwoorden. De ontwikkelaar die je platform bouwde snapt het product niet goed genoeg om die keuzes te maken, en overdragen aan een ander team kost weken inwerken en context die verloren gaat. Waarom founders hun SaaS platform door ons laten bouwen Beginnen bij het probleem van jouw klant, niet bij jouw featurelijst: Je weet wat je wilt bouwen. De vraag is of dat ook is wat je klant nodig heeft. Wij starten elk SaaS traject met een kort, betaald discovery traject van maximaal twee weken. Daarin scherpen we samen de propositie aan: welk probleem los je op, voor wie, en wat moet de eerste versie bevatten om dat te valideren. Je krijgt een concrete scope, een architectuurkeuze en een realistische inschatting van tijd en kosten. Die deliverable is van jou, ook als je daarna een andere kant op besluit. Snel naar de eerste betalende klant, dan bouwen op basis van wat je leert: We bouwen niet het volledige platform in één keer. We bouwen de versie die genoeg doet om je eerste klanten te bedienen, en die gaat doorgaans in tien tot twintig weken live. Geen big bang na een jaar, maar een werkend product waar echte gebruikers mee aan de slag gaan. Wat ze daarmee doen bepaalt de volgende milestone, niet een lijst met aannames die zes maanden geleden op papier logisch leek. Architectuur die schaalt zonder dat je opnieuw moet bouwen: Een SaaS platform stelt eisen die maatwerksoftware voor intern gebruik niet stelt. Multi-tenancy, data-isolatie per klant, subscription management, veilige API's voor integraties. Wij maken die keuzes in de discovery, niet achteraf wanneer de eerste grote klant zich meldt. Dat betekent ook: eigenaarschap over je eigen data en code, geen vendor lock-in. Je kunt op elk moment met een ander team verder. Eén vast team dat het product meebouwt, niet alleen de code: SaaS development vraagt om een team dat het product begrijpt, niet alleen de technische specificaties uitvoert. Bij Riotbyte zit product, design en engineering in één team. Dezelfde mensen die in de discovery het probleem leerden kennen, bouwen het platform, regelen de deployment en denken mee over wat de volgende versie moet worden. Geen overdracht, geen kennisverloop, geen accountmanager als tussenlaag. Zo verloopt een SaaS traject bij Riotbyte Discovery: propositie en architectuur scherp: Maximaal twee weken. We brengen het klantprobleem, de propositie en de technische architectuur in kaart. Keuzes als multi-tenancy, data-isolatie en de juiste stack worden hier gemaakt. Resultaat: een concreet plan met scope, aanpak en inschatting. Lees meer in [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Eerste versie live: tien tot twintig weken: We bouwen naar een werkend SaaS product dat live gaat en door echte klanten gebruikt kan worden. Geen maanden wachten op de perfecte versie, maar snel valideren of het product doet wat het moet doen. Doorontwikkelen per milestone: Op basis van gebruikersdata en feedback bepalen we samen wat de volgende stap is. Nieuwe features, betere onboarding, extra integraties. Elke milestone heeft een eigen scope en doorlooptijd die we vooraf bepalen. Schalen en onderhoud: Het platform blijft performant, veilig en onderhoudbaar naarmate het gebruikersbestand groeit. Geen technical debt die zich opstapelt, geen verrassingen als de load toeneemt. "Voordat er een regel code werd geschreven, lag er een gevalideerd concept en een heldere eerste versie." SkillyBee had een idee voor een platform waar creators hun vaardigheden laten zien en gecertificeerde coaches daar gestructureerde feedback op geven. Meerdere gebruikersgroepen die elkaar moeten versterken: precies het type product waar bouwen vanuit aannames het duurst uitpakt. In een discovery traject hebben we uitgewerkt wie die gebruikersgroepen zijn, wat ze van elkaar nodig hebben en welke onderdelen echt bij de eerste versie horen. De uitkomst was een klikbaar prototype met onderbouwing, waarmee SkillyBee het concept kon toetsen bij gebruikers, partners en investeerders. Veelgestelde vragen over SaaS laten ontwikkelen Wat kost het om een SaaS platform te laten ontwikkelen? De kosten hangen af van de complexiteit van het platform, de architectuurkeuzes en de scope van de eerste versie. Een eerlijk bedrag noemen kan pas als we het probleem kennen. Daarom bepalen we de prijs in een kort, betaald discovery traject met een onderbouwde inschatting in plaats van een offerte op basis van aannames. Wat dat kost en inhoudt, lees je hier: [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Hoe lang duurt het om een SaaS product te bouwen? We starten met een discovery van maximaal twee weken om het klantprobleem en de architectuur scherp te krijgen. De eerste werkende versie gaat doorgaans in tien tot twintig weken live, afhankelijk van de complexiteit. Doorontwikkeling gaat daarna per milestone verder. Wat is het verschil tussen een SaaS platform en een webapplicatie? Een webapplicatie lost een probleem op voor één organisatie of gebruikersgroep. Een SaaS platform is een product dat je aan meerdere klanten aanbiedt, elk met een eigen account, data en configuratie. Dat stelt andere eisen aan de architectuur: multi-tenancy, data-isolatie, billing en schaalbaarheid. Meer over webapplicaties lees je op onze pagina over een [webapplicatie laten maken](/webapplicatie-laten-maken/). Kan elke klant zijn eigen omgeving krijgen binnen mijn SaaS? Ja, dat heet multi-tenancy. Elke klant werkt in een eigen, afgeschermde omgeving binnen hetzelfde platform. Hun data is gescheiden van die van andere klanten, maar je beheert alles centraal. Die architectuurkeuze maken we in de discovery, omdat de manier waarop je multi-tenancy inricht direct bepaalt hoe het platform later schaalt en wat het kost. Van wie is de code als ik een SaaS laat ontwikkelen? De code is van jou, net als de documentatie en de infrastructuur. Er is geen vendor lock-in: je kunt op elk moment met een ander team verder. Wij bouwen zodat je ons niet nodig hebt om te blijven draaien. Wat gebeurt er na livegang van mijn SaaS product? Livegang is het startpunt, niet het einde. Een SaaS product evolueert continu: nieuwe features, betere onboarding, extra integraties op basis van wat klanten vragen en wat de data laat zien. We bouwen per milestone verder en houden het platform onderhoudbaar en veilig. Meer over onze aanpak lees je op onze pagina over [softwareproducten](/software-producten/). Eerlijk: wanneer wij niet de juiste keuze zijn Liever vooraf helder dan halverwege teleurgesteld. Herken je jezelf in een van deze punten, dan zijn wij waarschijnlijk niet de juiste partij. - Wanneer je een idee wilt valideren zonder iets te bouwen. Dan is een prototype in Figma of een no-code tool een betere eerste stap. Zodra je weet dat het probleem klopt en de markt er is, praat dan met ons. - Wanneer je een white-label oplossing zoekt die je onder eigen naam kunt doorverkopen. Wij bouwen maatwerk platforms, geen reseller producten. - Wanneer je een fixed price wilt voor het volledige product zonder ruimte om bij te sturen. We werken per milestone met eerlijke schattingen, niet met vaste prijzen voor een scope die nog moet uitkristalliseren. - Wanneer je al een volledig uitgewerkt technisch plan hebt en alleen developers zoekt die het uitvoeren. We denken altijd mee over product en architectuur. Als je dat niet wilt, zijn wij de verkeerde partij. --- ### Maatwerk software Slug: `maatwerk-software`. URL: https://riotbyte.com/maatwerk-software/ Je wilt maatwerk software laten maken omdat een standaardpakket niet meer past bij hoe je bedrijf echt werkt. Het risico is bekend: het loopt uit in tijd en geld, of je krijgt precies wat je vroeg in plaats van wat je nodig had. Wij bouwen maatwerksoftware met één vast team en in vaste milestones, zodat je vooraf weet waar je aan begint en snel een eerste werkende versie live hebt. Product, design en engineering in één team, dezelfde mensen die je probleem snappen. Waarom maatwerk software laten maken zo vaak misgaat Maatwerk loopt berucht uit in tijd en budget: De meeste horrorverhalen over maatwerk software gaan over hetzelfde: een traject dat maanden uitloopt en een rekening die blijft oplopen. De oorzaak is bijna altijd dat er te vroeg te veel is toegezegd zonder dat iemand de scope echt scherp had. Zonder een duidelijk beginpunt en vaste milestones weet je nooit of je halverwege zit of pas net begonnen bent. Je krijgt wat je vroeg, niet wat je nodig had: Bureaus bouwen graag netjes de feature list af die je aanleverde. Het gevolg is software die op papier compleet is, maar waarvan de helft ongebruikt blijft terwijl de functie die het werk echt lichter maakt ontbreekt. Zonder een partij die doorvraagt op het onderliggende probleem, betaal je vol voor een oplossing die net naast de kern zit. Je mist het team om aan over te dragen: Vaak zit de kennis bij één externe developer of verspreid over meerdere leveranciers, en bij elke overdracht gaat er iets verloren. Een eigen team opbouwen duurt maanden. Zo blijft de founder de bottleneck voor elke technische beslissing, en staat of valt je software met de beschikbaarheid van één persoon. Waarom CEO's en CTO's hun maatwerk software door ons laten maken Geen open einde, maar vaste milestones: Maatwerk staat bekend om projecten die uitlopen in tijd en budget. Wij beginnen daarom met een discovery van maximaal twee weken die scope, aanpak en kosten scherp maakt voordat er groot budget vastligt. Daarna bouwen we per milestone, met een doorlooptijd die we vooraf samen bepalen. Je weet waar je aan begint en houdt op elk moment de regie over wat er wanneer gebouwd wordt. Geen feature list, maar een bedrijfsdoel: We bouwen niet klakkeloos wat er gevraagd is, maar wat het probleem oplost. Voordat er code wordt geschreven, koppelen we elke milestone aan een concrete uitkomst: minder handwerk, kortere doorlooptijd, minder fouten. Zo bouw je geen dure functionaliteit langs de kern heen, maar software die aantoonbaar bijdraagt aan een doel waar jij als CEO of CTO op wordt afgerekend. Niet meerdere leveranciers, maar één vast team: Bij software maatwerk gaat de meeste tijd verloren in overdrachten: van strateeg naar designer naar developer, en bij elke schakel verdwijnt kennis. Bij ons zit product, design en engineering in één team. De mensen die je software bouwen zijn dezelfde mensen die het probleem snappen, en je praat direct met hen. Eén partij die verantwoordelijk is, geen accountmanager als tussenlaag. Geen ja-knikker, maar een partner die tegenspreekt: Wij zeggen wat een leverancier vaak niet durft. Als je aanpak niet klopt of een feature geen waarde toevoegt, hoor je dat van ons voordat je er tijd en geld in steekt. Een CTO zoekt geen uitvoerder die alles beaamt, maar een sparringpartner op niveau die meedenkt over product en techniek. Die rol nemen we, ook als het ongemakkelijk is. "Een codebase waarin één wijziging op drie andere plekken effect had. Nu kan Factua weer vooruit met het product." Factua verzorgt de facturatie en incasso voor MKB'ers, ZZP'ers en verenigingen. Het platform deed functioneel wat het moest doen, maar de codebase was in ruim tien jaar zo dichtgeslibd dat uitbreiden bijna niet meer ging. Wij vernieuwden de schermen en ordenden de codebase eronder, in milestones die naast de dagelijkse dienstverlening door konden lopen. Geen big bang herbouw, maar stap voor stap ruimte terugwinnen om weer nieuwe functionaliteit te kunnen bouwen. Zo verloopt een maatwerk software traject Discovery: scope en aanpak scherp: Maximaal twee weken. We brengen het proces, de gebruikers en de bottlenecks in kaart en vertalen dat naar een concreet plan met scope en aanpak. Lees meer in [Wat is een discovery traject?](/blog/wat-is-een-discovery-traject/) Eerste versie live: tien tot twintig weken: We bouwen naar een werkende eerste versie die live gaat en meteen gebruikt kan worden, in plaats van maanden te wachten op een big bang. Doorbouwen per milestone: Op basis van echt gebruik breiden we uit, verfijnen we en voegen we toe wat waarde blijkt te hebben. De doorlooptijd per milestone bepalen we samen vooraf. Onderhoud en optimalisatie: Het systeem blijft onderhoudbaar en veilig, en groeit mee met je bedrijf zonder dat de technical debt zich opstapelt. Maatwerksoftware of standaardsoftware: wanneer kies je wat Standaardsoftware (SaaS) Wanneer het past: Wanneer je proces grotendeels standaard is en niet je onderscheidend vermogen bepaalt. Wat het je oplevert: Je bent snel live, betaalt per maand en hoeft niets te beheren. De keerzijde: Je past je werk aan de software aan, je deelt dezelfde functionaliteit met al je concurrenten en je bent afhankelijk van de roadmap van de leverancier. Maatwerksoftware Wanneer het past: Wanneer je proces juist het verschil maakt, of wanneer geen enkel pakket dekt wat je nodig hebt. Wat het je oplevert: De software volgt jouw manier van werken, je bent eigenaar van de code en je bepaalt zelf wat er wanneer gebouwd wordt. De keerzijde: Het vraagt vooraf een grotere investering en een partner die meebouwt, en betaalt zich terug in een systeem dat precies past. Welke technologie past bij jouw maatwerksoftware Bouwen op bewezen technologie: We werken met frameworks en tools die zich in productie hebben bewezen en die door een brede community worden onderhouden. Dat betekent minder verrassingen, makkelijker onderhoud en developers die er later zonder inwerktijd mee verder kunnen. Volledig from scratch bouwen: Alles zelf bouwen geeft maximale vrijheid, maar kost meer tijd en levert code op die alleen jouw team begrijpt. Zinvol voor een uniek kernonderdeel, risicovol als fundament voor het hele systeem. Veelgestelde vragen over maatwerk software laten maken Wat kost het om maatwerk software te laten maken? De prijs van maatwerksoftware bepalen we niet vooraf op basis van een aanname, maar aan de hand van een discovery traject waarin we scope en aanpak scherp krijgen. Zo weet je waar je aan begint voordat er groot budget vastligt. In onze blog leggen we uit hoe een [discovery traject](/blog/wat-is-een-discovery-traject/) werkt en wat het oplevert. Hoe lang duurt het om maatwerk software te laten maken? Een discovery traject duurt maximaal twee weken. Daarna werken we naar een werkende eerste versie die doorgaans in tien tot twintig weken live gaat, afhankelijk van de complexiteit. Vanaf dat punt bepalen we de doorlooptijd per milestone samen vooraf. Wat is het verschil tussen maatwerksoftware en standaardsoftware? Standaardsoftware is gebouwd voor een brede markt en dwingt je je proces aan te passen aan het pakket. Maatwerksoftware volgt jouw manier van werken en groeit mee met je bedrijf. Standaard is sneller live en goedkoper in aanschaf, maatwerk past beter naarmate je proces onderscheidend is. Is maatwerk software duurder dan een standaardpakket? In aanschaf is maatwerk vaak duurder, in gebruik lang niet altijd. Bij een standaardpakket betaal je maandelijks per gebruiker en groeit die rekening mee met je bedrijf, terwijl je vastzit aan functionaliteit die niet helemaal past. Maatwerksoftware is een investering die je terugverdient in een proces dat wel klopt. Van wie is de code van mijn maatwerksoftware? De code is van jou, samen met de documentatie en de infrastructuur. Er is geen vendor lock-in: je kunt op elk moment met een ander team verder. Wij bouwen zodat je ons niet nodig hebt om te blijven draaien. Wat gebeurt er na livegang? Livegang is bij ons het startpunt, niet het einde. We bouwen per milestone verder op basis van echt gebruik en houden het systeem onderhoudbaar en veilig. Voor grotere digitale producten en platforms werken we vanuit dezelfde aanpak. Meer daarover lees je op onze pagina over [softwareproducten](/software-producten/). Eerlijk: wanneer wij niet de juiste keuze zijn Liever vooraf helder dan halverwege teleurgesteld. Herken je jezelf in een van deze punten, dan zijn wij waarschijnlijk niet de juiste partij. - Wanneer je alleen extra handjes zoekt om een afgebakende opdracht uit te voeren, zonder dat er meegedacht hoeft te worden over product en proces. - Wanneer je een fixed price wilt afspreken zonder ruimte om onderweg bij te sturen op wat we leren. - Wanneer je al een volledig uitgewerkt technisch plan hebt liggen en enkel iemand zoekt die het uitvoert. - Wanneer een standaardpakket je proces prima dekt. Dan is maatwerksoftware laten maken zonde van je geld, en zeggen we dat gewoon. --- ## Cases ### Realtime data tussen de Volkswagen-fabriek en het Nederlandse dealernetwerk Client: Volkswagen. URL: https://riotbyte.com/cases/volkswagen/ Nederland is wereldwijd het eerste land waar Volkswagen-dealers realtime data uitwisselen met de fabriek. Wij ontwierpen en bouwden de koppeling. ## Een wereldprimeur in Nederland Volkswagen koos Nederland als eerste land ter wereld waar dealers direct met de fabriek mochten koppelen. Riotbyte ontwierp en bouwde de pilot, samen met de softwareleverancier en zijn ontwikkelaars. Pon is de Nederlandse importeur van Volkswagen, Audi en Seat. Het Dealer Management System (DMS) van een Pon-softwareleverancier draait in vrijwel elk dealerbedrijf in Nederland. Monteurs, servicemedewerkers en magazijnpersoneel werken er dagelijks in. Tot voor kort liep de data tussen dat DMS en de Volkswagen-fabriek via een verouderde route. Elke paar minuten werd de complete historie van de afgelopen dagen opnieuw naar de fabriek gestuurd, alleen vanuit de dealer. Er was geen manier om te herkennen wat al gesynct was of wat sinds de vorige sync was gewijzigd, dus alles ging steeds opnieuw mee. Internationale informatie die de fabriek had over onderdelen en reparaties kwam niet terug naar het DMS. En wat er aan fabriekszijde binnenkwam, matchte vaak niet met de bestaande registratie, waardoor daar een berg ongekoppelde data ontstond. Volkswagen leverde nieuwe software die realtime synchronisatie ondersteunt, en vroeg of het Nederlandse dealernetwerk daar als eerste op aan zou sluiten. De softwareleverancier schakelde Riotbyte in voor het ontwerp en de bouw van de koppeling. Wij presenteerden wekelijks aan de Volkswagen-stakeholders en rolden de pilot uit bij de eerste dealer. ## Ingebouwd in het systeem zelf De vraag was niet óf een realtime koppeling kon. De vraag was hoe die in het bestaande DMS terechtkwam zonder dat de mensen op de werkvloer er last van hadden. Wij hebben de architectuur opgehangen aan de werkorder. Het moment waarop een handeling in het DMS wordt geregistreerd, is het moment waarop de fabriek het ziet. Diezelfde route werkt andersom: wat de fabriek weet over een onderdeel of een reparatie, verschijnt in het DMS op de plek waar de medewerker eraan werkt. Voor de mensen op de werkvloer is dit gewoon hun bestaande applicatie, alleen met een directe verbinding met de fabriek erbij. ## Alleen wat verandert Iedere werkorder loopt nu realtime over de koppeling. Wat een monteur registreert, staat binnen seconden bij de fabriek, op de juiste plek. Fabrieksinformatie over onderdelen en reparaties verschijnt automatisch in het DMS op het moment dat de medewerker er iets mee gaat doen. De zware periodieke syncs met de complete historie zijn verleden tijd: alleen wijzigingen stromen door, in beide richtingen. ## Resultaat Voor Volkswagen ligt er een eerste werkende implementatie. Data uit het Nederlandse dealernetwerk komt actueel en schoon binnen, in beide richtingen gekoppeld aan de fabrieksregistratie. De softwareleverancier heeft de architectuur in handen om de rest van het Nederlandse dealernetwerk zelfstandig aan te sluiten, zonder externe afhankelijkheid. En bij de eerste dealer is internationale fabrieksinformatie die voorheen niet bereikbaar was nu beschikbaar voor de mensen die er hun werk mee doen. De pilot staat live bij de eerste Nederlandse dealer. De rest van het Nederlandse netwerk rolt de leverancier zelf uit. Slaagt Nederland, dan volgt internationale uitrol vanuit de fabriek. --- ### TU Delft Library: ingehuurd voor twee klussen, gebleven voor het hele plaatje Client: TU Delft Library. URL: https://riotbyte.com/cases/tu-delft-library/ De research data repository van TU Delft, waar onderzoekers wereldwijd hun data delen, kampte met stabiliteitsproblemen die wekelijks om aandacht vroegen, ook 's avonds. Nu draait hij zonder dat iemand er naar hoeft te kijken. ## De situatie De research data repository is het platform waar onderzoekers aan de TU Delft en daarbuiten hun onderzoeksdata delen en publiceren. Wereldwijd bekeken, een open source project dat wordt onderhouden door een klein team binnen de universiteitsbibliotheek. Het team had een uitdaging die al een tijdje sluimerde. De applicatie kampte met stabiliteitsproblemen die wekelijks om aandacht vroegen, ook 's avonds. Een ontwikkelaar hield het in de gaten en sprong bij wanneer dat nodig was. Daardoor bleef de applicatie draaien, maar het team wist: zo kan het niet blijven. En er was nog iets wat onderhuids meespeelde. Iedere codewijziging voelde als een klein risico. Er stond geen geautomatiseerde controle tussen een wijziging en productie, dus wat goed werkte kon morgen stuk zijn zonder dat iemand het direct zou zien. ## Wat het team er concreet aan heeft Na dit traject draait het platform zonder dat er iemand op hoeft te letten. De server vangt drukke momenten zelf op, ook bij zware crawler-activiteit waar hij voorheen moeite mee had. Wat ooit een paar avonden per maand aan ongeplande inzet kostte, vraagt nu geen aandacht meer. De ontwikkelaar die dat bijhield heeft die tijd terug. En er staat nu een vangnet onder het ontwikkelproces. Elke wijziging wordt automatisch gecontroleerd voordat hij op productie terecht kan komen. Dat verandert hoe het team werkt. Nieuwe features bouwen hoeft niet meer met ingehouden adem, en een bug die tussendoor wordt gefixt kan niet ongemerkt iets anders stuk maken. Voor een klein team dat een platform draait waar onderzoekers van over de hele wereld hun onderzoeksdata delen, is dat een ander soort werken. ## Wat er ligt voor de toekomst Een applicatie die vandaag stabiel draait, is niet automatisch een applicatie die over drie jaar nog met gezonde kosten te onderhouden is. Daarom hebben we naast de concrete fixes ook een rapport opgeleverd met observaties en aanbevelingen over waar het platform staat en waar de keuzes zitten die het team structureel geld en tijd kosten als ze blijven zoals ze zijn. Dat geeft de organisatie iets om beslissingen op te baseren, nu en bij elke volgende moderniseringsstap: geen losse meningen, maar een onderbouwd overzicht van wat gezond is en wat aandacht verdient. ## Meer dan alleen de opdracht Het traject had een heldere scope en een vaste prijs, waarin beide partijen van tevoren wisten waar ze aan toe waren. Een deel van het werk hebben we samen met een ontwikkelaar van het TU Delft team gedaan, die geregeld naar Rotterdam kwam om samen aan specifieke stukken te werken. Zo bleef de kennis die wij opbouwden ook binnen het team zelf hangen. TU Delft Library huurde ons in voor twee afgebakende klussen: een probleem oplossen dat hen al te lang bezighield, en een testopzet neerzetten. Dat is gebeurd. Maar we hebben ons niet beperkt tot die twee klussen. We hebben meegekeken naar de applicatie als geheel, naar waar het team over een paar jaar wil staan, en naar de keuzes die nu gemaakt worden die dat mogelijk maken of juist in de weg zitten. Wat zij zochten was externe consultancy om iets te fixen. Wat ze kregen was een partij die meedenkt op het niveau waarop zij hun platform eigenlijk willen sturen, met uitkomsten die draaien om wat het de organisatie oplevert, niet om wat er technisch gebeurd is. --- ### Superconnectors: praktijken die meegroeien met het product Client: Superconnectors. URL: https://riotbyte.com/cases/superconnectors/ Een netwerkplatform dat in korte tijd hard was gegroeid, met praktijken die ondertussen een update verdienden. Wij hielpen Superconnectors aan een ontwikkelproces dat het tempo van het product aankan, zodat hun engineers met meer rust en vertrouwen kunnen blijven bouwen. Een product dat snel groeit is een mooi probleem, totdat het ontwikkelproces eronder het tempo niet meer bijhoudt en elke wijziging meer voorbereiding gaat vragen dan voorheen. Op dat punt stond Superconnectors toen ze ons benaderden. ## De situatie [Superconnectors](https://www.superconnectors.io/) verbindt startups, investeerders en communitybuilders via samengestelde events. Het platform is in korte tijd uitgegroeid en doet inmiddels veel: live biedingsspellen, AI-matchmaking, geautomatiseerde e-mailflows, en integraties met de tools waar partners op rekenen. Daarmee kwam ook de vraag om het ontwikkelproces eronder mee op te trekken, zodat het team wijzigingen kon doorvoeren met meer zekerheid dat de rest blijft staan en feature-werk kon leveren zonder dat elke aanpassing extra voorzichtigheid vraagt. ## Wat het team nodig had Een ontwikkelproces dat het tempo van het product bijhoudt: voorspelbaar werken, automatische controles tegen regressie onder elke wijziging, en genoeg gedeelde kennis om nieuwe mensen efficiënt in te kunnen werken. ## Hoe we het hebben aangepakt Onze opdracht was om het bestaande team toe te rusten en sneller te laten werken. Daarom hebben we gewerkt aan werkwijzen die het team zelf eigen maakt en doorzet, zodat het effect ook blijft als wij niet meer aangesloten zijn. ## Wat het oplevert Superconnectors levert nu uit met meer vertrouwen en kortere cyclustijden. Ontwikkelaars kunnen een wijziging doorvoeren zonder de hele applicatie in hun hoofd te hoeven hebben, en het team kan doorschalen zonder dat de complexiteit meegroeit. Het ontwikkelproces is daarmee weer in lijn met het product, en het team heeft de werkwijzen in handen om dat zo te houden naarmate Superconnectors verder groeit. --- ### OfficeR: een technisch partner die jouw missie waarmaakt Client: OfficeR. URL: https://riotbyte.com/cases/officer/ OfficeR breekt de gesloten kantorenmarkt open voor huurders. Wij vullen de technische rol in het bedrijf, van strategie tot oplevering. ## Een vastgelopen markt De kantorenmarkt werkt nog grotendeels zoals vijftien jaar geleden. Wie een kantoorruimte zoekt, gaat via een makelaar die een stevige fee rekent en heeft zelf weinig inzicht in wat er echt beschikbaar is. Michon van der Salm kent die markt van binnenuit, en weet precies waar het vastzit. Zijn missie met OfficeR: huurders weer de regie geven, op basis van heldere data en een eerlijk matchingsproces, en daarmee een markt die lang dezelfde vorm heeft opengooien. ## Hoe Michon bij ons kwam Toen Michon ons benaderde, lag er al een MVP. Die was gebouwd door een eerdere partij en was goed genoeg om het verhaal mee te vertellen. Hij kon potentiële partners en investeerders laten zien waar hij heen wilde. Wat ontbrak was voldoende aanbod in de database, en iemand die verder meedacht dan opleveren wat er werd gevraagd. Wat Michon zocht was geen nieuwe leverancier maar een technisch partner. Iemand die niet vanuit techniek denkt maar vanuit het bedrijf: wat moet OfficeR op korte termijn waar kunnen maken, waar staat het over drie jaar, en welke keuzes nu maken dat mogelijk. Iemand die kritisch meedenkt in plaats van klakkeloos uitvoert, en die de uitkomsten van dat gesprek vervolgens zelf omzet in werkend product. ## Hoe we die rol invullen Wij zijn voor OfficeR het technische deel van het bedrijf. Wat dat in de praktijk betekent: we beginnen niet bij de techniek maar bij de onderneming. Waar wil OfficeR over een jaar staan, welke markt willen we dan bedienen, wat hebben we dan nodig. Pas daarna komt de vraag hoe we dat technisch bouwen. Zo blijft de techniek iets wat het bedrijf ondersteunt, in plaats van iets waar de onderneming zich naar moet voegen. In de praktijk zitten we daarom niet alleen aan tafel als er code geschreven moet worden. We schuiven aan bij gesprekken met potentiële data-partners, we denken mee over wat prioriteit verdient op de roadmap en wat nog even kan wachten, en we zorgen dat wat er vandaag gebouwd wordt ook past bij waar OfficeR volgend jaar wil staan. Dat maakt de rolverdeling helder. Michon doet waar hij het sterkst in is: de markt kennen, partijen binnenhalen, richting bepalen. Alles wat techniek is ligt bij ons, van strategie tot uitvoering. We schakelen op ondernemingsniveau, niet op taakniveau. Dat betekent ook dat we kritisch zijn op wat er gebouwd moet worden. Wat een oprichter intuïtief denkt dat klopt, is niet altijd wat gebruikers of marktpartijen terugzeggen. We stellen die vragen, zoeken de input op bij de mensen voor wie we bouwen, en helpen zo mee de goede conclusies te trekken voordat we iets in code gieten. ## Hoe de samenwerking er inmiddels uitziet Wat begon als "ons product op de rit krijgen" is uitgegroeid tot een structurele betrokkenheid bij OfficeR als onderneming. We zijn geen leverancier die per project wordt ingehuurd, we zijn de technisch partner waarbij de verantwoordelijkheid thuishoort. Voor Michon betekent dat dat hij zich volledig kan richten op wat OfficeR in de markt wil zijn, met de zekerheid dat er naast hem staat wie dat technisch ook waar kan maken. --- ### Skalar: software die meebeweegt met instrumenten van wereldklasse Client: Skalar Analytical. URL: https://riotbyte.com/cases/skalar/ Skalar bouwt al sinds 1965 laboratoriuminstrumenten waar labs over de hele wereld op leunen. Voor de volgende generatie software wilden ze een gedeelde basis onder al hun productlijnen, plus reproduceerbare cloud-infrastructuur in eigen beheer. Wij hebben dat samen met hen opgezet. [Skalar Analytical](https://www.skalar.com/) bouwt sinds 1965 laboratoriuminstrumenten die wereldwijd in milieu-, farma- en voedingslabs draaien. Aan de softwarekant van die producten was een volgende stap nodig. ## De situatie De besturingssoftware van Skalar was over de jaren met de instrumenten zelf meegegroeid. Per productlijn, en vaak per generatie, was er een eigen applicatie ontstaan. Een logische evolutie, maar zonder gedeelde codebase waar alle productlijnen op konden voortbouwen. Voor de volgende generatie instrumenten wilde Skalar die er wél onder leggen, zodat nieuwe ontwikkelingen niet telkens vanaf nul beginnen. Tegelijk maakte Skalar de stap richting cloud, omdat klanten op termijn van hun apparatuur dezelfde gebruikservaring zullen verwachten als van de software die ze dagelijks gebruiken. Daarvoor zochten ze een partner die de software op één gedeelde codebase kon brengen en daaronder reproduceerbare cloud-infrastructuur kon opzetten. ## Hoe we het hebben aangepakt Aan de softwarekant hebben we een gedeelde codebase gebouwd waar alle instrumentbesturing op draait, met een gemeenschappelijk design system en de gedeelde functionaliteit op één plek. Wat eerder per productlijn los groeide, draait nu op één schaalbaar platform. Het ontwikkelteam heeft daardoor minder dubbel werk, en de Skalar-ervaring blijft consistent tussen instrumenten. Aan de infrastructuurkant hebben we de cloud opgezet met de randvoorwaarde dat het Skalar team het zelfstandig moet kunnen voortzetten. Daarom is alles als code vastgelegd en gedocumenteerd, zodat het beheer en de uitbreiding bij Skalar zelf liggen, zonder afhankelijkheid van ons. ## Wat het oplevert Skalar heeft nu één schaalbaar softwareplatform voor alle productlijnen. De volgende generatie instrumenten begint daarmee niet meer bij nul, en de cloud-infrastructuur eronder draait in eigen beheer. Hardware en software groeien zo uit dezelfde lijn door, op een tempo dat Skalar zelf bepaalt. --- ### SkillyBee: van visie naar valideerbaar concept Client: SkillyBee. URL: https://riotbyte.com/cases/skillybee/ SkillyBee had een ambitieus idee voor een platform waar talent zichtbaar wordt en coaches helpen verder te groeien. Voordat de bouw begon, hielpen wij dat idee scherp te krijgen: wat hoort bij de eerste versie, en kan het concept overeind blijven als product. Voordat SkillyBee aan de bouw begon, was er een andere vraag: blijft dit concept als product overeind, en hoe ziet een minimale versie eruit waarmee dat te toetsen valt? ## De situatie SkillyBee zag een platform voor zich waar creators hun vaardigheden laten zien via posts en daar gestructureerde feedback op krijgen van gecertificeerde coaches. Geen vacaturesite of portfoliosite, maar een omgeving waar vaardigheden zichtbaar worden gemaakt en aangescherpt door inhoudelijke interactie tussen verschillende gebruikersgroepen. Met meerdere gebruikersgroepen die elkaar moeten versterken zat de complexiteit in het ontwerp van het idee zelf. Hoe weet je voorafgaand aan de bouw of dat idee als product werkt, en welke onderdelen daadwerkelijk horen bij een eerste versie waarmee je dat kunt aantonen? ## Hoe we het hebben aangepakt We hebben SkillyBee door een discovery-traject genomen. In workshops hebben we uitgewerkt wie de verschillende gebruikersgroepen zijn, wat ze van elkaar nodig hebben, en welke onderdelen werkelijk horen bij de eerste versie tegenover wat later kan komen. Dat zijn de juiste vragen op het juiste moment, voordat antwoorden in code worden vastgelegd. De uitkomst is een klikbaar prototype van hoe het platform zou werken, met onderbouwing van de keuzes daarachter. SkillyBee kan dat direct voorleggen aan gebruikers, partners en investeerders, en gebruikt het om feedback op te halen voordat er een regel code wordt geschreven. ## Wat er ligt SkillyBee ging weg met een gevalideerd concept, een heldere afbakening van wat de eerste versie wel en niet doet, en een prototype waarmee dat verhaal direct te vertellen valt. Wanneer de bouwfase begint, vertrekt SkillyBee vanuit keuzes die zijn getoetst bij de gebruikersgroepen waar het platform voor bedoeld is. --- ## Tech ### TypeScript Slug: `typescript`. URL: https://riotbyte.com/tech/typescript/. Official site: https://www.typescriptlang.org/ De taal waarin we bijna alles schrijven. Types vangen het soort fouten die op productie pas pijn doen. TypeScript is de standaard taal achter vrijwel elk Riotbyte-project. De extra strengheid kost je een paar minuten extra in het editorvenster en bespaart je dagen aan debugging in productie. Refactors die anders weken zouden vragen kunnen in TypeScript binnen een middag, omdat de compiler de aanroepende code voor je vindt. Wij zetten TypeScript niet alleen op de frontend in maar over de hele stack heen: gedeelde domeinmodellen tussen client en server, strakke API-contracten, en types die uit de database afgeleid worden zodat één bron van waarheid blijft staan tussen schema en code. --- ### React Slug: `react`. URL: https://riotbyte.com/tech/react/. Official site: https://react.dev/ De UI-bibliotheek waar we frontends mee bouwen die snel laden en lang houdbaar zijn. React is voor ons de default voor klant-facing en interne web-interfaces. De combinatie met TypeScript, een doordachte componenten-bibliotheek en server-side rendering levert frontends op die zowel snel laden voor de gebruiker als jaren te onderhouden blijven voor het team eronder. Wij bouwen React-interfaces voor scaleups die hun product opbouwen, voor admin-omgevingen die met grote datasets stabiel moeten draaien, en voor publieke sites waar performance direct conversie raakt. Altijd met aandacht voor toegankelijkheid, een ontwerp-systeem dat met het product meegroeit, en een testopstelling die het team durft te wijzigen. --- ### Angular Slug: `angular`. URL: https://riotbyte.com/tech/angular/. Official site: https://angular.dev/ Opinionated TypeScript-framework voor frontends waar structuur en testbaarheid voorgaan. Angular is voor ons de keuze wanneer een frontend genoeg complexiteit draagt om gebaat te zijn bij een framework met sterke conventies in plaats van losse bibliotheken. Modules, dependency injection, een eigen template-taal en eerste-klas TypeScript-ondersteuning geven structuur aan applicaties die jaren mee moeten en door wisselende teams onderhouden worden. Wij zetten Angular in voor enterprise-grade frontends, voor systeemintegratie-portalen waar veel data, formulieren en interacties tegelijk samenkomen, en voor producten waar de samenstelling van het team in de loop van de tijd verandert. De conventies van Angular zorgen dat nieuwe ontwikkelaars sneller meekomen op een bestaande codebase. --- ### Next.js Slug: `nextjs`. URL: https://riotbyte.com/tech/nextjs/. Official site: https://nextjs.org/ React-framework voor productie-applicaties waar performance, SEO en developer experience tegelijk moeten kloppen. Next.js is voor ons het default framework als we een React-applicatie naar productie brengen. Server components, file-based routing, en een rendering-strategie (SSR, ISR, statisch) die per route gekozen kan worden zonder dat de codebase in twee architecturen uiteenvalt. We zetten Next.js in voor klant-facing portalen waar laadtijd direct conversie raakt, voor admin-interfaces die met honderden gelijktijdige gebruikers stabiel moeten draaien, en voor publieke sites waar SEO en deelbare URL's net zo belangrijk zijn als de interactie eronder. --- ### NestJS Slug: `nestjs`. URL: https://riotbyte.com/tech/nestjs/. Official site: https://nestjs.com/ Het backend-framework waar we API's mee bouwen die met het bedrijf meegroeien. NestJS is ons default backend-framework voor TypeScript-services die meer doen dan een handjevol endpoints. Modules, dependency injection en duidelijke layering geven structuur aan een codebase die over jaren mensen ziet komen en gaan zonder dat de architectuur verwatert. Wij gebruiken NestJS voor systeem-integraties waar meerdere bronnen samenkomen, voor backends die honderden gelijktijdige gebruikers stabiel moeten bedienen, en voor producten waarvan de API in de loop van de tijd zelf onderdeel van het aanbod wordt. --- ### Symfony Slug: `symfony`. URL: https://riotbyte.com/tech/symfony/. Official site: https://symfony.com/ PHP-framework voor backends waar architectuur, testbaarheid en lange-termijn-onderhoud meetellen. Symfony is een volwassen PHP-framework dat dezelfde patronen biedt als wat je in NestJS of Spring zou herkennen: modules, services, dependency injection, en een eigen ORM (Doctrine) waarmee complexe domeinmodellen helder te beschrijven zijn. Voor PHP-teams met een bestaande codebase betekent het: een upgrade-pad zonder de stack op te blazen. Wij werken met Symfony bij systeem-integraties waar PHP de gegeven werkomgeving is, bij scaleups die een bestaande Symfony-applicatie verder willen brengen, en in situaties waar de architectuur een opinionated framework verdraagt om snelheid en correctheid samen mogelijk te maken. --- ### Livewire Slug: `livewire`. URL: https://riotbyte.com/tech/livewire/. Official site: https://livewire.laravel.com/ Server-rendered interactiviteit voor PHP-applicaties, zonder een aparte frontend-stack erbij te bouwen. Livewire is een PHP-bibliotheek die interactieve componenten op de server rendert en via een dunne JavaScript-laag synchroon houdt met de client. Het vult de plek tussen klassieke server-rendered apps en een full SPA: je houdt PHP als bron van de waarheid, maar krijgt het soort interactiviteit waar gebruikers vandaag op rekenen. Wij zetten Livewire in bij PHP-platforms waar de complexiteit niet rechtvaardigt om een tweede stack erbij te onderhouden, en waar de doorlooptijd van feature naar productie kort moet blijven. Vooral nuttig bij moderniseringen van bestaande PHP-systemen, waar de team-skills al in PHP zitten en het pad naar een aparte React- of Vue-frontend onevenredig veel kosten zou vragen. --- ### PostgreSQL Slug: `postgres`. URL: https://riotbyte.com/tech/postgres/. Official site: https://www.postgresql.org/ De relationele database waar wij standaard naar grijpen wanneer data integriteit telt. PostgreSQL is de open-source relationele database die de meeste van onze productiesystemen draagt. Sterk type-systeem, transacties die je kunt vertrouwen, en een ecosysteem aan extensies (PostGIS, pgvector, TimescaleDB) dat hem klaar maakt voor werk dat verder gaat dan een CRUD-applicatie. Wij gebruiken Postgres voor financiële platformen waar consistentie verplicht is, voor systemen waar tientallen miljoenen rijen rond moeten zonder dat queries traag worden, en voor producten die geleidelijk uitbreiden naar zaken als full-text search of geospatial data zonder dat we van database hoeven te wisselen. --- ### Prisma Slug: `prisma`. URL: https://riotbyte.com/tech/prisma/. Official site: https://www.prisma.io/ De data-laag die het databaseschema en de TypeScript-types in één bron van waarheid houdt. Prisma is onze standaard tussen TypeScript-applicaties en PostgreSQL. Eén schemabestand definieert de database én de types die de applicatie eronder gebruikt. Wijzigingen propageren zichtbaar door je codebase: migraties, queries en uitkomsten lopen synchroon, en de compiler vangt wat anders pas op productie zou breken. Wij zetten Prisma in voor applicaties waar data en domein nauw verweven zijn, waar het schema vaak wijzigt naarmate het product groeit, en waar verschillende teams tegelijk aan dezelfde codebase werken zonder dat queries en kolommen langs elkaar heen gaan leven. --- ### Supabase Slug: `supabase`. URL: https://riotbyte.com/tech/supabase/. Official site: https://supabase.com/ PostgreSQL-gebaseerde backend-as-a-service met realtime, auth en row-level security uit de doos. Supabase is voor ons de keuze wanneer een product de kracht van een echte PostgreSQL-database wil zonder eerst een eigen backend op te bouwen. Authenticatie, realtime subscriptions, opslag en row-level security komen meegeleverd, en omdat het onder de motorkap gewoon Postgres is hou je later alle vrijheid om naar een eigen backend te schalen zonder van database te wisselen. Wij zetten Supabase in voor scaleups die snel naar gebruikers willen zonder de operationele overhead van een eigen platform, voor producten waar realtime samenwerking centraal staat, en voor MVP's waar het bewijs uit gebruikersgedrag moet komen voordat zware investering in infrastructuur te rechtvaardigen valt. --- ### Firebase Slug: `firebase`. URL: https://riotbyte.com/tech/firebase/. Official site: https://firebase.google.com/ Backend-as-a-service voor producten die snel naar gebruikers willen zonder eerst een platform op te bouwen. Firebase brengt authenticatie, realtime database, opslag en cloud functions in één pakket. Voor producten in de eerste paar maanden levensduur betekent dat: je richt je aandacht op de feature waarmee je gebruikers wint, in plaats van op de infrastructuur eronder. Wij kiezen voor Firebase wanneer een product snel naar de markt moet, wanneer realtime samenwerking tussen gebruikers een eis is, of wanneer de operationele overhead van een zelf-gebouwde backend (nog) niet te rechtvaardigen valt. Wanneer het product schaalt en de eisen complexer worden, helpen we vervolgens met de stap naar een eigen backend zonder breuk voor de gebruiker. --- ### Docker Slug: `docker`. URL: https://riotbyte.com/tech/docker/. Official site: https://www.docker.com/ Containers zodat 'het werkt op mijn machine' niet langer een productiestoring is. Docker is de gemene deler onder ongeveer elk Riotbyte-project. Dezelfde container draait lokaal, in CI, in staging en in productie. Een bug die je in development reproduceert blijft daardoor ook in productie gefixt, en omgekeerd. Wij gebruiken Docker als basis voor een reproduceerbare development-omgeving, voor CI-pipelines waar testen onder realistische omstandigheden draaien, en als bouwsteen onder grotere orchestratie zoals Kubernetes wanneer de eisen daar om vragen. --- ### DevOps Slug: `devops`. URL: https://riotbyte.com/tech/devops/ Infrastructure-as-code, CI/CD en observability: zo kan het team morgen nog releasen zonder ingehouden adem. DevOps is bij ons geen aparte rol maar een werkwijze. Elke wijziging gaat door geautomatiseerde controles voordat hij productie raakt, infrastructuur staat in code zodat omgevingen reproduceerbaar zijn, en er staan dashboards die het verschil tussen "het werkt" en "het werkt voor iedereen" zichtbaar maken. We pakken DevOps op wanneer een team sneller wil releasen zonder regressies, wanneer een platform stabiliteitsproblemen heeft die wekelijks om aandacht vragen, of wanneer een organisatie de stap maakt van een handmatige deploy naar een proces waar iedereen op kan vertrouwen. --- ### Sentry Slug: `sentry`. URL: https://riotbyte.com/tech/sentry/. Official site: https://sentry.io/ Observability voor productie-software. Fouten zien voordat een gebruiker ze meldt. Sentry is onze standaard voor het kort houden van de afstand tussen "er is iets stuk in productie" en "we weten wat er stuk is". Stack traces met context, release-tracking, en alerts die naar het team gaan zonder dat iemand handmatig logs moet doorploegen. Wij koppelen Sentry vanaf dag één aan productie-applicaties, niet als een naderhand-toevoeging. Bij scaleups die te lang met "zoek het uit in de logs" werkten geven we vaak ook een tweede leven aan Sentry: gestructureerde events, foutbudgetten en dashboards waar het team daadwerkelijk naar kijkt. --- ### Electron Slug: `electron`. URL: https://riotbyte.com/tech/electron/. Official site: https://www.electronjs.org/ Cross-platform desktop apps gebouwd met web-technologie, voor producten waar hardware en native UX samenkomen. Electron pakt een Node.js-runtime en Chromium-renderer in één installeerbare desktop-applicatie. Je schrijft de UI in React (of welk web-framework je team al kent) en levert hetzelfde resultaat op Windows, macOS en Linux. Voor producten die op werkstations naast hardware moeten draaien betekent het: één codebase, drie platforms. Wij zetten Electron in wanneer een product met laboratorium- of industriële instrumenten moet praten via lokale protocollen, wanneer offline werken een eis is, of wanneer een installeerbare app vertrouwen oplevert dat een browser-tab niet wekt. In combinatie met TypeScript en React blijft de codebase consistent met onze webprojecten en kan het team makkelijk schakelen tussen surfaces. --- ### .NET Slug: `dotnet`. URL: https://riotbyte.com/tech/dotnet/. Official site: https://dotnet.microsoft.com/ Microsoft's volwassen cross-platform framework voor backend-services en desktop-applicaties, met C# als domein-taal. .NET en C# zijn de keuze wanneer een team al in het Microsoft-ecosysteem werkt, wanneer Azure-integratie eersteklas moet zijn, of wanneer hardware-integratie en interop met bestaande Windows-componenten centraal staan. Het type-systeem van C# is sterk genoeg om grote domeinmodellen helder uit te drukken zonder dat de codebase verwatert. Wij werken met .NET bij integraties met laboratoriuminstrumenten, industriële controllers en Microsoft-cloud-systemen. Voor scaleups in industriële, lab- of healthcare-domeinen levert het een ecosysteem waar dependencies, tooling en operationele kennis gewoon bestaan: geen niche-stack die je later weer weg moet engineeren. --- ### Azure Slug: `azure`. URL: https://riotbyte.com/tech/azure/. Official site: https://azure.microsoft.com/ Microsoft's cloud platform voor producten waar enterprise-integratie, Active Directory en hybride scenarios meetellen. Azure is de cloud waar je naartoe gaat wanneer Microsoft-tooling al onderdeel is van de klantorganisatie, wanneer Active Directory de waarheid is over wie binnen mag, of wanneer een hybride architectuur (on-prem instruments plus cloud-data) een gegeven is. App Service, Functions, Container Apps, AKS en Azure SQL leveren dezelfde bouwstenen als de andere clouds, met betere koppeling naar Microsoft-only stacks. Wij zetten Azure in bij scaleups in het Microsoft-domein (lab, industrieel, finance, healthcare), bij integraties met bestaande Microsoft-back-offices, en bij producten waar Active Directory en single-sign-on vanaf dag één goed moeten zitten. Beheer doen we via Terraform zodat omgevingen reproduceerbaar in code beschreven staan. --- ### Terraform Slug: `terraform`. URL: https://riotbyte.com/tech/terraform/. Official site: https://www.terraform.io/ Infrastructure as code: omgevingen in versiebeheer in plaats van handmatige clicks in een cloud-console. Terraform beschrijft cloud-infrastructuur in declaratieve code. Wat je in Git ziet is wat in de cloud draait. Geen drift tussen staging en productie omdat iemand een knop in de console heeft omgezet. Een nieuwe omgeving aanmaken is een `terraform apply` in plaats van een dagvullende handmatige checklist. Wij zetten Terraform in bij elk traject waar meer dan één omgeving in het spel is: staging tegenover productie, multi-tenant per klant, of disaster-recovery-replica's. Providers voor Azure, AWS, DigitalOcean en Cloudflare houden onze playbook consistent ongeacht waar de workloads landen. --- ### Kubernetes Slug: `kubernetes`. URL: https://riotbyte.com/tech/kubernetes/. Official site: https://kubernetes.io/ Container-orchestratie die vastgelopen pods zelf vervangt en meeschaalt met de drukte, zodat niemand 's nachts een server herstart. Kubernetes draait de containers die Docker bouwt en verdeelt ze over meerdere machines. Nieuwe versies rollen uit zonder dat gebruikers er iets van merken; valt een node weg of loopt een pod vast, dan plant Kubernetes het werk zelf opnieuw in. Jij beschrijft de gewenste toestand. Kubernetes beweegt de werkelijkheid daarnaartoe — en houdt dat zo. Wij draaien de producten van onze klanten op één cluster, met een aparte namespace per project: isolatie zonder de kosten van een cluster per klant. Schalen gebeurt automatisch op basis van echte belasting, en Prometheus, Grafana en Loki staan er vanaf dag één op. Dezelfde manifesten die lokaal in een k3d-cluster draaien gaan ongewijzigd naar productie. Alles staat declaratief in Git: wat in de repo staat is wat er draait. --- ## Team ### Daniël Brekelmans (Founder) Vertaalt business naar techniek, en terug. Tien jaar als senior engineer en lead voor scaleups en multinationals. Evenveel tijd doorgebracht in directiekamers als in code. Vertaalt strategische keuzes naar architectuur, en architectuur terug naar wat het kost en oplevert. Vindt "nee" soms het beste antwoord. --- ### Niels Mokkenstorm (Founder) Begint bij wie ermee werkt, tekent de architectuur, maakt het werk lichter. Gelooft dat goede infrastructuur niet over uptime gaat, maar over flow, focus en werkplezier van het developer-team. Zorgt dat het juiste doen ook het makkelijkste is. Tien jaar als technisch eindverantwoordelijke en engineer bij scaleups en grotere organisaties. Schrijft code, ontwerpt architectuur en doet site reliability engineering: betrouwbare software op Azure, AWS en Kubernetes. --- ### Maarten Nusteling (Founder) Bouwt producten die over vijf jaar nog staan én meegroeien. Bemoeit zich net zo graag met de architectuur als met de eerste mockup. Bouwt full-stack, van idee tot deploy, en denkt vijf versies vooruit. Kiest liever de saaie technologie die over vijf jaar nog werkt dan de hippe stack van vandaag. ---