Why I built it
Buying fuel for a network of locations is not one job. It is ordering, deciding where to source from, watching inventory, arranging carriers, tracking what actually arrived, and proving the invoice matches the delivery. I spent years around that work. It runs across disconnected systems, a lot of email, and institutional memory held by a few people.
The people doing it are buyers, schedulers, dispatchers, and the accounting teams downstream of them. They are time-boxed by market hours and delivery windows, and a slow or wrong call costs real money per gallon. Most of the day goes into reassembling context the systems should have kept together: what was ordered, at what landed cost, who approved it, what actually showed up.
So I built the product I thought should exist. In Homebrew an order is an object that carries its own history, from the sourcing decision through the bill of lading to reconciliation.
How it works
The platform is organized around the lifecycle rather than around departments. Each stage hands the next one a complete record. Two stages deliberately require a person to make the decision.
01
Demand
reorder point
02
Sourcing
net landed cost
03
Order
04
Dispatch
carriers and windows
05
Delivery
bill of lading
06
Reconciliation
match and flag
Demand, the order record, and dispatch are the connective stages, and the walkthrough shows those moving. Three moments are worth seeing on their own.
01
The sourcing decision
Homebrew brings the available supply options and their landed costs into one decision point before an order is created. The arithmetic is deterministic code. AI assembles the comparison and shows its reasoning, and the buyer approves.
Screenshot placeholder
Sourcing comparison: supply options and their landed costs at the decision point.
02
Extraction review
Bills of lading arrive as scans and emails. Extraction returns a structured record, and the user can still see and review what was produced against the source document.
AI helps interpret the information. Nothing posts past a person where the reading is uncertain.
Screenshot placeholder
Extraction review: the source document beside the extracted fields and their review state.
03
Reconciliation
Ordered, delivered, and invoiced are matched, and differences are flagged rather than absorbed. Exception triage can read order history, delivery records, and contract terms over MCP and propose an explanation.
It never closes an exception on its own. Every AI-touched field records what it saw, what it produced, and who accepted it.
Screenshot placeholder
Reconciliation exception: ordered, delivered, and invoiced side by side with the mismatch flagged.
See it
Screens show what the product is. A short recording shows the workflow moving, from a location running low through the sourcing decision and out to a reconciliation exception that needs a person.
The sandbox will run on synthetic data with a few guided scenarios. This page does not depend on it.
Decisions that matter
- AI where interpretation helps, deterministic code where precision matters
- Pricing, tax, and freight math is code. Auditors need to reproduce a number, not read a model’s reasoning about it.
- Human approval at two points, not everywhere
- Approval on every step would recreate the email problem. Sourcing and reconciliation are where a wrong call is expensive, so those are the two points that wait for a person.
- One lifecycle rather than disconnected tools
- An order carries its own history forward, so nobody downstream has to reassemble what was decided upstream.
- Structured outputs over freeform generation
- Every AI step returns a typed object the platform can validate, store, and diff. Prose is a presentation layer, never the record.
- Auditability as a feature
- Every AI-touched field records what it saw, what it produced, and who accepted it. Without that trail the AI layer is not adoptable in a finance-adjacent workflow.
What exists today
The product direction, workflow design, requirements, architecture decisions, and definition of done are mine. I use agentic development, Claude Code and Codex working against my own specifications and acceptance criteria, to turn those designs into functioning software.