Airport HQ

They gave me one real month of numbers, exactly as they track them. My goal wasn't to change their process at all. It was to show them how powerful the data they already collect could be.

If they'd had to learn a new way of working before they could see the value, the demo would have been about the new way of working. This way the only new thing on the screen was what their own numbers could now do.

Chose

Every sheet became its own screen with data entry built in, laid out the way staff already track it.

Rejected

A new workflow modeled on what FBO software usually does.

The cost

Some screens inherit the sheets' quirks. That's the point: they recognized every one of them.

One workbook per month was the actual problem, so flipping between months (and laying several side by side) had to take a click rather than an afternoon. The goal was year-over-year comparison once there was a year of real data behind it.

For the months I didn't have, I generated data with the same shape as the month they sent, and said so plainly. They were looking at their own sheet with more months attached, and they knew which month was real.

Chose

Month filters on every report and side-by-side comparison across several months, with year-over-year next.

Rejected

More dashboards for a single month.

The cost

With one real month, the history had to be generated, in exactly the same shape as theirs, and I told them which was which.

In the demo I asked it which fuel truck was the most profitable. That's a question their sheets can only answer with an afternoon of copying columns between monthly files. Here it's one sentence, and the answer shows its working.

The example questions matter as much as the text box. Nobody knows what to ask a blank input about their own business; six good questions teach the shape of the thing in a glance.

Chose

Natural-language questions answered by Claude over their own numbers, with example questions to start from.

Rejected

Another report to go looking for.

The cost

An answer is only as honest as the brief behind it, which is the next call.

The maintenance shop's labor billing isn't recorded anywhere; only parts spend is. So the shop always reads as a loss. An analysis layer looking at that will tell you to cut the shop, confidently and disastrously, for a business whose fuel customers land there because there's a mechanic on the field.

So the gap is stated beside the line in the profitability view and in the prompt the model actually sees. The insights describe it as what it is, a gap in the records rather than a failing shop, and recommend starting to record what the shop bills. A model's output is only as honest as its brief, and the things you know are missing from your data are exactly the things it can't infer.

Chose

Encode known gaps in the records in the prompt, and show them next to the affected number.

Rejected

Hiding the line, or letting the model reason from books it doesn't know are incomplete.

The cost

The prompt now carries domain knowledge that has to be maintained alongside the data.

Changing the fuel price on their website meant working out who built it, getting in touch, and asking. That's a chain of people and an unknown wait standing in front of a number that changes weekly and decides where pilots buy.

In the prototype, the staff portal renders the public page inside the admin and staff edit it where it appears: the prices, the wording, and which third parties (detailers, mechanics) show up on it. The bottleneck was a person, not a technology, and it would have been easy to fix the wrong half.

Chose

In-place editing of the public site: fuel prices, wording, and which detailers and mechanics are listed.

Rejected

Asking whoever built the website every time a number changes.

The cost

No approval step. Right for a weekly fuel price; wrong for anything with legal weight.