Role
Founder & sole developer
Real data. The automation running on schedule: every time-driven pass reads new order emails and completes in a few seconds. Rebuilt in the site's theme from the live execution log.
An end-to-end email-to-inventory automation that reads unstructured order emails with the Claude API and turns them into clean, structured records a business can act on in real time. Sold as a recurring subscription to a paying brand.
A reselling brand buys inventory from dozens of suppliers, and every order arrives as an email in a different format, purchased, confirmed, or cancelled. Tracking stock and spend meant someone reading inboxes by hand and re-typing the numbers into a sheet.
Order emails are unstructured: no two suppliers lay out the supplier name, order number, item, quantity, or totals the same way. That's exactly the kind of messy, real-world data a large language model is good at reading, if you wrap it in the right pipeline.
A Google Apps Script pipeline searches up to 8 connected Gmail inboxes, auto-forwards and filters messages, and isolates the order emails (purchased, confirmed, or cancelled) across all accounts.
Each order email is routed to the Anthropic Claude API for structured field extraction: supplier, order and confirmation numbers, item, quantity, subtotal, shipping, tax, total, and recipient.
Results are deduplicated by order number so the same order is never counted twice, then logged to an interactive inventory dashboard for real-time stock and spend tracking.
From OAuth-scoped Gmail integration and prompt design through deployment and customer delivery, I built, shipped, and supported it as a real product.
A normal parser works when every email looks the same. Order emails do not. One supplier writes Qty: 3, another writes "you ordered 3 units," a third buries the number in a sentence. A language model reads all of them, which is exactly why it fits here.
But a model can also be confidently wrong, so the pipeline never trusts a single read blindly. It pins each record to the order number, drops duplicates before anything is logged, and keeps the original email so any figure can be traced back to its source. A double-counted order erodes trust faster than almost anything, so that guard mattered more than any clever feature.
That gap, between a parser that works in a demo and one a business will pay for every month, is most of what this project taught me. The model does the reading; the engineering around it makes the numbers trustworthy.
Two real order emails the system read and turned into structured records. Every supplier formats things differently, which is exactly the point.
This was my first time charging money for software, and selling it taught me more than building it. A paying customer doesn't care about your architecture, they care that the numbers are right and the thing doesn't break. Deduplication and reliable parsing mattered more than anything clever, because one double-counted order erodes trust fast.
If you're learning this: don't reach for a heavy framework. A scripting layer (Apps Script) plus a good LLM prompt plus careful handling of duplicates and edge cases can be a real, sellable product. Ship the smallest thing that's actually useful, then let a real user tell you what's wrong.