Skip to content

RELEASE PLAN — PHASE 2

VietGara — Mobile Apps

Version 2.1 — October 9, 2026 · Cloud: Google Cloud Platform (GCP) · Backend: Go

In-app payment and e-invoices in the Customer App (FR-CAPP-04) follow the payment gateway and e-invoicing into Phase 16.

Other changes to this phase: the owner app’s “split with an insurer” (FR-OAPP-03) disappears in Release 5.0, when insurance leaves the product until Phase 17. The built apps receive compatibility updates in later phases: the rename account → user (Phase 3), the link-request screen in the customer app (Release 5.1), the plan payment request in the owner app and the payment review queue with the platform payment details in the admin app (Release 5.2), MFA screens in the owner, admin and technician apps (Release 6.1; the customer app signs in with Google only), stock count and barcode scanning in the owner app (Phase 7), and booking in the customer app (Phase 12); the technician app keeps seeing base-unit quantities (Release 6.0). Store listings wait for Phase 9.

1. Introduction

Phase 2 (per Vision & Scope Section 3.2) puts VietGara on the phone for every audience:

RepoAudienceStatus at the start of Phase 2
vietgara-owner-appGarage ownersBuilt ahead of this phase: the Phase 1 owner features (Releases 1.0–1.5), maintained on master
vietgara-admin-appVietGara platform administratorsNew repo, initialized in Release 2.1
vietgara-technician-appTechnicians (offline-first)Repo exists, empty; its core and offline sync are in Phase 11
vietgara-customer-appEnd customers (vehicle owners)Repo exists, empty; its core is in Phase 11

All four are Flutter apps that follow the same feature-first structure (Coding Standards Section 4.1). Their store identifiers follow com.viettechno.vietgara.<app>: .owner, .admin, .customer, .technician (Coding Standards Section 4.2a). The owner and admin apps call the existing REST API (/api/v1) directly. They are the mobile companions of vietgara-owner-web and vietgara-admin-web, and need no new backend. The technician and customer apps get a dedicated BFF each, because their needs differ from the web consoles: offline sync, and phone-based customer identity. The phase ends with the real-time and push infrastructure that all four apps use.

2. Overview of the 4 Releases

ReleaseNameMain ModulesDemoable Value
2.0Owner Appvietgara-owner-app, store distributionAn owner runs the garage from the phone: dashboard, quotes, repair orders, receivables, PDFs
2.1Admin Appvietgara-admin-appA platform admin checks plans and subscriptions and extends one from the phone
2.2Technician App Foundationvietgara-technician-app scaffold, Technician BFFLog in, see today’s assigned repair orders on the phone
2.4Customer App Foundationvietgara-customer-app scaffold, Customer BFF, phone/OTP and Google authLog in, see vehicles and their repair history

3. Release Details

Release 2.0 — Owner App

  • App: the Phase 1 owner features are already implemented in vietgara-owner-app, with one commit per Phase 1 release (see its README):
    • sign-in and e-mail verification, garage switcher, invitations;
    • subscription and license banner, customers and vehicles;
    • quotes: send, record decisions, convert;
    • repair orders: line progress, technicians, close; inventory and stock receipt;
    • receivables and payments; shared quote, repair order and receipt PDFs;
    • dashboard.
  • This release makes it shippable:
    • app icons, splash screen and store listing;
    • signing and build jobs in CI;
    • crash reporting;
    • internal distribution (TestFlight / Google Play Internal Testing), then the public listing.
  • Backend: none. The app uses the same REST API as vietgara-owner-web. Setup and data entry stay on the web: garage settings, invitations, roles, suppliers, creating quotes and repair orders, and the item catalogue.
  • Dependency: Phase 1 complete.
  • Definition of Done: on a real device installed from internal testing, an owner does the following against staging:
    • signs in and switches garage;
    • sends a quote and records the customer’s decision;
    • completes and closes the resulting repair order;
    • records a payment and shares the receipt PDF;
    • sees the change on the dashboard.

Release 2.1 — Admin App

  • Initialize the vietgara-admin-app repo (Flutter, same structure and CI as the owner app). It is the mobile companion of vietgara-admin-web, for VietGara’s own operators only.
  • Features:
    • sign in with e-mail and password, with the optional MFA once NFR-SE-04 ships (Release 6.1); users that are not platform admins see an access-denied screen;
    • plans list and plan edit (FR-LIC-05);
    • subscriptions list with search, and manual extension.
  • The payment review queue and the platform payment details of Release 5.2 (FR-LIC-08, FR-LIC-10) and the platform dashboards of Release 12.4 are added to this app in those releases.
  • Backend: none new. It reuses the /api/v1/admin/... endpoints.
  • Dependency: Phase 1 (FR-LIC-05, the /admin API).
  • Definition of Done: a platform admin extends a trial subscription from the phone, and the owner sees the new end date in the owner app and the owner web. A non-admin user cannot get past the sign-in screen.

Release 2.2 — Technician App Foundation

  • Initialize the vietgara-technician-app repo (Flutter, feature-first structure per Coding Standards Section 4.1).
  • Backend: Technician BFF. This is a dedicated, consolidated API for the app, so the app does not call many services directly.
  • Features: login, today’s repair order list (FR-TAPP-01), and a sync indicator (online/offline), per UI Design Spec Section 5.1.
  • Definition of Done: a technician logs in and sees the correct list of assigned orders, on a real device (Android/iOS) via an internal build (TestFlight/Internal Testing).

Release 2.4 — Customer App Foundation

  • Initialize the vietgara-customer-app repo (Flutter).
  • Backend: Customer BFF.
  • Features:
    • login with phone/OTP or Google (FR-CAPP-01). The login OTP is delivered by a managed phone-verification service (e.g. Firebase Authentication), chosen in this release. The SMS/Zalo notification channel is a separate Phase 16 item.
    • vehicle list and history (FR-CAPP-02).
  • Definition of Done: a customer who already has a profile at a garage (created by a Service Advisor on the owner web) logs in with the matching phone number and sees the correct vehicles and their history.
  • Status (October 2026, Release 5.1): a customer’s records are the garages’ profiles linked to the user. A profile carrying the user’s verified e-mail is linked at the first call unless it has ever had a link with that user; garages can send link requests that the user accepts or declines in the app (FR-CAPP-05, GET /me/garage-links). Phone matching waits for phone sign-in below.
  • Status (October 2026): the foundation ships Google sign-in only. A customer’s records are matched by the Google account’s verified e-mail, not yet by phone number. Phone/OTP login, and choosing its verification service, remain open within this release.

4. Dependency Diagram

flowchart TD
  P1(["Phase 1 complete"]) --> R20["Release 2.0<br/>Owner App"]
  P1 --> R21["Release 2.1<br/>Admin App"]
  P1 --> R22["Release 2.2<br/>Technician App foundation"]
  P1 --> R24["Release 2.4<br/>Customer App foundation"]
  R20 --> DONE(["Phase 2 complete"])
  R21 --> DONE
  R22 --> DONE
  R24 --> DONE

Release 2.0 and 2.1 only package and extend the existing API, so they ship first. The Technician App foundation (2.2) and the Customer App foundation (2.4) are independent of each other. Releases 2.3, 2.5 and 2.6 of the earlier plan are now Phase 11, after the backend foundations they depend on.