Toen ik besloot deze webapplicatie echt te gaan bouwen, stond de allereerste vraag niet in de code op mijn scherm. Die stond gewoon thuis aan de keukentafel: waar zet ik dit systeem eigenlijk neer, en wie fixt het als het midden in de nacht stukgaat?

Het antwoord was pijnlijk simpel: niemand. Ik ben tenslotte geen systeembeheerder. Ik heb geen servers in de kelder draaien en wil zeker geen complexe eigen server in de cloud die ik helemaal zelf moet onderhouden en waar ik om drie uur 's nachts voor uit bed moet als hij crasht. Firebase — met out-of-the-box hosting, een snelle database, inlogsystemen en serverless functions — leek me de enige realistische optie. Snel live kunnen gaan, per klant een eigen veilige workspace bieden, en pas verder kijken als het product echt z'n waarde bewijst. Of dat technisch gezien voor elke ontwikkelaar de beste keuze is? Geen idee. Maar voor mij werkte het direct.

"Even snel neerzetten" en "goed gebouwd" bleken in de praktijk toch veel dichter bij elkaar te liggen dan ik dacht. In het prille begin leek het een prima idee om bijna alles in één groot bestand te gieten. Lekker overzichtelijk, toch? Totdat ik zelf na een paar weken absoluut niet meer wist waar ik bepaalde functies had verstopt.

Na een paar maanden worstelen knipte ik de boel resoluut op: aparte modules voor de takenlijst, de Q&A, de Business Lens, de gedeelde status en de vertalingen (NL/EN). Niet omdat dat zo hip klinkt op een ontwikkelaarsforum, maar simpelweg omdat ik anders zelf de weg kwijtraakte in mijn eigen systeem. En vooral omdat een kleine wijziging in het ene scherm natuurlijk niet per ongeluk drie andere workflows kapot mocht maken.

Toch red je het met Firebase alleen niet altijd. Zodra inloggen, betalingen en klantensupport met elkaar gaan praten, wordt de keten best lang. Soms faalde er iets tijdens het inloggen, terwijl de code op papier 100% klopte. Dan zat het probleem vaak veel dieper: toegangsrechten die net niet goed stonden, een klein foutje bij het live zetten, of iets dat stilletjes misging in de pijplijn op de achtergrond. Voor een gebruiker is dat geen abstract, technisch probleem; die ziet alleen maar de frustratie van "ik kan niet inloggen".

Daarom hanteer ik nu één keiharde regel: geen derde pleister op dezelfde wond plakken, maar eerst tot op de bodem uitzoeken waar het systeem precies breekt. Dán pas repareren.

Dat kost aan de voorkant absoluut meer tijd. Maar de structurele rust die het later oplevert? Die onthoud ik nu al. Of ik deze modulaire, rustige aanpak bij een volgend traject overal weer zo zou toepassen? Waarschijnlijk wel.