We kozen monday.com en bouwden de rest van Jira zelf

Jira is sterk in sprints en backlogs, maar je betaalt per gebruiker. En bij ons werken niet alleen developers in tickets: ook marketing, content en projectmanagement plannen hun werk erin. Voor een bureau van onze grootte liep die rekening te hoog op voor wat we eruit haalden.

We kozen monday.com. Het is overzichtelijk, ook voor wie geen developer is, en het past bij ons budget. Alleen: monday.com is geen Jira. Sprints met echte data, een backlog met een vaste volgorde en een overzicht van wie hoeveel werk heeft, zaten er niet in zoals wij dat wilden.

Een extra pakket, of een tweede tool naast monday.com? Dan betaal je twee keer en zet je gegevens met de hand over. We kozen een derde weg.

Infra is ons interne systeem, gebouwd in Drupal 11. Het begon in de zomer van 2025 als urenregistratie. Eind 2025 kwamen de koppeling met monday.com en de facturen erbij, in 2026 de afspraken met klanten, de cijfers en de planning.

Een collega opent een ticket en schrijft er uren op, en die uren komen vanzelf op de goede factuur. Een projectmanager plant per klant een sprint en ziet in één scherm wat af is, wat vastzit en wie het te druk heeft.

De belangrijkste keuze viel voor de eerste regel code: welk systeem is de baas over welk gegeven? monday.com blijft de bron van het ticket: de naam, de status, wie eraan werkt, de deadline en de schatting. Infra is de bron van de planning: in welke sprint een ticket zit, of het klaar is voor een sprint en in welke volgorde. Die planning gaat nooit naar monday.com.

Verandert iemand in Infra iets aan een ticket, dan gaat dat eerst naar monday.com. Pas als monday.com de wijziging accepteert, past Infra zijn eigen kopie aan. Zo lopen de twee systemen niet uit elkaar.

• Een bord per klant. Kolommen van Te doen tot Afgerond. Sleep je een kaart naar een andere kolom, dan verandert de status in monday.com mee. Weigert monday.com de wijziging, dan schuift de kaart vanzelf terug.
• Sprints met echte data. Een begin, een eind, een doel van één zin en wat er is toegezegd. Wat er halverwege bijkomt, staat apart. Sluit je een sprint af, dan gaat wat niet af is mee naar de volgende sprint of terug naar de backlog.
• Een backlog met een volgorde. Nieuwe tickets komen binnen als Nieuw. De projectmanager zet ze op Klaar voor sprint, In de wacht of Niet nu, en sleept de klare tickets op volgorde. Net als in Jira heeft elke rij een menu om hem te verplaatsen.
• Werklast en signalen. Per collega staan de geplande uren naast de uren die die collega in de sprint beschikbaar heeft. Een ticket dat te laat is of te laat dreigt te worden, krijgt een signaal.
• Een ticketpagina zoals in Jira. De naam bovenaan, de status en wie eraan werkt ernaast, de reacties uit monday.com eronder, met @mentions en bijlagen. Vanaf die pagina schrijf je ook direct je uren.

Planning is één kant. De andere kant is alles wat een bureau over zijn klanten moet weten: welke afspraken lopen er, hoeveel uren zijn er nog over, wat moet er deze maand gefactureerd worden. Daar zijn CRM- en boekhoudpakketten voor, maar die passen zelden precies op hoe jij werkt. In Drupal bouw je die laag zelf, en een groot deel heb je al:

• Een datamodel zonder code. Een klant is een inhoudstype met velden, zoals de tarieven per dienst en de gekoppelde borden in monday.com. Een veld erbij is een paar klikken.
• Gebruikers, rollen en rechten. Wie welke klant mag zien, wie mag factureren en wie alleen de cijfers mag lezen, regel je met rollen die Drupal al kent.
• Lijsten en formulieren. Overzichten met filters en sortering bouw je met Views, zonder zelf queries te schrijven.
• Configuratie in git. Elke wijziging aan velden en rechten gaat via een review naar productie, net als de code.
• Een vaste beveiligingsroutine. Drupal heeft een eigen securityteam, en onze Updater kijkt elk uur of Infra nog bij is.

Daarbovenop bouwden we wat geen pakket voor ons deed: afspraken in vier vormen (een maandabonnement met uren, uren voor een project, een vast product per maand of jaar en een eenmalig product), een urensaldo per klant, facturen als PDF, plus- en minuren en vakantie-uren per collega, cijfers per klant, collega en dienst, en een werkrapport dat we naar klanten sturen.

