BEMRIX / TECHNOLOGY CONSULTING / 11 OCTOBER 2026
SmartShop.
From FYP to a focused pilot.
A source-informed assessment, an architectural decision framework and a phased commercial roadmap.
Internal assessment of our academic project. Implementation remains proposed. No client engagement, production launch or commercial results are claimed.
Keep the experience. Prove the foundations.
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.
Priorities with acceptance gates.
P0: before a public pilot. P1: required for the supported release scope. Implementation remains proposed.
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
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
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
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
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
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
One shared system. Clear responsibilities.
Customer · Seller · Delivery · Administrator
↓User identity · Roles · Resource ownership
↓Catalog & stock · Orders & fulfillment · Payment & reconciliation
↓Database & migrations · Media & backup · Provider adapters
Proposed conceptual boundaries, not deployed services. Hosting products, provider choices and migration scope remain discovery decisions.
Make the architectural choice deliberately.
Harden the existing backend
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
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
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.
A phased route to a controlled pilot.
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.
Constrain the first commitment.
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
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 achieved target or baseline is claimed. Agree collection methods and thresholds 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
Know what the review establishes.
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.
- 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
- OWASP Authorization Cheat Sheet — Supports per-request, resource-aware authorization recommendations.
- Firebase Dynamic Links shutdown FAQ — Confirms service retirement and the need to replace affected link flows.
- Stripe webhook documentation — Concrete reference for signature verification, duplicate events and event ordering; not a provider recommendation or eligibility claim.
References checked on 2026-10-11. The Stripe reference illustrates webhook behavior; provider eligibility and selection remain open.
No SmartShop implementation changes, commercial launch or live operating results are claimed. Credentials and original private data are not included.