Outcomes
20+
MVP features shipped from Sep 2025 to Mar 2026 (+68 post MVP PRs)
1,448
Automated tests, 0 type errors, 0 lint errors
4
Active pilot tenants across multiple F&B categories
3
Tier Stripe billing live, with trial conversion in progress
6
Months from zero to live SaaS, solo
Stack: React 19, TypeScript, Supabase, Tailwind v4, Stripe, all directed via Claude Code
About the project
Bringing automation to cost and inventory management
Live SaaS
Solo Founder
F&B Manufacturing
Prophitable started because my wife ran a specialty chocolate business and couldn't tell me, week to week, whether she was profitable. Her costs moved constantly. Bulk-cocoa prices spiking, packaging suppliers raising rates, seasonal swings in production. The spreadsheet she'd built was guessing. So was I, every time I tried to help her use it.
I spent two months talking to other food and beverage founders before writing a line of code. Same pattern across all of them. Real businesses, ranging from first $10K to $700K in annual revenue, running on obscurity. Margin wasn't a number for them. It was a feeling.
The existing tool were static spreadsheets that couldn't keep up with variable inputs. Nothing modeled the actual workflow of a small manufacturer: buying raw materials, making recipes, batching products, fulfilling sales, watching the profit fall out at the end.
The goal was never to ship every feature a category leader has. It was to give a founder one trustworthy number. Am I profitable on this product, on this channel, right now?
Role
Founder
Product & UX design
Engineering (Claude)
Brand
Customer Research
Go-to-Market
Date
2024 - Present
Selected work
Cost-trace from purchase to profit
A single dollar can be traced through the system. A bag of organic cocoa enters via a Purchase Order, gets allocated to a Recipe, gets mixed into a Product Batch, fulfills a Sales Order, and shows up in the Dashboard's profit calculation. Every adjustment along the way (line-item discounts, shipping fees, packaging, fulfillment labor) is attributed back to the SKU it actually touched.
What the user sees on the other side is true per-unit margin. Not "what we charged minus what we paid for the cocoa."
We have no way of doing that now."
— pilot on PO-to-lot traceability, first demo session
Spreadsheets can't do this. Not because the math is hard, but because the bookkeeping is too unforgiving to maintain by hand for more than a few months.
AI Receipt Scan
Tap "Add receipt," point the camera at a paper receipt, and Prophitable parses line items, fees, taxes, and discounts into a draft Purchase Order. It runs on Claude Sonnet's vision model with a structured-output prompt, validated against a benchmark of real receipts I collected from pilot users (some pristine, some crumpled at the bottom of someone's apron pocket).
A receipt that used to take fifteen minutes to enter by hand now takes under a minute. Most of that minute is the upload, not the parsing.
This is unbelievable. I don't know how you came up with this."
— pilot, scanning his first receipt in the live demo
Competitors don't have this feature, and I think the reason is mostly timing. Vision models only got reliable enough to ship in the last year or two. I built the parser, the benchmark suite, the cache layer (which dedups on image hash so users aren't billed for re-uploading the same receipt), and the inline editor for fixing the model's misreads. In benchmarking, Sonnet outperformed Haiku on rotated phone photos and on receipts with adjustments at the bottom, so Sonnet is what's in production.
Transport Orders with Cost Allocation
Most cost-and-inventory tools treat shipping as an after-the-fact line item. Prophitable treats it as a first-class operation. A Transport Order (TO) has stops, each stop links to one or more Sales Orders, and when the TO is marked delivered, the cost of that delivery (packing labor, delivery labor, mileage, materials) is allocated back across the orders that rode in that truck.
The hard part is that small F&B operators rarely deliver one order per trip. A catering operator running an early-morning route might fulfill six Sales Orders across tech offices, a college campus, and a hotel before nine AM — one truck, one driver, one tank of gas. Prophitable models this exactly. Materials go direct to the SO that consumed them. Packing labor splits by unit count. Delivery labor and mileage split equally across the SOs on board.
If one of my guys gets back an hour late, at least I'd know what it should have taken."
— pilot on TO route calculation
If any stop is missing an address when a TO is being optimized, a single modal collects all the missing addresses at once before route calculation runs. The user fixes the data once instead of being interrupted mid-flow.
Co-manufacturer flow for externally produced products
Most F&B software assumes the brand makes everything in-house. About a third of small F&B brands don't. They outsource production to a co-packer, sometimes multiple co-packers for the same SKU. The data model for that has to be different.
Prophitable models externally-produced products as a separate product mode. Each external product has one or more co-packer sources. Costs land as variable inputs (landed cost per case, MOQ, lead time, freight) rather than recipe-built. When a PO is received from a co-packer, the finished goods land directly as product batches. The cost trace stays intact end-to-end: co-packer invoice through product batch through sales order through dashboard, every adjustment attributed.
Your app [Prophitable], the point is to know exactly what it's costing."
— pilot on what Prophitable does that his previous inventory tool couldn't
I designed this against a real pilot's pain. He produces South African biltong through one co-packer in North Carolina with 5-to-8-week variable lead times, and jerky through another in California at a consistent $5.50 landed. His previous tool tracked unit count. It didn't tell him the true cost of either. That gap drove the multi-supplier + per-supplier-cost model.
Research that shaped the product
Talking to those who feel the pain the most
Two rounds, one before the build and one during the pilots.
The pre-MVP round happened in 2024 with four founders. The goal was to validate the category gap before I committed to building anything. Nobody I talked to was happy with their current setup, and nobody could name a solution they'd recommend to a friend. That was the green light.
The pilot round ran from February to May 2026 with four active tenants. Three distinct shapes of pain emerged that I wouldn't have predicted from inside my own head.
One pilot, a B2B catering operator running multi-stop wholesale delivery routes, couldn't see which Sales Order was actually profitable when one driver, one truck, and one tank of gas served six accounts before nine AM. The cost-allocation-on-delivery model came directly from his accountability problem.
Another pilot's pain wasn't per-unit profit at all. It was overhead and cashflow. Whether the lights stayed on next month. That insight isn't really in Prophitable yet, but it's reshaping how I think about the Phase 3 roadmap.
A third pilot runs a café and an Uber Eats storefront and sells the same brownie at different effective margins on each channel. Multi-channel pricing went into the Phase 2 backlog because of him.
The process that produced both rounds, refined across about a dozen interviews:
Define Scope
Before any conversation, I open a Google doc and write a one-page scope. Business context, the specific research goal, target audience, and a discussion guide built to surface real operations. Without a scope, an interview drifts into chat. With one, it becomes signal.
Conduct Interviews
Using the discussion guide loosely, I speak to volunteers via Zoom. The goal is to understand operations, not validate a hypothesis. The best moments are when a founder pulls up their actual spreadsheet and walks me through it, swearing softly at columns long stale.
Participant Outreach
Once the scope is set, I build a list of founders who actually match the criteria. Operationally dense, not just any F&B brand. I reach out through my network first, or to professionals whose audience includes the right fit. Cold introductions only when the fit is sharp enough to justify them.
Take Notes
Light notes during the call so I can stay present on my participant. The real work happens after the call ends. I play back the recording, transcribe verbatim, and tag every line as either signal or noise. The transcript becomes layer one of three.
Schedule Interviews
After confirmation from volunteers, I share my Calendly link to begin scheduling. Live calls when the conversation is exploratory, async written follow-ups when I need depth on a single question. Both feed the same per-person file later in the research repo.
Extract Key Takeaways
With the transcript done, I highlight patterns in the document, create tables on Sheets, and use FigJam boards to map cross-customer synthesis. Some patterns become Phase 2 features. Others stay in the research file as "not yet, but worth watching."
Now today, the research is fed into a three-layer system: raw meeting transcripts, then per-person feedback files, then cross-customer synthesis. The same pattern runs across customer research, marketing, and team docs. It's repeatable enough that a future hire could pick it up in a week, most likely less.
​
If you want to see how I think about research, the closest thing to that is The Spreadsheet Delusion, the original 2024 research report I republished as a blog post.
Visual Identity
Efficiency with streamlined design systems
The brand is built on emarald green (#2bb673) used for CTAs, success states, and link surfaces. Around it sit neutrals scaled across surface, text, and border tokens.
Typography is a custom token scale from `xxs` through `5xl`. Icon and input tokens use bracketed access (`designTokens['icon/size/default']`), which I discovered the hard way after a few hours wondering why an icon prop was silently falling back to a default.
The component system is a custom UI library on top of Tailwind v4 utilities, with a custom Icons component and a Storybook entry for every primitive. Responsive padding scales come from CSS custom properties for mobile, tablet, and desktop breakpoints.
Typography
Colors
Montserrat
AaBbCc123
Montserrat
AaBbCc123
Emerald
#2BB673
Onyx
#212529
Snow
#FFFFFF
Future Proofing, Planning for Growth
The component system, color tokens, type scale, and spacing rules don't exist for their own sake. They exist so the next page I build is faster to ship than the last one. Every type size, color value, input padding, and icon weight lives as a token. New screens inherit them automatically.
That payoff shows up in real time. When co-packer mode landed on the Product page, the UI followed from the system. No new colors, no new spacing rules, no thirty small decisions to make again. The system did the visual work. I worked on the new behavior.
