Public Build Proof
Louie Boards Charcuterie CRM & Dashboard
A custom CRM, order tracker, and fulfillment workflow for a boutique food business with highly specific order details and repeat-customer preferences.
This project matters because it shows how I translate messy real-world operating workflows into a structured product, not just a frontend. The core problem was taking fragmented customer conversations, custom order details, payments, and follow-up logistics and moving them into a system with durable records and cleaner handoffs.
System context
What problem this project actually solves.
The business was running through texts, custom requests, and ad hoc memory. That is workable at low volume, but it breaks as soon as you need repeatability, customer history, or clear order-state visibility.
Operating constraints
- No generic CRM matched the exact flow of custom charcuterie orders, pickup timing, and repeat personalization.
- The data model needed to preserve both transactional accuracy and human context, such as saved product preferences.
- Operational reliability mattered more than visual novelty because missed webhook or order-state transitions would create real customer friction.
Why it belongs in the portfolio
A tailored serverless CRM and e-commerce tracker built on a robust Postgres data layer.
It shows the decision-making, system design, and implementation signal behind the build without exposing private customer or financial records.
Architecture
How I structured the build.
The goal is not to show every file. It is to make the operational design legible to a recruiter or hiring manager in a few minutes.
Frontend and operator workflow
A Next.js interface supports order review, customer lookup, and status visibility without forcing the operator to bounce between spreadsheets, messages, and payment tools.
Relational core
Supabase Postgres stores customers, orders, product options, and repeat-order context as first-class relational entities instead of free-form notes.
Payments and sync
Square webhook events are used to validate payment milestones and keep the order record aligned with external transaction activity.
Operational messaging
Notification logic supports the next step in the order lifecycle so fulfillment work does not depend on manual memory alone.
Product and data decisions
- Modeled repeat-order preferences as reusable customer context rather than burying them inside one-off order text.
- Separated development and production schemas early so experimentation would not threaten live order data.
- Treated webhook handling as an operational integrity feature, not just an integration checkbox.
What a public reviewer can verify
- The case study itself documents the workflow boundaries, data model choices, and business process being automated.
- The stack reflects a full path from product interface to database design to external API event handling.
- Because this is a family business system, the public material emphasizes architecture and decisions rather than exposing customer records or internal operational details.
Future iterations
What I would expand next.
Prepare a sanitized repo walkthrough with schema excerpts and selected API integration patterns.
Add a small gallery of redacted screens showing customer search, order history, and fulfillment status transitions.
Document the order lifecycle as a sequence diagram so recruiters can inspect the system thinking faster.