Skip to content

RELEASE PLAN — PHASE 1

VietGara — Backend (Go) + Owner Web and Admin Web (React/TS)

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

Items this plan defers move accordingly:

  • automatic renewal and subscription payment (FR-LIC-03, FR-PAY-03): Phase 16;
  • insurance claim integration (FR-INS): Phase 17;
  • the receivables model and its Excel export: Release 13.0 (Phase 13), until then served by Billing & Settlement;
  • Optional MFA: Release 6.1 (Phase 6), offered by the Admin App from Release 2.1.

The garage owner’s app (vietgara-owner-app) carries the owner side of Releases 1.0–1.5 and is released in Release 2.0.

1. Introduction

This document breaks down the Phase 1 (MVP) scope — finalized in Vision & Scope Section 3.1, covering Backend (Go) + Owner Web (React/TS), not including the Mobile App — into 6 consecutive releases, sequenced according to business and technical dependencies. Each release is a deployable, demoable increment, not merely a partially completed slice of the overall system.

Sequencing principles: (1) the identity/multi-tenancy foundation must exist before any other feature; (2) a feature that is a data prerequisite for a later feature must be built first (e.g. Customer & Vehicle must precede Quote); (3) each release ends with one complete business flow that has demo value for stakeholders, rather than stopping mid-flow.

2. Overview of the 6 Releases

ReleaseNameMain ModulesDemoable Value
1.0Foundation & IdentityIdentity & Access, Tenant/Garage ManagementRegister and verify a user, create garages, invite staff, define roles and groups
1.1Subscription Plans & CustomersLicense Management, Customer & VehicleA verified owner gets a trial subscription with plan limits; customers/vehicles/partners can be added
1.2QuotesQuote & Pricing, vehicle historyCreate a quote, send an approval link to the customer, convert to a repair order; vehicle repair history (FR-CUS-03); daily transaction limits enforced
1.3Repair & InventoryRepair Order, InventoryRepair order Kanban board, automatic stock deduction when an order closes
1.4Settlement & DocumentsBilling & Settlement, Document/PrintSettlement, PDF/Excel export
1.5Reporting & PolishReporting, Notification (email)Revenue dashboard and e-mail notifications; tracing. Hardening (rate limiting, security review, load test, Terraform) moved to Phases 8 and 9, MFA to Release 6.1

3. Release Details

Release 1.0 — Foundation & Identity

This is the “walking skeleton”: not feature-rich, but must run end-to-end for real (CI/CD, DB, Auth) — every subsequent release builds on this foundation.

  • Backend: initialize the vietgara-backend monorepo following the Modular Monolith structure (ADR-001); migrations for users, garages, staff, roles, staff groups and invitations with RLS enforced through a non-bypass application role; Identity (register/login with e-mail or Google, e-mail verification and password reset by 2-minute e-mail OTP, JWT + rotating refresh tokens, Vietnamese/English preference); Tenant/Garage (garages with Active/Inactive status and configuration, logo upload, staff invitations to existing users, owner-defined roles assigned through staff groups, default roles). REST is served by grpc-gateway from the vietgara-proto contracts; e-mail goes through Mailpit locally and Mailjet in staging/production.
  • Frontend: initialize vietgara-owner-web; root layout (sidebar, header, garage selector, language switcher); sign-in, sign-up, e-mail verification and password reset; garages and garage settings; staff, invitations, roles and groups screens. Server state with TanStack Query; Vietnamese/English with react-i18next; API types generated from the OpenAPI document.
  • Infrastructure: CI pipelines for the backend (build, lint, unit tests with a 90% coverage gate, integration tests), owner web (format, lint, typecheck, tests, build, image) and proto (lint, format, generated code, breaking changes).
  • Definition of Done: a real user can register, verify their e-mail, create 2 garages, invite an existing user which accepts from its e-mail, restrict it with a custom role, and switch language — entirely through the real UI, with data persisted in Cloud SQL (dev environment).

