Case study · live pilot · eigen product
Brengo verbindt aanvragers en providers rond dezelfde taak: aanvragen, route en prijs beoordelen, accepteren, status volgen, chatten en de overdracht afronden. Hier laten we het zichtbare product én de onderliggende technische keuzes zien.
Een browser- en mobiele applicatie met aparte rollen voor aanvragers en providers, taakstatus, chat, routecontext, betaalstatus en taakgebonden audio- en videogesprekken. Brengo draait als een eigen product van OmniTechs binnen een Groningen-pilot.
Dit is geen klantcase en we publiceren geen adoptie-, omzet- of bezorgtijdclaim. De beelden tonen publieke of gasttoegankelijke schermen; beschermde gesprekken en persoonsgegevens blijven buiten beeld.
Van scherm naar systeem
Publieke en gasttoegankelijke schermen zijn rechtstreeks vastgelegd. Beschermde media- en beheerflows tonen we als brongebaseerd implementatieschema, zodat geen privégesprek, token, account of operationeel detail op de openbare site belandt.
01 · Product en rollen
De Brengo-site maakt het proces zichtbaar: een lokale transporttaak plaatsen, de routecontext volgen en de overdracht bevestigen. De interface noemt Groningen expliciet en presenteert voorbeeldtaken als voorbeelden.
02 · API-koppelingen
De aanvraagflow is in vier stappen opgebouwd: route, pakket, prijs en beoordeling. De webclient gebruikt versieerbare REST-contracten onder /api/v1. De backend koppelt productlogica aan onder meer route-/plaatsendiensten en de Stripe-betaalflow, zonder die providerregels in de interface te verspreiden.
03 · WebSockets
Django Channels en Redis fan-out geven taak-, chat- en statuswijzigingen door aan toegestane deelnemers. De payload is bewust een signaal om actuele gegevens opnieuw op te halen. Bij openen en reconnect refetcht de client de autoritatieve HTTP-status; rechten worden bij taak-events opnieuw gecontroleerd.
04 · Video en spraak
Voor een taakgesprek vraagt de app eerst de taakgebonden roomstatus op. Django controleert toegang en verstrekt een tijdelijke token. De web- en native clients verbinden daarna met LiveKit voor audio en video. Gespreksuitnodigingen en lifecycle-events blijven zichtbaar in de Brengo-taaktijdlijn.
05 · Beheer met de .exe
HoifietsOpsStart.exe wordt door het installatieproces gegenereerd als klikbare Windows-launcher. Die start de vastgelegde PowerShell-ingang en opent het Ops Control Center. De root Start-flow publiceert en controleert de marketingwebsite, /app, Django API, workers, beat, Telegram en benodigde lokale diensten; een aparte smoke-check controleert lokale listeners en publieke routes.
Productbeslissing
De aanvrager beschrijft wat verplaatst moet worden en doorloopt route, pakket, prijs en beoordeling. Een provider ziet de relevante taakcontext voordat die accepteert. Na koppeling werken beide rollen vanuit dezelfde taakstatus, chat en overdrachtsstappen.
De huidige productgrens is bewust lokaal: Brengo is een live pilot voor transportoverdrachten in Groningen. Beschikbaarheid van taken hangt af van de pilot en actieve vraag.
Waarom deze architectuur
WebSockets versnellen zichtbare updates, maar zijn niet de enige waarheid. De clients halen bij openen of opnieuw verbinden de actuele taak via HTTP op. Daardoor hoeft een gemist socketbericht tijdens een storing de interface niet blijvend verouderd te maken.
Spraak en video zijn gescheiden van gewone applicatie-events. Django controleert taaktoegang en geeft een tijdelijke LiveKit-token uit; LiveKit vervoert de mediastromen. Uitnodigen, beantwoorden en beëindigen blijven onderdeel van de taaklifecycle en tijdlijn.
Wat deze case bewijst
De case toont dat OmniTechs een rolgebaseerde webapp, realtime status, mediagesprekken, externe API-diensten en een beheerd Windows-startpad als één samenhangend product kan bouwen.
Een vergelijkbaar project begint niet automatisch met dezelfde stack. Gebruikers, gegevens, integraties, risico en beheer bepalen welke onderdelen echt nodig zijn. De prijsindicatie op de webapplicatiepagina is daarom een niet-bindend startpunt; een geaccepteerde scope blijft leidend.
Laat zien wie welke stap uitvoert, welke systemen al bestaan en waar status of overdracht nu misgaat. Dan bepalen we de kleinste verantwoorde eerste slice.