Velden en formulieren zijn het makkelijke deel. Een eerste versie van een CRM in Drupal staat snel. Het moeilijke deel zit in dingen die je pas tegenkomt als het systeem elke dag gebruikt wordt. Bij ons waren dat er vijf.

monday.com geeft een account 10.000 API-verzoeken per dag. Is dat op, dan werkt de hele koppeling niet meer tot middernacht: geen ticketpagina, en geen uren die terug naar monday.com gaan.

Wij kwamen er bijna aan door een reparatie. Een achtergrondtaak werd al een tijd afgeremd door monday.com, en een afgeremd verzoek telt maar voor een tiende. Toen we de taak repareerden, slaagden al die verzoeken ineens wel. Het verbruik ging in één nacht van zo'n 2.600 naar rond de 8.000 per dag, zonder dat er een nieuwe functie bij kwam.

De oplossing was een kopie van alle tickets in eigen tabellen. Infra vraagt elke tien minuten alleen op wat er veranderd is, bundelt tien borden in één verzoek en stopt na dertig verzoeken per ronde. De overzichten lezen die kopie in plaats van monday.com. Webhooks hebben we bewust niet gebruikt: die vragen een publiek adres en een webhook per bord, en monday.com garandeert niet dat elk bericht aankomt.

Het urensaldo van een klant stond eerst als getal bij de klant. Bij elke factuur gingen de gefactureerde uren eraf. Werd een maand opnieuw gefactureerd, dan gingen dezelfde uren er nog een keer af. Na een paar keer stond het saldo ver onder de werkelijkheid.

Nu slaan we het saldo nergens op. Infra berekent het elke keer opnieuw uit de geschreven uren: eerst gaan de uren van het abonnement op, daarna die van een extra urenpakket. Opnieuw rekenen geeft altijd hetzelfde antwoord, en er is geen knop "herbereken" die iemand kan vergeten.

Een agenda-onderdeel in de browser zette tijdzones ongemerkt om naar UTC. Daardoor kwamen uren soms een dag te vroeg in de administratie. Sindsdien rekent alleen de server met tijdzones; de browser werkt met een dag en het aantal minuten sinds middernacht.

Met geld is het net zo. Tarieven worden bij het factureren vastgezet op de factuur. Verander je later een tarief, een afspraak of het btw-percentage, dan blijft een bestaande factuur zoals hij was.

Drupal is vergevingsgezind, en dat is niet altijd fijn. Een paar voorbeelden die we tegenkwamen:

• Een aanpassing aan een formulier met een verkeerde formuliernaam doet niets. Geen fout, geen waarschuwing. Een downloadknop heeft zo nooit bestaan, terwijl de documentatie zei dat hij werkte.
• Een rol die een recht krijgt dat geen enkele module kent, raakt dat recht bij de volgende deploy kwijt, zonder dat iemand het merkt. Bij ons zagen collega's daardoor knoppen bij hun meldingen die bij een klik geweigerd werden.
• Ook de API van monday.com zwijgt graag. Een filter op een persoon zonder het juiste voorvoegsel geeft nul resultaten. Vraag je naar meer dan 25 borden zonder limiet, dan krijg je er 25.

Daarom draait Infra op tests: meer dan honderd testbestanden voor de PHP-code, en aparte tests voor de JavaScript van de planning. We schrijven een test zo dat hij faalt zonder de oplossing. Pas dan weet je dat hij iets bewaakt.

In een eigen systeem staan uren, tarieven en kostprijzen bij elkaar. Niet iedereen hoeft alles te zien. In Infra loopt elke controle op toegang via één plek, die bepaalt welke klanten iemand mag zien. Een analist leest de cijfers, maar kan geen afspraken wijzigen. En het werkrapport voor een klant bevat nooit bedragen of namen van collega's; een test controleert dat.

Een eigen systeem is niet voor iedereen. Past een standaard CRM of planningstool op hoe je werkt, gebruik die dan. Het wordt interessant als:

• je voor dezelfde mensen in meerdere tools betaalt en gegevens met de hand overzet;
• je werkwijze niet past in wat een pakket kan, en je daar elke week omheen werkt;
• je uren, afspraken en facturen in losse spreadsheets bijhoudt;
• je een tool als monday.com wilt houden, maar er iets naast nodig hebt dat die tool niet kan.

Dan bouwen we zoiets ook voor jou, in Drupal of Laravel, gekoppeld aan de tools die je al gebruikt. We beginnen klein, met het proces dat nu de meeste tijd kost, en bouwen van daaruit verder. Zo is Infra ook ontstaan. Mail ons en vertel waar je nu tegenaan loopt.