Release 1.1 — Subscription Plans & Customers

  • Backend: License (plans with price and limits on garages, staff and transactions per day; one subscription per owner, 14-day trial on e-mail verification; entitlement cache; read-only/suspended enforcement; platform-admin plan management and manual extension); Customer & Vehicle (customers with personal-data consent, vehicles, partners); domain events through the outbox to Kafka (ADR-004); append-only audit log.
  • Frontend: Subscription screen (plan, usage against limits, plan change) and license banners in the owner web; Customer, Vehicle and Partner screens; the platform-admin plans and subscriptions screens, which now live in their own app, vietgara-admin-web.
  • Dependency: requires Release 1.0 (garage_id, RLS, auth) to be ready.
  • Definition of Done: verifying an owner creates a trial; creating a garage or inviting staff beyond the plan limit is refused with a clear message; an admin changes a plan’s limits and the owner sees them; customers, vehicles and partners can be managed; events reach Kafka and are processed once.
  • Moved out: automatic renewal and subscription payment (FR-LIC-03, FR-PAY-03) → Release 16.0 (Payments, Phase 16); vehicle repair history (FR-CUS-03) → Release 1.2.

Release 1.2 — Quotes

  • Backend: Quote & Pricing Service (create, send, customer approval via a public link with no app login required, conversion into a draft repair order); quote numbering from the garage template (FR-TEN-05); daily transaction limit per plan counted on quote/repair order/settlement creation; vehicle repair history (FR-CUS-03).
  • Frontend: quote creation screen (dynamic table for adding/removing line items), a public page for viewing/approving a quote (no login, uses a token link).
  • Dependency: requires Customer & Vehicle (Release 1.1) to select a customer/vehicle when creating a quote.
  • Definition of Done: create a quote → send it → the customer clicks the link outside the browser and approves it → the status updates in real time on Owner Web.

Release 1.3 — Repair & Inventory

  • Backend: Repair Order Service (create from a quote, assign technicians, update progress via the Web); Inventory Service (stock in/out/on-hand); Event Design: repair_order.closed → automatically deducts stock via the Outbox Pattern.
  • Frontend: Repair Order Kanban board (drag-and-drop status changes); Inventory screen (stock receipt, stock on hand, alerts).
  • Dependency: requires an approved Quote (Release 1.2) to convert into a repair order.
  • Definition of Done: closing a repair order that used parts → stock on hand automatically decreases by the correct quantity with no manual step.

Release 1.4 — Settlement & Documents

  • Backend: Billing & Settlement Service (create a settlement from a closed repair order, allocate customer/insurer payment — insurance data is recorded only, no real claim integration; the split was removed in Release 5.0 and insurance returns in Phase 17); Document/Print Service (quote/repair order/receipt PDF, stock in/out/on-hand Excel report).
  • Frontend: settlement screen; PDF/Excel export buttons on relevant screens.
  • Dependency: requires a closed Repair Order (Release 1.3).
  • Definition of Done: close a repair order → create a settlement → export a valid receipt PDF.

Release 1.5 — Reporting, Notification & MVP Polish

  • Backend: Reporting Service (revenue by period — reads aggregated data from earlier services); Notification Service (email channel only for Phase 1: registration confirmation, license renewal reminders).
  • Frontend: overview Dashboard (KPIs + revenue chart).
  • Hardening: OpenTelemetry tracing (NFR-OB-01) is delivered. Load testing per NFR-PF-06, the security review, the Compliance Checklist, Kong rate limiting moved to Phase 8, and the load test and Terraform for the GCP environments to Phase 9; optional MFA (NFR-SE-04) moved to Release 6.1.
  • Definition of Done: the entire Quote → Repair → Inventory → Settlement → Dashboard flow runs on the Compose staging. The 50-garage scale test moved to Release 9.0; a limited launch before Phase 9 is by invitation only.

4. Inter-Release Dependency Diagram

flowchart TD
  R10["Release 1.0<br/>Identity + Tenant/Garage"] --> R11["Release 1.1<br/>License + Customer & Vehicle"]
  R11 --> R12["Release 1.2<br/>Quote + vehicle history"]
  R12 --> R13["Release 1.3<br/>Repair Order + Inventory"]
  R13 --> R14["Release 1.4<br/>Billing & Settlement + Document/Print"]
  R14 --> R15["Release 1.5<br/>Reporting + Notification + Hardening"]
  R15 --> GL(["MVP go-live"])

Note: within each release, the backend and frontend of the same module can be developed in parallel (the frontend uses a mock API based on the API Specification while waiting for the backend), as long as the API contract has been agreed upon at the start of the release.