NevaBridge begon niet als product. Het begon als onze eigen pijn, duizenden vage bugreports, op een platform dat we zelf draaien. Dus bouwden we de laag die de juiste vragen stelt voordat een ticket ooit bij een developer terechtkomt.
Het team achter NevaBridge draait ook Calendall, een populair klantbeheer- en afsprakensysteem voor salons. Elke week kwamen er klantverzoeken binnen via e-mail, chat en support-tickets: vragen, feature-ideeën en bugreports. Elk daarvan moest gelezen, begrepen en naar de juiste plek doorgezet worden. En als het een bugreport was? Onze developers moesten bijna altijd terugvragen. Welke browser? Welk scherm? Wat heb je precies geklikt voordat het stopte?
De meldingen waren niet slecht. Ze waren gewoon onvolledig. En elke vervolgvraag kostte tijd, context en geduld aan beide kanten. We hebben het gemeten: 44% van alle bugreports had minstens één verduidelijkingsronde nodig voordat een developer überhaupt kon beginnen. Sommige hadden er drie of vier nodig.
We hebben gezocht naar een tool die dit probleem bij de bron oplost. Een workflow die de juiste vragen stelt voordat het ticket bij de developer terechtkomt. We hebben er geen gevonden.
Dus hebben we het zelf gebouwd. Wat begon als interne tool voor ons eigen supportteam, werd NevaBridge.
van alle bugreports had minstens één vervolgvraag nodig voordat een developer kon beginnen
langere tijd tot de eerste fix bij onvolledige meldingen
We zijn niet begonnen om een product te bouwen. We zijn begonnen om onze eigen pijn op te lossen. NevaBridge bestaat omdat niemand anders dit probleem voor teams zoals het onze had opgelost.
Ons foundersteam heeft het platform gebouwd en exploiteert het, waar we dit probleem voor het eerst zelf ervoeren. We hebben duizenden support-interacties afgehandeld, honderden bugreports zelf getriageerd en de pijn van vage tickets aan den lijve ondervonden. We hebben deze pijn niet in een marktrapport gelezen. We hebben hem wekenlang, jarenlang, geleefd.
Toen we met de bouw van NevaBridge begonnen, haalden we een CTO aan boord die hetzelfde patroon van de andere kant kende. Als senior software engineer bij AWS had hij jarenlang aan de ontvangende kant van onvolledige bugreports gestaan, zelfs binnen een bedrijf met enkele van de meest volwassen engineering-processen in de industrie. Het probleem was niet uniek voor ons. Het was structureel.
Die combinatie geeft NevaBridge zijn vorm. De ene kant van het team weet wat het betekent om een product te exploiteren, met klanten te praten en support te beschermen tegen de ruis. De andere kant weet wat een developer echt nodig heeft om met een issue te beginnen, en hoe duur het wordt als die informatie ontbreekt. Niet omdat terugvragen lang duurt, maar omdat elke vervolgvraag teruggestuurd wordt, uren of dagen op antwoord wacht, en de developer is tegen die tijd allang met iets anders bezig. NevaBridge ontstaat op het snijvlak van beide perspectieven.
exploitatie van een SaaS-platform met echte gebruikers en echte supportbelasting
ontwikkeling van enterprise software, van startups via de publieke sector tot een senior engineering-rol bij AWS.
We bouwen niet vanuit theorie. We bouwen vanuit duizenden echte gesprekken, echte tickets en echte frustratie aan beide kanten van de overdracht.
NevaBridge staat nog vroeg. We bouwen de eerste module: interne bugreporting. Een teamlid beschrijft een probleem in natuurlijke taal. NevaBridge analyseert wat er is, herkent wat ontbreekt, stelt gerichte vervolgvragen en maakt een gestructureerd, dev-ready ticket aan in jullie issue tracker.
Dit is geen generieke chatbot op een formulier geplakt. NevaBridge werkt op drie niveaus. Out of the box weet het al wat developers doorgaans in een bugreport nodig hebben, opgebouwd uit onze eigen ervaring met productontwikkeling, het werk met pilot-klanten en het analyseren van open-source issue trackers. Daarbovenop kun je het voeden met jullie eigen productdocumentatie en eerdere bugconversaties, zodat het jullie terminologie, jullie features en jullie bekende issues leert. En je kunt eigen report-templates aanmaken naast onze bewezen starter-template. NevaBridge kiest voor elk gesprek de juiste.
Die combinatie maakt van een vage zin een ticket waar een developer direct mee aan de slag kan, zonder één vervolgvraag.
We beginnen waar de pijn het scherpst is. Bugreports zijn de plek waar de kloof tussen wat mensen zeggen en wat developers nodig hebben het grootst is. Dit ene goed doen is de basis voor alles wat volgt.
We gebruiken het zelf, elke dag. En we zoeken teams die dezelfde pijn kennen.
module in productie, bewust strak afgebakend
vervolgvragen nodig wanneer NevaBridge het ticket schrijft
We leveren liever nu één module die een echt probleem oplost, dan teams te laten wachten tot alle drie klaar zijn.