Client system

RFID subscription and access platform

A connected operator, access-decision, customer, and billing system backed by durable PostgreSQL state and a request-driven AWS data layer.

View GitHub repository

Back to selected work

Operator decisions first, then the subscription lifecycle.

Operator and edge controls lead. Customer, billing, architecture, and cloud views then show the state behind each decision. Stripe remains sandbox-only, and physical equipment activation remains outside the claimed scope.

RFID operator dashboard showing an access decision, subscription context, runtime status, and recent allowed or denied events. — The operator view brings together allow-or-deny results, customer context, durable runtime state, and recent events.

RFID operator tag setup showing reader selection, customer claim-code lookup, and controlled manual assignment. — Tag assignment supports reader selection and customer claim codes while retaining a controlled operator fallback.

RFID operator wash controls showing off, manual, and automatic modes with all physical outputs disabled. — Modes and output indicators remain visible without treating a dashboard action as confirmation of physical movement.

Customer portal presenting Standard, Premium, and Ultimate wash-plan choices for one vehicle. — Each vehicle receives its own explicit plan choice before customer and billing details move forward.

Customer portal capturing vehicle registration and optional fleet context before secure checkout. — Registration anchors the plan to a specific vehicle before the customer enters the secure billing handoff.

Customer account showing a vehicle plan, access status, tag readiness, and per-vehicle billing controls with private identifiers removed. — The customer workspace keeps plan, vehicle, tag readiness, payment state, and billing actions visible without exposing private account details.

Stripe sandbox subscription and paid test-invoice state with private customer identifiers excluded. — Sandbox subscription and invoice state anchor the signed event lifecycle. The displayed amount is a temporary test price, not commercial pricing.

Before-and-after database architecture comparing fixed RDS PostgreSQL with Aurora Serverless v2 and verified acceptance checks. — The live service moved to Aurora Serverless v2, preserved record counts, returned to zero ACU at idle, and retired the old RDS instance.

Commercial state, access logic, and field control stay distinct.

ACCESSDecision and field controls

Tag registration, entitlement checks, repeat protection, operator modes, and explicit field-commissioning gates.

SUBSCRIPTIONCustomer and billing lifecycle

Verified accounts, per-vehicle plans, Stripe sandbox Checkout, Billing Portal access, and signed lifecycle events.

CLOUDRequest-driven PostgreSQL

A live migration from fixed RDS compute to private Aurora Serverless v2 with observed zero-ACU idle state.

Four layers, one traceable decision.

Commercial state is resolved before an access result reaches the local field boundary, and every transition keeps its own status.

01 / CUSTOMERVerify identity and ownership
A verified account owns its vehicles, plan choices, and customer-managed billing sessions.
02 / BILLINGReconcile ordered lifecycle events
Signed Stripe sandbox events advance durable subscription state without replaying the same change twice.
03 / ACCESSEvaluate entitlement fail closed
Tag, subscription, repeat, busy, and availability checks produce one explicit allow-or-deny result.
04 / FIELDKeep intent separate from movement
The edge path records command and acknowledgement state while physical activation remains an onsite acceptance step.

Physical actuation remains a separate acceptance step.

The operator interface exposes tag assignment, access results, modes, and output indicators. Reader input, PLC acknowledgement, and equipment movement remain separate field checks.

Customer and vehicle records remain explicit.

Verified accounts keep each vehicle, subscription, billing action, and tag status visible without collapsing them into one opaque customer state.

Billing events update durable operational state.

Stripe sandbox Checkout and signed lifecycle events pass through an ordered AWS broker before current subscription state is reconciled into PostgreSQL.

Connect customer state to controlled operations.

SM Systems builds subscription portals, integration brokers, access-decision services, operator tools, and cloud data layers around explicit operating boundaries.