KloudC / forward-deployed engineering
Retail Operations Platform.
From the store floor to a working system.
What it does
A FastAPI/React/Flutter operations platform that helps retail staff manage inventory, purchasing, reporting, labels, and daily workflows across web and mobile.
Why it matters
Staff need to complete the task in front of them without reconciling separate tools or losing context between devices.
What I owned
I carried client requirements through architecture, backend and web delivery, the Flutter extension, validation, and release preparation.
Conceptual architecture illustration. No production account or client data.
01 / THE PROBLEM
Start with the constraint.
Retail operations span people, stock movements, purchasing, reconciliation, and multiple systems. A useful product has to fit the way staff work while making the underlying data dependable.
Since August 2026, I have run an in-house FastAPI/React platform alongside Toast and extended it with a Flutter staff app. I also migrated the surrounding automation from Clover to Toast. The mobile application shares the backend and role model instead of creating a second data silo.
02 / THE ARCHITECTURE
Under the hood.
- 01Toast feeds + nightly backfills
- 02Integration + validation layer
- 03Shared FastAPI backend
- 04React workspace + Flutter iOS
A simplified view of the boundaries I designed.
03 / ENGINEERING DECISIONS
The details that matter.
Extend the existing foundation
I extended the existing React/FastAPI platform with a Flutter client that shares its data and role model. That kept mobile delivery focused on the store workflow instead of duplicating backend logic.
Keep an operator in the loop
I designed review steps around price changes, purchasing, and reconciliation. The point was to make a staff decision clearer, not to hide it inside automation.
Choose reliable automation
I piloted time-series forecasting, then replaced it with a deterministic heuristic when production data variance made the model less dependable. The simpler path was easier to explain and safer for an operational workflow.
Bound AI access
I constrained the inventory assistant to read-only tools and used structured outputs. It can answer operational questions without being able to rewrite the underlying records.
Distribution is an engineering task
I took the signed Flutter release through App Store Connect and TestFlight, then through Apple App Review to approval and a live App Store listing, backed by public support and privacy pages.
04 / TESTING & DELIVERY
Make the result accountable.
I checked the data behind the screens, validated generated PDFs visually, and used database-verified and pixel-level regression checks before releases. The current release process runs more than 300 backend tests and 800 app tests against copies of production data. For iOS, I worked through signing and provisioning, validated the release build in TestFlight, and took it through Apple App Review.
I used Claude Code to accelerate implementation while owning the requirements, architecture, prompt and context design, debugging, acceptance criteria, validation, and release decisions.
05 / OUTCOME & LESSON
Forward-deployed work starts with understanding the workflow, then carries that understanding through integration, user experience, and release.
A connected web and mobile operations experience, with the Flutter staff app live on the App Store and still receiving new features and fixes.
Evidence & provenance
Client work and the App Store launch are documented in the role-specific and master resumes. Client code and authenticated screens were unavailable for this review; no implemented supplier projection is claimed.
Supplier projection is not claimed. Client metrics, internal endpoints, and operational records are intentionally excluded.