Skip to content
Terminales Docs

PDR 0001 — MVP go-live scope

Purpose: freeze what is IN and OUT of the production MVP so the Wave 3 backlog contains no speculative work and the go-live date has a bounded scope. This closes the §4.6 “Decisiones de PO pendientes” table of the Wave 2 analysis.

Context

Section titled “Context”

Wave 2 closed with an open PO-decision table (§4.6): eleven product calls, each with draft-ready candidates, that had to land before MVP scope could be declared final. Two were resolved into Wave 2 (held orders → W64, denominación → W65). The rest were “deferred to a potential wave 3.” Wave 3 is that wave, and the PO has now made the scope call.

Decision — VAS + Clientes are IN; the rest of §4.6 is deferred

Section titled “Decision — VAS + Clientes are IN; the rest of §4.6 is deferred”

In scope for the production MVP (build in Wave 3):

  • VAS / servicios financieros (W-09 + M-5) — the special-categories vertical: airtime/TAE, gift-card PINs, service/bill payment, and SIM chips, plus the legacy financial domains (deposits, transfers, wallet/merchant-balance) that back W44–W47. Migrated to the Appwrite POS model per value-added-services.md and TDR-0003. This also drives the Bucket-2 domains of the full migration. Phasing amendment (2026-07-11, PDR-0003): MVP ships Phase 1 connectivity only (single shared VB webService user); Phase 2 (per-merchant webService users) and Phase 3 (direct provider integration + certification) are post-MVP, as are bank-statement-import deposit validation and the wallet withdrawal/payout flow.
  • Clientes / Customers (BG-1; web W-13 231:3–233:383, mobile M30–M33, gaps #25/#42/#43/#45) — customer directory + sale linkage (sales_orders.customerId). Wallet/fiado stays parked; the customer role stays reserved (no self-service portal in MVP).

Deferred (post-MVP; kept in the §5 post-MVP catalog and the Wave 3 §5):

  • QR tenders CoDi/SPEI + CFDI receipt QR (BG-9; gaps #29/#39/#40) — the 5th tender and CFDI QR. Keep the payment-method enum and receipt schema additive/extensible so it lands later without a schema break.
  • Cobro rápido + UX v2 absorptions (gaps #28/#30/#31/#32/#44) — quick-charge modal, quick-actions FAB, PIN profile selector, low-stock KPI quick-filters.
  • POS interaction modes — tap-to-add / long-press details, fullscreen POS mode.
  • Dashboard KPI drill-down (W07; gap #8) — per-KPI destination wiring.

Rationale: the client needs the special-categories/financial vertical to operate their business day one (it is a core revenue surface, not a nice-to-have), and customer capture is a low-cost additive that several flows already anticipate. QR tenders, cobro-rápido, POS-interaction, and KPI drill-down are speed/UX enhancements or depend on external/CFDI tracks — deferring them does not stop the client operating live, and each has an additive seam so it lands cleanly later.

Alternatives rejected

Section titled “Alternatives rejected”
  • Verify-and-harden only (defer VAS + Clientes too) → rejected; VAS is a primary revenue surface the client needs at launch, so shipping without it is not a viable MVP for them.
  • All deferred modules in (also QR/cobro-rápido/POS-interaction/KPI) → rejected; that scope pushes the launch date out for enhancements the client can operate without.

Consequences

Section titled “Consequences”
  • Track C (VAS) and Track D (Clientes) become MVP-gating work in the Wave 3 backlog.
  • The VAS vertical discriminator is products.kind (enum [PHYSICAL, TAE_AIRTIME, GIFT_PIN, SERVICE_PAYMENT]), per value-added-services.md — this supersedes the tentative products.vertical name floated in Wave 2 §4.6.
  • The deferred items keep their §5 additive-readiness requirements (enum-extensible tender/receipt schemas, sales_orders.customerId optional, etc.).
  • MVP scope is now final — the Wave 3 backlog draws no work from outside this decision.

References

Section titled “References”