Concurrences: zero app-side issues in 2+ years of production

What we had to solve

• 01

  Building real-time chat without touching the client's application backend

  The app needed in-event attendee chat so delegates could connect once registered. The primary backend was PHP, owned and operated by the client's own developer. Adding endpoints or changing the data model required coordinating with the client's team — a dependency that would have slowed every future chat feature. The solution was to build the chat layer on Firebase, fully decoupled from the PHP backend. Chat worked without touching anything outside RaftLabs' scope, and future changes to the chat model don't require a backend deployment.

• 02

  A live-tweets feature that became expensive because of someone else's business decision

  Embedding live event tweets via the Twitter API was in the original specification and worked as intended. After a change in Twitter's ownership and API pricing, running a native integration became prohibitively expensive. The team removed the native Twitter API integration and replaced it with an in-app webview linking to the relevant Twitter pages. The feature's intent was preserved. The ongoing cost was eliminated. No lingering dependency remained.

• 03

  Offline caching with full control over what gets stored and when it expires

  Delegates need to revisit event details, session schedules, and speaker bios without a guaranteed connection — a realistic scenario for professionals traveling between sessions. Rather than use an external caching package, the team built the offline caching layer in-house. That decision cost more time upfront but gave complete control over what was cached, how long it was kept, and how it was invalidated when content changed. For content that updates on a schedule — agendas, speaker profiles — that control matters.

• 04

  Session identity that follows a user from native screens into website-backed sections

  Some sections of the app — user account management, certain registration flows — open the Concurrences website inside a webview. A user logged in to the native app expects to arrive at those sections already authenticated, without a second login prompt. This was solved with tokenized URLs: the native app generates a token encoding the user's identity and passes it as a parameter when launching any website-backed section. The Concurrences website validates the token and establishes the session. The user sees one continuous experience; the mechanism is explicit and auditable.

• 05

  Making desktop payment flows work inside a mobile webview

  Concurrences' event registration payments ran through infrastructure designed for a desktop browser — standard HTML forms, browser-level payment APIs, and JavaScript behaviors that don't all carry into Flutter's webview. Getting those flows to work inside the app required identifying every browser capability the payment flow depended on, determining which were unavailable inside the webview (Android is more restrictive than a desktop browser), and engineering specific workarounds for each one.

• 06

  A state management pattern that traded ongoing friction for code reusability

  The project used BLoC for state management, chosen by the lead developer to increase code reusability across screens. It delivered on that goal: logic that would otherwise be duplicated was written once and shared. The honest retrospective is more nuanced. BLoC's explicit event-state model requires developers to understand the pattern before they can contribute effectively, and debugging requires tracing events through the BLoC layer rather than following simpler state flows. The team would make that call differently today on a project of this scope — not because BLoC was wrong, but because the reusability benefit didn't clearly outweigh the friction it introduced over the project's lifetime.

• 01

  Flutter

  Concurrences needed iOS and Android from a single build within a 16-week window. Flutter was the right call: one codebase, platform-native performance, and built-in webview support for the sections that needed to open Concurrences website pages inside the app. The client's PHP backend was never touched — Flutter made it straightforward to build the mobile layer as a consumer of the existing API without any backend modifications. One architectural note worth disclosing: the project used BLoC for state management to improve code reusability across screens. It worked as intended, but introduced more ongoing friction than a simpler pattern would have. The team would make that call differently today on a project of this scope.

• 02

  Firebase

  The app needed real-time attendee chat and push notifications without modifying the client's PHP backend — infrastructure RaftLabs didn't own and couldn't change independently. Firebase solved both: Firestore for real-time messaging, FCM for push notifications, all running as a separate data layer the team controlled entirely. When the chat model needed to evolve, it changed in Firebase without a backend deployment. That independence was the point.