Thanks for the comment and suggestion! Petrel, in its current state, is deliberately in the post-planning phase of travel, but definitely great ideas on planning portion.

We are agnostic on which LLM does the parsing because the rules and structure built around it is the real magic.

Out of curiosity, how do you currently save ideas you get from Reels?

Very fair callout and question.

The extraction setup was actually the easy part. The magic in the tool is from the deterministic rules I put in place over months of iteration using it myself.

Inconsistent date formats, multi-lingual reservations, logic around when a new trip starts and your previous trip ends, parsing both an expense and a confirmation from the same email, duplication rules for when someone accidentally adds the same booking but from a different source, etc. These were all causes of actual parsing errors found from people testing it out.

I built 68 modules within the tool itself from testing.

The logic of the output will only improve over time with more usage. Building the right logic and ruleset into every conceivable scenario is the end goal.

For the technical audience, the tool runs on Cloudflare Worker with D1 for data and R2 for photos. It's one hand-rolled HTML file and is only ~1.1MB. I built in an HEIC decoder utilizing libheif in a Web Worker. It also has an android and apple version with watch, widgets, and Live Activity native capabilities.

Sonnet 4.5 does the extraction with numerous logic variations built in from trial and error, on many different file types. I am challenging all to try and stump it (PDF, .eml, .csv, .tsv, JPG, .ics).

Thank you! I had a lot of fun branding it around the bird. Do you have any unique booking confirmations to test the tool with?

I don't but this was interesting to see as I have not seen this put together like this. I just appreciate the creativity.

No worries and I appreciate the feedback!

Claude drives me absolutely crazy for that very reason. It's so obvious when people use it to write anything.

I'm a fractional CFO.

Fractional service works for functions that are judgment-dense and cadence-light. You pay for expertise and experience. It's essentially an advisor more than an employee. For building an app, you should hire a contractor or agency with a defined deliverable.

the deployment targets that got cheap over the last five years are all stateless and a protocol that fights that gets no serverless implementations

From a financial perspective, what were your biggest challenges? What was the working capital cycle like? Were you forced to do a certain level of minimum order quantities and did the cash constraint limit other decisions?

500 units was my first run, and it worked out really well. None of the suppliers complained about that order size. I recommend starting with a smaller quantity until you've validated the market. The "economies of scale" between 100, 500, or 1000, units are not all that dramatic. Perhaps 30% cost difference.

I was originally planning to do 4000 units as my first run. Boy I'm glad I started to run out of money and cut it way back. That would have been way too much as a first run.

The pressure is real but that's kind of what we sign up for. If it's not working, part of being an entrepreneur is knowing when to quit and avoiding falling into the sunk cost fallacy. Quitting this one project doesn't mean you failed. You will just divert your energy into the next endeavor. They can't all be winners or everyone would do it. Hang in there.

I agree with people saying LLM developed websites and apps are just more quickly sent to market and they all likely have similar issues and less oversight.