Hoe je bugs bijhoudt zonder Jira

Bugs bijhouden is de oorspronkelijke reden waarom issue trackers bestaan. En het is precies de use case die Jira de afgelopen tien jaar onder een berg enterprise-features, custom workflows, permission schemes en screen configurations heeft begraven - niets waar het ontwikkelteam ooit om heeft gevraagd.

Als je weleens een halve ochtend kwijt bent geweest om een Jira-admin zover te krijgen één veld toe te voegen aan een bug-scherm, of een freelancer hebt zien zuchten bij wéér een login op wéér een log dashboard alleen om een regressie te melden: deze post is voor jou. Zo zet je een bugtracker neer die in minuten staat, minder per seat kost dan een kop koffie, en alles doet wat een werkend dev-team nodig heeft - zonder Jira.

Wat "een bug bijhouden" écht inhoudt

Haal het project-management-theater eraf en een echte bugtracker doet vijf dingen:

1. Snel een melding vastleggen, met genoeg context om hem te reproduceren.
2. Planning: prioriteit, severity, eigenaar, doel-release.
3. In één oogopslag laten zien wat openstaat, wat loopt en wat geblokkeerd is.
4. De fix terugkoppelen aan de code (commit, branch, PR, deploy).
5. Het gesprek op één plek houden zodat de volgende persoon niet hoeft na te vragen.

Dat is de hele lijst. Alles wat Jira er bovenop legt is optioneel, en het meeste kost je focus voordat het waarde oplevert.

Een bord dat past bij een bug-workflow

In Todo4you bepaalt elk project zijn eigen statussen onder Instellingen -> Statussen. Voor een bug-project zit een workflow als Gemeld -> Gepland -> Bezig -> In review -> Geverifieerd -> Gesloten binnen een minuut klaar. Elke status hoort bij een categorie (backlog, todo, active, review, done) en de rest van het systeem, inclusief rapportages en automatiseringen, draait op de categorie - niet op hardcoded namen. Zo splits je In review in Code review en QA, of voeg je een Niet reproduceerbaar-kolom toe, zonder dat er iets breekt.

Het bord komt met wat je verwacht: drag and drop met live updates, lijstweergave, kalenderweergave, kolommen verbergen of minimaliseren per gebruiker, en een dark mode die in beide thema's gewoon werkt. Geen screen schemes, geen workflow conditions, geen admin-rol nodig.

Meldingen vastleggen zonder gedoe

De grootste belasting van Jira is het moment waarop je een niet-developer vraagt een bug in te dienen. Todo4you heeft meerdere manieren om meldingen te vangen waarbij de melder geen kanban-bord hoeft te openen:

