BEMRIX / TECHNOLOGY CONSULTING
A platform.
A clearer path.
Turning SmartShop’s final-year project into a considered plan for a commercial pilot. What to keep, what to validate and what to build next.
Internal assessment · 11 October 2026 · Proposed work, not a completed commercial launch
THE RECOMMENDATION
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.
The decision is to proceed with a scoped discovery and technical spike. It is not a recommendation to launch the current preview publicly.
THE STARTING POINT
Four roles.
One connected system.
Three Flutter applications and a PHP / CodeIgniter backend with web administration provide a substantial starting point. The existing showcase demonstrates interfaces using isolated sample data.
REVIEW FINDINGS
Decisions grounded
in the source.
A targeted review, not an exhaustive security audit. Each finding has a next action and an acceptance gate in the downloadable report.
F01 / P0Identity 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.
Recommendation. 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, E03Supporting technical reference ↗F02 / P0Separate 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.
Recommendation. 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, E04F03 / P1Replace 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.
Recommendation. 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: E05Supporting technical reference ↗F04 / P0Prove 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.
Recommendation. 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, E06Supporting technical reference ↗F05 / P1Plan 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.
Recommendation. 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, E07F06 / P0Make 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.
Recommendation. 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, E08P0 = required before a public pilot. P1 = required for the agreed supported release scope. All listed implementation work is proposed.
ARCHITECTURE DIRECTION / PROPOSED
A shared foundation.
Clear responsibilities.
Keep the role interfaces. Put identity, ownership and order rules on the server, with provider-specific work behind clear integration boundaries.
User sessions · Roles · Resource ownership
Catalog & stock / Orders & fulfillment / Payment & reconciliation
Conceptual boundaries, not deployed services. Hosting products, migration strategy and integration providers remain discovery decisions.
THE TRADE-OFFS
Choose a path with evidence.
THE DELIVERY ROADMAP
Progress by evidence,
not a promised date.
Four proposed phases. Each has an owner, a concrete output and a decision gate before the next commitment.
Validate the pilot
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.
Outputs, owner & exit gate
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.
Establish trusted access
Implement user sessions, resource ownership, admin permissions, release configuration checks and the minimum shared API contract.
Outputs, owner & exit gate
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.
Validate one commerce path
Complete checkout, stock handling, one payment route, fulfillment exceptions, refund handling and seller reconciliation. Replace product links and validate the agreed devices.
Outputs, owner & exit gate
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.
Run a controlled pilot
Rehearse recovery, verify alert delivery and support escalation, onboard the invited group and collect operational evidence.
Outputs, owner & exit gate
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.
SCOPE THE FIRST PILOT
Make the first release manageable.
Planning assumption: one region, one currency and an invited seller group. The business owner still needs to confirm the market, payment route and delivery model.
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
A PRACTICAL HANDOVER
Take the decisions
into the next meeting.
The assessment includes six findings, an options comparison, four delivery phases, a prioritized backlog and the assumptions needed before estimating.
Review method, evidence & references
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.
Reviewed on 2026-10-11. Local source notes are retained separately; the public report contains a summarized evidence register without private configuration.
- 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.
The Stripe reference illustrates webhook behavior, not a recommendation that Stripe is the appropriate or available provider for this business.
Let’s make it happen