Brengo · own-product case study

One task connects the requester, provider and handover.

Brengo brings a local transport request, route, price, acceptance, status, chat and handover into one role-based application. This case explains the built workflow and the technical choices behind it.

Review the implementation evidenceExplore web application development

What has actually been built?

A browser and mobile application with requester and provider roles, task status, chat, route context, payment status and task-bound audio and video calls. Brengo is an OmniTechs product developed around a local Groningen pilot.

This is an own-product case, not a customer testimonial. Public and guest-accessible captures date from 13 September 2026; implementation diagrams explain protected flows. They do not establish current availability, adoption, revenue or delivery times.

From interface to system

Five components, with visible evidence and clear limits.

Public and guest-accessible screens were captured directly. Protected media and operating flows use source-based diagrams, keeping private conversations, tokens and accounts out of the public evidence.

Status
Local pilot · dated evidence
Ownership
OmniTechs own product
Region
Groningen
Evidence date
13 September 2026

01 · Product and roles

A visible product journey with a local pilot boundary

The captured Brengo homepage connects a local transport request, route context and handover. It names Groningen and labels example tasks as examples.

  • Separate entry points for requester and provider
  • Route, status and payment in one journey
  • Pilot scope; task availability is not guaranteed
Brengo homepage showing the Groningen pilot, example tasks and route context.
Actual capture of the locally published Brengo marketing site, 13 September 2026.

02 · API integration

The interface collects intent; the API enforces rules

The request flow has four steps: route, package, pricing and review. Versioned REST contracts under /api/v1 connect the client to Django. Route and place services and Stripe support the product workflow.

  • Django REST API defines the product boundary
  • Stripe status is mapped to Brengo payment status
  • Route and place data support the task
Guest-accessible Brengo request builder with Route, Package, Pricing and Review steps.
Actual capture of the guest-accessible request flow, 13 September 2026.

03 · WebSockets

Fast task updates, with HTTP as the recovery path

Django Channels and Redis fan out task, chat and status signals to permitted participants. Clients fetch current data when they open or reconnect; access is checked again for task events.

  • Task-bound socket channels
  • Refetch after reconnect or missed events
  • Audience checks before sensitive updates
Public explanation of Brengo task and payment statuses.
Actual capture of the public status and payment explanation; no personal data was used.

04 · Voice and video

LiveKit carries media; Brengo controls participation

The application requests task-bound room status. Django checks access and issues a temporary token. Web and native clients then connect to LiveKit. Invitations and call lifecycle events stay in the task timeline.

  • Temporary task-bound access
  • Media separate from ordinary application events
  • Web and native room sessions share the API boundary
Implementation diagram of Django authorization and LiveKit media between task participants.
Source-based implementation diagram of live_support, the LiveKit adapter and web/native room sessions; not a live call capture.

05 · Windows operations

A launcher for the managed operating path

The installer generates HoifietsOpsStart.exe as a clickable Windows launcher. It opens the supported PowerShell entry and Ops Control Center. The documented Start flow manages the marketing site, /app, Django, workers, beat, Telegram and local services; public smoke remains a separate acceptance step.

  • One operator entry point
  • Status and recovery actions in the Control Center
  • Separate checks for local listeners and public routes
Implementation diagram from the Windows launcher to the Ops Control Center and managed services.
Source-based architecture diagram, not current runtime status. The executable launches the controlled operating process.

Product boundary

A task is the shared source of context

The requester works through route, package, pricing and review. A provider sees the relevant task before accepting it. Once linked, both roles follow the same status, chat and handover steps.

The pilot scope is local transport in Groningen. Available tasks and service availability depend on the pilot; the case evidence is not an availability guarantee.

Technical choices

Fast updates need a recovery path

WebSocket events signal that the client should fetch current data. HTTP remains the authoritative status source when the application opens or reconnects, so a missed event need not leave the interface permanently stale.

Audio and video use a separate media path. Django checks task access and issues a temporary LiveKit token; LiveKit transports media. Invitations, answers and call lifecycle events remain part of the task timeline.

What the evidence supports

Built integrations, with a specific proof boundary

The implementation connects role-based clients, the Django API and external route, payment and media services. It includes a managed Windows launch path. This case does not claim a completed ERP or CRM integration.

A comparable project may need a different stack. Users, data, integrations, risk and operating responsibilities determine the scope. Any development price indication remains nonbinding until a written scope is accepted.

What should your first useful step achieve?

Describe the users, current process and the decision that needs to improve. We can assess a bounded next step.

Request an initial assessment