Business or user problem

Make tyre catalog data available quickly and reliably on mobile devices, including when field usage requires offline access.

Technical constraints and architecture

  • Catalog data needed local persistence and sync-friendly behavior.
  • Remote configuration had to support controlled updates.
  • The app needed release parity across Android and iOS.
  • Implemented offline-first storage using SQFlite and a clear MVVM structure.
  • Used Serverpod and Remote Config integration to support dynamic catalog behavior.
  • Planned milestones around data access, offline behavior, QA, and store release readiness.

Role and ownership

  • Developed the Flutter app using Serverpod and MVVM.
  • Implemented offline-first catalog behavior with SQFlite.
  • Integrated Firebase Remote Config for dynamic updates.
  • Prepared delivery scope, sprint tasks, ETA communication, demos, and release follow-ups.

Delivery and client communication

Client context

  • Tyre-catalog product where mobile delivery had to align business catalog needs, offline behavior, platform release checks, and stakeholder review.

Discovery and requirements

  • Clarified product goals, users, and the mobile workflows that mattered most for offline catalog access.
  • Converted approved requirements into implementation scope, feature notes, and release checkpoints.

Project plan and milestones

  • Broke mobile delivery into milestones covering core flows, integrations, QA, store readiness, and post-release checks.
  • Kept scope visible so new feedback could be triaged without losing release focus.

Sprint planning approach

  • Supported sprint planning, feature sequencing, story estimation, and acceptance-criteria preparation.
  • Kept implementation tasks connected to API readiness, design states, and QA coverage.

Estimation and ETA communication

  • Prepared practical delivery estimates based on integration complexity, platform differences, and testing risk.
  • Communicated ETA changes when blockers, dependency shifts, or feedback affected the plan.

Stakeholder cadence

  • Shared progress, blockers, dependencies, and implementation decisions with stakeholders during delivery.
  • Used demos and review points to gather feedback before release-critical decisions became expensive.

Risks, blockers, and dependencies

  • Tracked API readiness, third-party SDK behavior, device differences, offline behavior, and app-store requirements.
  • Escalated blockers with context, impact, and proposed next actions.

Client feedback and follow-ups

  • Captured client feedback, meeting notes, action items, and next decisions after reviews.
  • Closed the loop on changes through implementation notes, QA handoff, and release follow-up.

Release responsibilities

  • Prepared release builds, store-facing checks, and post-release monitoring support where applicable.
  • Coordinated fixes and follow-up actions after QA, stakeholder review, or public release feedback.

Approved outcomes

  • Released public Android and iOS catalog apps.
  • Provided a field-friendly app experience with offline catalog access and controlled update paths.