Cross-location inventory
Structured and semantic search across multiple locations, with stock, confidence, and workflow context presented to an operator.
Anonymized client case study
A multi-location parts workflow with explicit evidence boundaries.
In a confidential client engagement, Sean McDonnell designed and implemented a multi-location dealership parts and inventory workflow using Python, FastAPI, PostgreSQL/pgvector, Redis, and Next.js. This case study describes implemented architecture and tested workflow behavior; it does not identify the client or claim current production adoption or business results.
01Implemented capabilities
What the implemented system demonstrates
These are implementation claims, not claims about current production usage, inventory accuracy supplied by third parties, or business results.
Orders, invoices, and customers
Backend models and operator workflows for inventory, orders, invoices, customers, and location-aware actions.
Fail-closed boundaries
External dependencies remain visibly disabled when credentials or contracts are unavailable; the interface does not pretend a real transaction occurred.
Automation with approval
Drafting and workflow assistance stop for explicit operator review before customer-facing or inventory-changing actions.
Python through interface
FastAPI, PostgreSQL/pgvector, Redis, Next.js, REST interfaces, automated checks, and technical documentation.
Privacy-bounded demonstration
Public descriptions are anonymized and demonstrations use synthetic data. Client, product, source, and operational data are not exposed.
Discuss the system or the engineering behind it.
For a technical role, implementation engagement, or focused engineering discussion, contact Sean directly and identify the project that brought you here.