# SmartShop — From FYP to a commercial pilot Assessment date: 2026-10-11 Internal assessment of BEMRIX's academic portfolio project. Based on a targeted source review and the existing local restoration record. No commercial implementation, penetration test, live payment test or client engagement is claimed. ## Executive recommendation Preserve the four role experiences and validate the business model first. Modernize the backend in bounded stages, starting with identity and order ownership. Decide whether to retain or replace backend modules after a focused technical spike; avoid committing to a complete rewrite before that evidence exists. ## Planning assumptions - A proposed first pilot serves one agreed region, one currency and a small, invited seller group. These are planning assumptions, not agreed business requirements. - Customer, seller, delivery and administrator roles remain distinct. Android and iOS targets, device coverage and whether a customer web app is required are still decisions. - No existing production orders, paying customers, traffic baseline, service-level agreement or operating budget was established in this review. - Payment-provider eligibility, settlement model, delivery coverage, seller onboarding, returns and support ownership must be agreed before selecting integrations. - Source includes inherited eShop/WRTeam and package references. Confirm applicable commercial-use and redistribution rights before a commercial release; this assessment is not a legal determination. ## Findings and acceptance criteria Priority: P0 = required before a public pilot. P1 = required for the agreed supported release scope. All implementation items below are proposed. ### F01 / P0 — Identity before exposure **Observed:** The reviewed Flutter helpers sign bearer tokens in the client. Sampled API token verification checks a shared-client issuer; seller and delivery order handlers take actor identifiers from request data. **Implication:** Shared-client validation does not by itself establish the signed-in person's access to a particular order or seller account. This is a design concern from the sampled code, not a claim that every endpoint was tested. **Proposed action:** Replace shared-client signing with server-issued user sessions; enforce account, role and resource ownership on every protected request. Review administrator permissions and session controls separately. **Acceptance gate:** Automated negative tests reject cross-account order reads and writes, unassigned courier actions and unauthorized admin operations; expired and revoked sessions are rejected. **Proposed owner:** Backend lead + QA **Evidence:** E02, E03 Reference: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html ### F02 / P0 — Separate preview from a release **Observed:** The restoration guide defines explicit portfolio mode, fictional identities and a local backend. App endpoint configuration retains local-network defaults; external services are disabled in preview. **Implication:** A successful screenshot build is not a release configuration or an end-to-end commerce test. **Proposed action:** Create separate preview, staging and release configurations. Fail release builds when demo mode, local HTTP endpoints or missing required configuration are detected. Keep credentials server-side where appropriate. **Acceptance gate:** Release checks reject demo and local-only configuration; a clean staging install uses approved endpoints and no seeded demo identity. **Proposed owner:** Mobile lead + release owner **Evidence:** E01, E04 ### F03 / P1 — Replace retired product-link infrastructure **Observed:** The customer app declares firebase_dynamic_links and calls its link listener and short-link builder. Google lists August 25, 2025 as the service shutdown date. **Implication:** These product-sharing and link-opening paths need a replacement before they can be included in a supported release. **Proposed action:** Use links on an owned domain with verified Android App Links / iOS Universal Links and a web fallback. Add a provider only if deferred-install attribution is actually required. **Acceptance gate:** A product link opens the correct item on installed-app cold and warm starts and reaches a useful fallback without the app; deleted products fail gracefully. **Proposed owner:** Mobile lead + web lead **Evidence:** E05 Reference: https://firebase.google.com/support/dynamic-links-faq ### F04 / P0 — Prove the money and order lifecycle **Observed:** Payment dependencies and order-management surfaces exist. The restoration record explicitly excludes end-to-end payments, shipping and delivery completion from its validation. **Implication:** Integration presence is not evidence that payments, refunds, stock changes and seller reconciliation agree under retries or failures. **Proposed action:** Select one suitable payment route for the pilot. Test server-confirmed payments, duplicate callbacks, cancellation, refund reconciliation, stock races and delivery exceptions. Keep money state separate from fulfillment state. **Acceptance gate:** Sandbox evidence covers successful, failed and repeated events without duplicate orders or stock decrements; refunds and settlement records reconcile. Any cash-on-delivery path has an explicit collection/reconciliation process. **Proposed owner:** Backend lead + operations + QA **Evidence:** E01, E06 Reference: https://docs.stripe.com/webhooks ### F05 / P1 — Plan the maintenance path **Observed:** The repository identifies CodeIgniter 3.1.13. Flutter dependencies include a local vendored payment package; the restoration guide records compatibility fixes and remaining analysis warnings. **Implication:** The team needs evidence about maintainability and platform support before estimating a commercial delivery plan. Version age alone is not a vulnerability finding. **Proposed action:** Inventory dependencies and notices, review supported runtimes, run analysis and platform builds, then spike one authenticated order flow to compare hardening with incremental replacement. **Acceptance gate:** The dependency inventory, selected runtime matrix, unresolved findings and module migration decision are reviewed before a fixed delivery quote. **Proposed owner:** Technical lead **Evidence:** E01, E06, E07 ### F06 / P0 — Make operation and recovery testable **Observed:** The available evidence concerns an isolated local showcase. It does not establish a production host, alert delivery, a restore drill or native-device release validation. **Implication:** Real users would introduce recovery, support and device obligations beyond the current demonstration. **Proposed action:** Define hosting ownership, staging, protected logs, health checks, backup retention and recovery objectives. Rehearse database and media restore as well as application rollback; validate agreed physical devices. **Acceptance gate:** Restore and rollback are demonstrated in staging, alerts reach the responsible person, and the approved device/order journeys pass before inviting pilot users. **Proposed owner:** Release owner + operations + QA **Evidence:** E01, E08 ## Architecture direction — proposed Preserve the customer, seller, delivery and administrator interfaces. Put user identity, account/role permissions and resource ownership at the server boundary. Keep catalog/stock, orders/fulfillment and payment/reconciliation responsibilities explicit. Use controlled adapters for third-party payment and notification work. Treat the database, uploaded media and restore process as separate operational concerns. These are conceptual responsibilities, not a claim of deployed services or a mandated microservice architecture. ## Options and trade-offs ### Harden the existing backend **Benefit:** Preserves most current behavior and limits migration work. **Trade-off:** Existing coupling and dependency constraints remain; feasibility depends on the security and maintenance review. **Decision rule:** Use only if the technical spike demonstrates enforceable ownership, maintainable dependencies and reliable order behavior. ### Modernize in stages **Benefit:** Keeps the role experiences while replacing identity and order boundaries in manageable slices. **Trade-off:** Requires compatibility contracts and a transition plan; temporarily operating old and new code adds work. **Decision rule:** Preferred planning direction, conditional on the spike and agreed pilot scope. ### Replace the platform **Benefit:** Allows a different foundation when requirements or commercial constraints demand it. **Trade-off:** Largest migration and regression burden; current behavior must be rediscovered and revalidated. **Decision rule:** Reconsider only if licensing, maintainability or business-fit gates rule out the other options. ## Proposed delivery roadmap ### 01 — Validate the pilot **Work:** Agree region, currency, seller group, delivery model, payment eligibility, supported devices and rights to reuse the code. Record open questions and map the order lifecycle. **Output:** Pilot brief, dependency inventory and one authenticated order-flow spike. **Exit gate:** The owner accepts the pilot scope and technical direction. Blockers and integration access are known. **Owner:** Product owner + technical lead **Dependency:** Starting phase; needs access to original project records and the proposed business owner. ### 02 — Establish trusted access **Work:** Implement user sessions, resource ownership, admin permissions, release configuration checks and the minimum shared API contract. **Output:** A staging build with tested role boundaries and reproducible configuration. **Exit gate:** Cross-account negative tests and session-lifecycle tests pass; no portfolio identity or local-only endpoint enters the release build. **Owner:** Backend + mobile leads, with QA **Dependency:** Starts after phase 01. External identity-provider setup may affect sequencing. ### 03 — Validate one commerce path **Work:** Complete checkout, stock handling, one payment route, fulfillment exceptions, refund handling and seller reconciliation. Replace product links and validate the agreed devices. **Output:** A traceable sandbox order from purchase through completion or refund. **Exit gate:** Retries, cancellations, partial failures and reconciliation pass the agreed acceptance scenarios. **Owner:** Backend + mobile leads + operations **Dependency:** Requires phase 02 and access to the selected provider's sandbox and merchant configuration. ### 04 — Run a controlled pilot **Work:** Rehearse recovery, verify alert delivery and support escalation, onboard the invited group and collect operational evidence. **Output:** Pilot operating guide, incident/recovery record and a prioritized feedback backlog. **Exit gate:** The owner reviews measured order success, reconciliation exceptions, support issues and recovery results before expanding access. **Owner:** Release owner + support + product owner **Dependency:** Requires previous gates, commercial permissions and an agreed observation period. No launch date is promised. ## Pilot scope ### Prioritize - Invited sellers with administrator review - Catalog, stock and a traceable customer order - One agreed payment route and a refund process - Assigned delivery work and exception handling - Basic reconciliation, support and protected audit records ### Defer until justified - Multiple payment gateways and currencies - Automated seller payouts until reconciliation is proven - Advanced recommendations and loyalty campaigns - Additional delivery integrations or regions - Service splitting driven only by anticipated scale ## Estimation and operating costs No fixed cost or completion date is assigned. Estimate after phase 01 using workstream effort, team availability, provider onboarding lead time, device coverage and migration scope. Hosting, messaging, maps, payments and store-account charges are separate inputs; no provider or price is selected here. ## Proposed pilot measures No baseline or achieved target is claimed. Agree collection methods, exclusions and target thresholds with the owner before the pilot. - Completed pilot orders / attempted pilot orders, with cancellation and payment failure separated - Count and age of payment or seller-reconciliation exceptions - Support cases by cause and time to resolution - Observed restore time and recovered-data age against owner-approved objectives ## Discovery questions - Who owns the merchant relationship, seller settlement, delivery exceptions and customer support? - Which market, currency, payment methods and seller types belong in the first pilot? - Which devices must be supported? Is browser-based shopping a product requirement? - What source and package rights apply to a commercial release? - What downtime, data loss and support response can the pilot tolerate? - What team capacity, operating budget and provider accounts are available? ## Evidence register — summarized - **E01:** Local portfolio-restoration README: setup, preview boundaries, remaining release work and inherited references. - **E02:** Customer, seller and delivery token-signing helpers inspected in source. - **E03:** Sampled customer token verification plus seller and delivery order handlers inspected in source; not an exhaustive authorization audit. - **E04:** App endpoint constants and explicit portfolio-mode configuration inspected. - **E05:** Customer dependency manifest, dashboard link listener and product-sharing short-link calls inspected; retirement checked against Google documentation. - **E06:** Customer dependency manifest and existing marketplace case study reviewed. No payment-provider transaction was executed. - **E07:** CodeIgniter version constant inspected in the local repository. - **E08:** Existing screenshots and restoration record cover three Flutter browser previews and the web admin panel; native devices and live operations were not validated in this assessment. ## Technical references Checked on 2026-10-11. Provider documentation is supporting guidance, not evidence that integrations were executed. - [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) — Supports per-request, resource-aware authorization recommendations. - [Firebase Dynamic Links shutdown FAQ](https://firebase.google.com/support/dynamic-links-faq) — Confirms service retirement and the need to replace affected link flows. - [Stripe webhook documentation](https://docs.stripe.com/webhooks) — Concrete reference for signature verification, duplicate events and event ordering; not a provider recommendation or eligibility claim. ## Handover boundary This assessment changes the BEMRIX portfolio and its planning artifacts only. It does not implement the proposed SmartShop improvements. Local source evidence is retained separately; credentials, database records and original private configuration are not part of this public kit.