Van een bierviltje naar een slimme React-app

Van een bierviltje naar een slimme React-app

Bayramali Dilek

Dat was precies de uitdaging achter de KVK Verdiencheck: een online tool waarmee aspirant-ondernemers kunnen ontdekken of hun bedrijfsidee voldoende inkomen oplevert om van te leven. Een relatief eenvoudige vraag aan de voorkant, maar met verrassend veel technische en UX-uitdagingen onder de motorkap. Op basis van een idee vanuit de business vertaalde een multidisciplinair team het concept naar een toegankelijke digitale oplossing: de KVK Verdiencheck.

Van concept naar werkende applicatie



Voor developers Angel en Bayramali begon het project toen het concept vanuit business en UX werd toegewezen aan hun team voor de uitwerking.

"Het concept lag er al grotendeels. Voor ons begon het bij de vraag: hoe maken we dit zo gebruiksvriendelijk mogelijk?" vertellen ze.

De eerste ontwerpen gingen uit van een mobile-first aanpak met een zogenaamde stepper, waarbij gebruikers stap voor stap door het proces werden geleid. Tijdens het ontwerp- en testproces bleek echter dat gebruikers eerder ingevulde gegevens moeilijk konden terugvinden en aanpassen.

Het team besloot daarom een andere richting te kiezen: alle relevante invoervelden werden op één pagina geplaatst, logisch verdeeld over secties. Hierdoor ontstond meer overzicht en konden gebruikers eenvoudig terugkeren naar eerdere keuzes zonder hun voortgang kwijt te raken.

React, realtime berekeningen en slimme state management

Technisch gezien draait de Verdiencheck volledig op een frontend-oplossing gebouwd in React. Alle berekeningen vinden direct in de browser plaats.

Dat levert twee belangrijke voordelen op:

Geen extra communicatie met de backend;

Directe feedback voor de gebruiker.

Wanneer een ondernemer bedragen aanpast, worden de resultaten realtime bijgewerkt. De applicatie voelt daardoor snel en responsief aan.

De grootste technische uitdaging zat echter niet in de berekeningen zelf, maar in het beheren van gebruikersdata.

Neem bijvoorbeeld de situatie waarin een gebruiker eerst producten aanbiedt en later overstapt naar diensten. De eerder ingevoerde productgegevens mogen niet meer meetellen in de berekeningen, maar moeten wel beschikbaar blijven als de gebruiker zijn keuze opnieuw wijzigt. Dat betekent dat data tijdelijk moet worden uitgesloten van de businesslogica, terwijl deze wel beschikbaar blijft binnen de applicatiestaat.

"Dat klinkt eenvoudig, maar achter de schermen moesten we goed nadenken over hoe we die gegevens bewaren zonder dat ze de berekeningen beïnvloeden."

Achter een ogenschijnlijk simpele gebruikersinteractie schuilt daardoor een behoorlijk complexe state-management uitdaging.

Slim omgaan met technische beperkingen



Een ander interessant vraagstuk ontstond rondom een gewenste PDF-downloadfunctie.

In een vroeg stadium was het idee dat gebruikers hun berekeningen als PDF konden downloaden. De developers hadden hiervoor zelfs al een werkende oplossing gebouwd. Tijdens security-beoordelingen bleek echter dat de gekozen library niet voldeed aan de interne veiligheidsrichtlijnen.

Omdat de applicatie bewust zonder backend was ontworpen, viel ook het gebruik van bestaande server-side PDF-functionaliteit af. Uiteindelijk werd besloten de functie tijdelijk buiten scope te plaatsen. "Dat was wel jammer. We hadden een mooie oplossing gebouwd waar we best trots op waren. Maar security gaat altijd voor."

In plaats daarvan bedacht het team een alternatieve oplossing. Via een hash in de URL blijft de actuele staat van de applicatie behouden. Gebruikers kunnen de link opslaan of delen en later hun ingevulde gegevens opnieuw openen.

Samenbouwen met UX, business en gebruikers



Wat dit project volgens Angel en Bayramali vooral succesvol maakte, was de samenwerking tussen verschillende disciplines.

Wekelijkse sessies met business, UX en development zorgden ervoor dat ideeën voortdurend konden worden getoetst en verbeterd. Ontwerpen werden aangepast op basis van technische inzichten, terwijl developers tegelijkertijd meedachten over gebruiksvriendelijkheid en klantbehoeften.

Ook gebruikers werden actief betrokken bij het ontwikkelproces. Tijdens testsessies met ondernemers kwamen nieuwe inzichten naar voren. Zaken die in eerste instantie logisch leken, bleken in de praktijk soms verwarrend. Door die feedback direct terug te koppelen naar ontwerp en ontwikkeling kon de applicatie stap voor stap verder worden verbeterd.

Voor Angel en Bayramali betekende dit veel meer dan alleen code schrijven. Het betekende meedenken, uitdagen, ontwerpen verbeteren en samen zoeken naar de beste oplossing.

Waarom dit soort projecten aantrekkelijk zijn voor developers



De Verdiencheck laat goed zien wat werken aan digitale dienstverlening bij KVK interessant maakt.

Je werkt niet alleen aan techniek, maar aan oplossingen die daadwerkelijk impact hebben op ondernemers in Nederland. Tegelijkertijd krijg je de ruimte om technische keuzes te maken, samen te werken met verschillende disciplines en complexe vraagstukken terug te brengen tot een gebruiksvriendelijke ervaring.

Of het nu gaat om React-applicaties, UX-vraagstukken, state management, security-eisen of gebruikersvalidatie: achter een relatief eenvoudige tool schuilt een verrassend uitdagend ontwikkeltraject.

Voor de developers was de Verdiencheck meer dan een tool bouwen. Het was een kans om vanaf de eerste versie mee te werken aan een nieuw product dat direct impact heeft op ondernemers.

"Vanaf scratch bouwen blijft het leukst. Dan ben je echt aan het creëren in plaats van alleen aan het uitbreiden of onderhouden."

Vacatures bij KVK