The opportunity
FUME had something most brands spend years trying to manufacture: real, unforced consumer demand. Product was moving. People wanted it.
What the business needed was infrastructure worthy of that demand. The storefront was slow and the checkout leaked. Email sat almost entirely unused. And behind all of it, warehouse operations in Puerto Rico ran separately from the sales side, so inventory truth lived in one system and revenue truth lived in another.
None of that is unusual for a brand growing faster than its stack. It is also exactly the kind of problem we like, because every one of those gaps is a place where revenue is already sitting, waiting for someone to build the thing that unlocks it.
Before
- Inventory truth in one system
- Revenue truth in another
- Manual reconciliation
- Email effectively dormant
After
- One centralized record
- Continuous reconciliation
- Humans decide, system tracks
- Email earning daily
The spine: a custom agentic AI ERP
The first and most important build was our own.
Rather than bolt FUME onto a generic platform and spend months bending the business to fit it, we deployed our custom agentic AI ERP and shaped it around how FUME actually operated. Point of sale, inventory, purchase orders, warehouse movement, and product tracking came into one centralized system, with the Puerto Rico operation fully integrated into it.
The agentic layer is what made it more than a database. Instead of a team manually reconciling what the warehouse said against what the storefront said, the system kept those records true to each other continuously and surfaced what needed a human decision. Stock movement, order flow, and distribution intelligence became one live picture instead of three lagging ones.
This is the least visible work in the entire project and the most structurally important, because everything downstream depends on it. You cannot run good email against bad inventory data. You cannot judge an ad campaign when you do not trust your own order records. Getting this right first is what made every other result in this project possible.
You cannot run good email against bad data. Getting this right first is what made every other result possible.
Email marketing agents, producing at scale
FUME's email program was close to dormant. We did not rebuild it by hand, one flow at a time. We put our email marketing agents on it.
Welcome sequences, cart and browse recovery, post purchase journeys, winbacks, and a full segmented campaign structure were produced at a volume and speed that manual production simply does not reach. Because the agents pulled from the ERP, every message had real product, inventory, and order context behind it rather than generic merchandising copy.
The program went from inactive to producing daily revenue in under six weeks. Abandonment dropped, open rates climbed, and the automations kept earning without anyone needing to touch them. That is the difference between email as a campaign calendar and email as infrastructure.
Storefront and checkout
With the backend true and the email engine running, we reengineered the tech stack and rebuilt the checkout logic. Page weight came down, mobile speed came up, and the friction points where sessions were quietly dying got closed.
Paid acquisition, run as a data build
We put just over sixteen thousand dollars into Facebook to learn what acquisition actually cost in this category at real scale.
The campaign returned 0.9 to 1 on first purchase, and we will say that plainly, because what it bought was more valuable than a first order margin. Two hundred plus new customers came in at roughly eighty dollars each, along with a clear, tested read on category acquisition economics. That read directly shaped the retention and repeat strategy that followed, and those customers landed in a system that was finally built to keep working them.
What it produced
Monthly revenue moved from roughly thirty thousand to roughly fifty thousand across the rebuild, a lift of about sixty six percent.
Worth being precise about that number, because precision is the product here. The ERP, the email agents, the storefront work, and the paid test all ran inside the same window, and each contributed. Isolating any single one of them cleanly would have required attribution instrumentation that was not yet in place when the project started. That gap is exactly why closing tracking and attribution is now step two of every engagement we run, right after the data layer itself.