• Inkomende e-mail. Elk project heeft een eigen inbox-adres. Mail erheen wordt een ticket, met het onderwerp als titel, de body als beschrijving en bijlagen plus inline-afbeeldingen netjes mee. Reageer op het ticket en de melder krijgt het antwoord per mail terug. Forward een klantklacht en je hebt een ticket zonder je inbox te verlaten.
• De MCP-server. Werk je in Claude, Cursor of een andere MCP-aware assistent, dan kun je zeggen: "Maak een ticket in WEB: titel 'Afrekenknop loopt vast op Safari iOS', zet de beschrijving van wat ik net vertelde, tag het ios en bug, wijs het aan mij toe." Geen tabwissel.
• Koppelingen. Koppel je Todo4you aan bijvoorbeeld Slack of Homey, dan is het mogelijk om vanuit daar een ticket te maken.
• De REST API. Alles wat de UI doet is bereikbaar onder /api/v1/*. Koppel je eigen crash-reporter, supportformulier of status-pagina aan POST /api/v1/tickets en bugs melden zichzelf.

Elk ticket draagt de velden die je nodig hebt: een stabiele referentie zoals WEB-42, een markdown-beschrijving, een checklist voor reproductiestappen, blockers, tags, assignees, prioriteit, deadline, tijdinschatting, en bijlagen. Afbeeldingen renderen inline in reacties, en er zit een ingebouwde annotatietool in om de stukke plek op een screenshot te omcirkelen - wat een bugmelding meestal nodig heeft.

Plannen zonder permission scheme

Severity, area en klantimpact zijn gewoon tags. Tags zijn per project, gekleurd, en je filtert elke weergave op elke combinatie. Een handige startset: bug, regressie, critical, klant-gemeld, plus een area-tag per onderdeel van de codebase (auth, billing, mobile). Tag-filters combineren met assignee- en status-filters op elke weergave, dus "alle open critical bugs aan mij toegewezen" is twee klikken.

Voor terugkerend plan-werk zijn er Flows, en die lezen als zinnen: Als een ticket wordt aangemaakt, mits het tag critical heeft, dan wijs het toe aan de on-call engineer, zet prioriteit op Hoog en plaats een reactie. Triggers omvatten ticket aangemaakt, verplaatst, bijgewerkt, verwijderd, toewijzingen, reacties en checklist-wijzigingen. Condities combineren met ALL, ANY en NOT. Je hebt geen Jira-admin nodig om een Flow aan te passen - de projecteigenaar bewerkt hem in een formulier.

Blockers zijn een eersteklas veld. Markeer bug A als geblokkeerd door bug B en A staat met een rode streep op het bord tot B in een done-categorie valt. Handig voor de "we kunnen dit niet fixen tot het API-team hun fix uitlevert"-situatie die Jira met een verwarrend is blocked by-linktype probeert weer te geven.

De loop sluiten met Git

Koppel GitHub, GitLab, Gitea, Bitbucket of Forgejo eenmalig aan je project en het bord regelt de rest. Verwijs met WEB-42 of #42 in een commitbericht, branchnaam of PR-titel en:

• De commit verschijnt in de Git-activiteit-sectie van het ticket met een link.
• De branch wordt automatisch gekoppeld.
• PR opened, closed, merged en reviewed-events landen allemaal op het ticket.
• Auto-move regels vuren op de events die jij kiest: bij eerste commit verplaats naar Bezig; bij PR geopend verplaats naar In review; bij PR merged verplaats naar Geverifieerd.

Auto-moves gaan door dezelfde pipeline als een handmatige verplaatsing, dus Flows en uitgaande webhooks vuren precies alsof een mens de kaart had versleept. De geschiedenis van een bug leest als een tijdlijn: gemeld, getriaged, branch gepusht, PR geopend, gereviewed, gemerged, geverifieerd - zonder dat iemand een statusupdate typt.

Rapportages die de vragen van een manager beantwoorden

Projectrapportages tonen bug-aantallen per statuscategorie, per tag, per assignee, per prioriteit en per dag van de week. Tijdregistraties rollen op dezelfde manier op, dus "hoe lang stonden de laatste tien critical bugs te wachten voor we ze oppakten" en "hoeveel tijd zijn we deze maand kwijt geweest aan regressie-werk" zijn beide twee klikken. CSV-export als finance erom vraagt.

Wil je dezelfde weergave over meerdere projecten? De Alle borden-weergave toont elk actief ticket uit elk project waar je toegang toe hebt, met dezelfde filters als een enkel bord.

Realtime, zonder F5

Updates komen live binnen via Pusher op kanalen per project. Verplaats een ticket op je laptop en het scherm van je collega ververst zonder refresh. Reacties komen aan zonder polling. Timer-status synchroniseert tussen apparaten. Het tabblad dat je 's ochtends openliet, klopt nog steeds als je om 17:00 terugkomt.

Webhooks naar buiten, MCP voor AI, API voor de rest

Het ecosysteem werkt twee kanten op:

• Uitgaande webhooks onder Projectinstellingen -> Webhooks sturen ondertekende POST-requests voor ticket.created, ticket.moved, comment.added, timer.started en de rest. Koppel je alerting, dashboards of Slack/Teams-kanalen zoals je wil.
• De MCP-server laat je AI-assistent direct tickets lezen en schrijven. Standaard alleen-lezen; je kiest bij het aanmaken van een token expliciet voor schrijfrechten, en je kunt het scopen naar één project.
• Een echte REST API onder /api/v1/* met bearer-tokens uit je profiel. Postman-collectie staat op de developers-pagina.

Dezelfde drie dingen waar Jira per app voor laat betalen, op elk plan beschikbaar.

Mobiel, want bugs wachten niet

Er zijn volwaardige iOS-, macOS- en Android-apps. Plan vanaf je telefoon, start een timer als je achter je bureau gaat zitten, hang een screenshot aan vanaf het apparaat dat de bug raakte. Dezelfde data, dezelfde realtime updates, dezelfde meldingen. Push-notificaties komen rechtstreeks via APNs en FCM, niet via een derde partij.

De ontsnappingsroute

De belangrijkste vraag voor je een tool adopteert: hoe loop ik weer weg? Onder Projectinstellingen -> Export krijg je elk ticket, elke reactie, elke bijlage, elke tijdregistratie en elke flow als JSON. Jouw data is van jou. De Flows die je bouwt, de integraties die je koppelt, de API-tokens die je aanmaakt - allemaal van jou. Stop wanneer je wil en loop met alles naar buiten.

Een migratieplan, in vijf stappen

Als je een bestaande bugtracker naar Todo4you verhuist, werkt dit:

1. Eén project per repository of productdomein - niet één groot project voor alles. Bug-projecten blijven werkbaar als ze mappen op iets dat je kunt bouwen en uitleveren.
2. Schrijf eerst je statussen op. Gemeld -> Gepland -> Bezig -> In review -> Geverifieerd -> Gesloten is een prima default. Pas aan op je werkelijkheid.
3. Definieer je tags. Severity (critical, major, minor), bron (klant, intern, regressie) en area (auth, billing, mobile). Houd het onder de vijftien tags - meer en mensen gebruiken ze niet meer.
4. Koppel de integraties. Verbind je Git-provider, zet auto-move regels op, koppel Slack of Teams voor meldingen, en zet inkomende e-mail aan zodat support bugs kan doorsturen.
5. Importeer alleen openstaande bugs. Importeer geen tien jaar gesloten Jira-issues. Die blijven liggen stoffen. Exporteer uit Jira, importeer de openstaande set via de API en archiveer de rest in koude opslag.

Een klein team kan in dezelfde middag overstappen van Jira naar Todo4you en weer bugs aan het tracken zijn.

Probeer het op je eigen bugs

Meld je aan op todo4you.nl en start een project. Stuur je volgende bugmelding door naar het inbox-adres van je project. Koppel je Git-provider. Kijk hoe de loop zichzelf sluit. Vragen, feature-wensen, bug-meldingen over de bugtracker - info@todo4you.nl komt in mijn inbox.