Noble Gas, Building the Operating System for a Car Wash and Gas Station Business

A Benmore Technologies case study.

Noble Gas logo

Client: Jack Frisbie, Director of Finance & Real Estate, Noble Gas FDE: Arkash Jain

1. Introduction

Overview

Noble Gas operates a chain of unlimited-membership car washes alongside a portfolio of gas stations and convenience stores across Connecticut and Massachusetts, all under one multi-entity ownership structure. Jack Frisbie, Director of Finance & Real Estate, flew to Chicago for a two-day intensive to learn how to build with AI himself. Over those two days he learned Claude Code, built financial analysis workflows using the /xlsx skill, and audited his own business with tooling he'd never had before. By the end he'd saved 15+ hours a week, built his own Claude skill for Noble Gas, and was pair-programming with us on what became a live analytics portal.

That workshop became two production systems. The first is a real-time analytics portal for the car wash membership business, integrated directly with the car wash POS. It gives Jack live visibility into membership, recurring revenue, acquisition economics, retention curves per campaign, and a P&L, all from his phone. The second is a month-end reconciliation engine for the gas station and convenience store side of the business.

Challenge

Build a financially authoritative analytics layer across two separate business verticals (car wash memberships on one POS; fuel and convenience retail on another POS plus a desktop accounting system), teach the operator to build it himself, and get every number to reconcile. All of this across a rate-limited third-party API, a legacy POS system, and an accounting structure spread across many separate entities.

2. The Problem

Background

Noble Gas runs two very different businesses under one roof: a subscription car wash membership program, and fuel and convenience retail where volume, margins, and reporting work completely differently.

The U.S. car wash industry is a $15 to 20B market growing on the back of unlimited membership plans, which grew +16.6% YoY in Q3 2024 while retail per-wash sales declined 5.3%. Noble Gas had caught that wave with a large and growing membership base, but the business had no analytical infrastructure to understand which campaigns were paying back, which sites were underperforming, or what the real cost of acquisition was for each promotion.

On the fuel side, each entity keeps its own books, and the POS and the accounting system don't speak the same language. Every month the finance team assembled financial statements by hand, pulling POS exports, cross-referencing them against the books, and reconciling variances that were never fully explained.

Pain Points

Financial visibility was manual and stale. Car wash revenue data lived in the POS, but extracting and reconciling it across sites, revenue streams, and multi-month periods required hours of Excel work each week. There was no live P&L, no dashboard, and no alert when a site's trend turned.
Member retention was a gut feel. Several promotional acquisition campaigns had run at different times, with no way to compare acquisition cost, payback period, or retention between them. "Did our promo pay back?" was an unanswerable question.
Aggregate reports hid how each site actually made money. Revenue mix by location, the thing that drives capital allocation decisions, was invisible in the summary numbers.
The monthly close was a multi-day manual exercise. The POS exports in one format; the accounting system books in another. Some revenue lines produced different figures depending on which system you looked at, and no one had formally proven which was correct.
Consolidated reporting had no audit trail. Assembling consolidated financials meant pulling data from multiple sources by hand, on a deadline. The numbers were directionally right but couldn't be traced back to source records.

3. Our Solution

Discovery Process

The engagement started with Jack flying to Chicago for two days. The goal was to build capacity: teach Jack to audit his own business with Claude Code so he would understand the tools before we built anything for him.

Day one was the /xlsx skill and financial statements. We opened his own monthly financials workbook and walked through it with Claude Code. By the afternoon, Jack was running P&L analysis himself, tracing discrepancies between line items, and asking questions the spreadsheet had never surfaced.

Day two was the car wash POS data. We pulled membership and transaction exports, and patterns in revenue mix by location appeared that the aggregate reports had never shown. Jack built his first Claude skill for Noble Gas that afternoon, embedding his business context, revenue categories, and analysis patterns into a reusable skill he could invoke from any conversation.

By the time Jack flew home, he had saved 15+ hours of weekly manual work, had analytical insights he'd never had visibility into, and had started pair-programming on the portal.

Core Value Proposition

Give the operator of a multi-entity, multi-vertical business the same analytical infrastructure that enterprise operators spend millions on, built on their own POS data, reconciled to source, with the operator as a co-developer rather than a client waiting for deliverables.

Proposed Solution

The analytics portal, the layer the POS never shipped:

Executive Dashboard. Fleet-level KPIs (daily, weekly, and monthly revenue; active members; recurring revenue), an auto-generated ops brief in plain English, a site leaderboard with sparklines and week-over-week trends, and alerts when a site drops off its baseline.
Sites Deep-Dive. Per-site cards with revenue, trend, and membership; daily revenue charts with a fleet-average overlay; revenue-mix breakdowns; vs-fleet comparison.
Members & Retention. Active subscriber tracking, recurring revenue by site, and member flow (new vs churned per site).
Acquisition / LTV. Kaplan-Meier survival curves per campaign, acquisition cost and payback month from user-entered ad spend, and campaign-vs-campaign overlays.
Weekly Report. A CEO-format weekly summary generated automatically from POS data.
Financials. A P&L view with editable assumptions and derived operating KPIs.
Persistence Layer. Redis + PostgreSQL dual-write so the dashboard loads from stored data (<100ms) after every deploy, never from a cold API walk.

The reconciliation engine, the monthly close automation:

Variance Reconciliation Engine. Joins three sources (CFO actuals, an accounting-system extract, and POS exports) on account number, computes per-line variance with thresholds by category, and emits an auditor-ready .xlsx report.
Variance Classifier. Automatically classifies the variances that remain by likely cause, so the finance team gets a short list of specific questions instead of a spreadsheet of differences.
Signed Extract Pipeline. A signed, idempotent pipeline that pulls data from the desktop accounting system into a hosted reconciliation service with schema validation.
Account Mapping. A canonical chart-of-accounts mapping that bridges POS category codes to accounting GL accounts and prevents duplicate-account sprawl across entities.
Tested and CI-gated. Postgres-backed, with CI running tests and type checks on every change, covering signing, idempotency, and reconciliation math.

Technology Stack

Analytics portal: - Backend: Bun runtime, Hono framework, TypeScript - Frontend: Vite, TypeScript, Chart.js - Database: PostgreSQL (persistence layer), Redis (hot cache) - Authentication: Clerk - POS Integration: car wash POS data API (OAuth2 client credentials)

Reconciliation engine: - Backend: Python 3.12, FastAPI, SQLAlchemy 2, Pydantic v2 - Integrations: desktop accounting SDK, fuel and convenience POS exports - CI: GitHub Actions (pytest + pyright)

4. Implementation

Claude Code skills

The main deliverable of the Chicago engagement was Jack himself. A non-technical operator who flew in on a Monday morning left on Tuesday evening able to audit a consolidated P&L, identify structural patterns in his revenue, and build domain-specific AI tools on his own. Everything that followed was built on that foundation.

Teaching Claude Code to a Non-Technical Operator

Jack had never used a terminal. The entry point was the /xlsx skill, a Claude Code skill that reads multi-sheet Excel workbooks, traces formula dependencies, and surfaces variances with explanations in plain English. We opened his own financials workbook (many entities, monthly tabs, dozens of inter-sheet references) and ran it.

Within an hour, Jack was asking Claude Code questions about his own P&L that hadn't been asked before: why certain costs tracked tightly to sales in some months but not others, which line items were computed versus hardcoded, and where reconciliations broke down. He'd moved from receiving reports to doing the analysis himself.

Day two we turned to the car wash membership data. Using Claude Code to pull and reshape the transaction exports, Jack broke revenue out by type and by location for the first time. In aggregate the sites looked alike; broken out, the picture was different. Jack made that discovery himself, with the tools in his hands.

Building a Domain-Specific Claude Skill

By day two's afternoon, Jack had enough context to build his first Claude skill. He embedded:

The structure of the business and how its entities relate
His sites and how each system identifies them
Revenue category vocabulary for each line of business
Common analysis patterns and the questions finance asks each month

The skill is now part of his daily workflow. When he opens a new conversation, it loads his business context automatically. He built it himself, and he continues to update it as the business evolves.

The Analytics Build

The portal was built through pair programming after the Chicago workshop. It integrates with the car wash POS vendor's rate-limited Data API, a token-bucket throttle that required empirical characterization before the caching and persistence architecture could be sized correctly. Three rate-limit fix attempts failed because they were based on the wrong model; the fourth worked because we wrote a probe script and measured.

Key production bugs fixed before the numbers could be trusted:

Revenue double-counting. Each transaction's line items contain both the product line and the tender line. Summing all of them doubled every transaction.
Timezone attribution. UTC timestamps with a separate offset field. Slicing UTC for the date undercounted every site by attributing evening transactions to the next day.
Missing plan prices. Most active plans had no scheduled payment price on the record. Without a fallback to the plan definition, recurring revenue was dramatically understated.

All three produced plausible-looking wrong numbers with no errors. Running every calculation against a known POS export is what caught them.

The Reconciliation Engine

The accounting automation was built in a few hours of pair programming, test-first. The variance engine joins the CFO actuals, the accounting-system extract, and the POS export on GL account number, canonicalizing three different account-number dialects into one schema.

Run against a full year of actuals at a pilot location, the major revenue lines reconciled to within a fraction of a percent. The one line that didn't was classified automatically, and the investigation went from "something is wrong" to a single, specific question for the finance team.

5. Results

Product Outcomes

The analytics portal is live in production with authentication, a persistent data layer, a full set of analytics tabs, and a direct POS integration covering executive KPIs, member retention, acquisition economics, weekly CEO reports, and the P&L.

Technical Achievements

Instant Load After Every Deploy. PostgreSQL + Redis dual-write means the dashboard loads from stored data in <100ms after every redeploy. Background scans keep data fresh without blocking any user.
Empirical Rate-Limit Characterization. The vendor API's throttling, quotas, and silent page-size limits were fully characterized by measurement. None of it was in the vendor's documentation.
Math that matches. Every dashboard figure reconciles to the POS's own exports.

Business Impact

Jack saved 15+ hours per week previously spent on manual Excel analysis: assembling exports, cross-referencing spreadsheets, chasing variances.
A new model for operator-led development. Jack pair-programs on portal features. He shipped dashboards himself. The engagement built capability instead of creating dependency.

Read client reviews on Trustpilot ↗

6. Lessons Learned

The Workshop Is the Product. The Chicago intensive was more valuable than any feature we shipped afterward. Two days of teaching Jack to audit his own numbers with Claude Code produced his first real revenue-mix insight, the reconciliation plan, and a co-developer. None of that comes from shipping software on someone's behalf.

The Operator's Vocabulary Is the Spec. "Recovery-based breakeven" in cattle, membership recharges versus retail washes in car washes. Domain expertise doesn't come from reading documentation. It comes from sitting with the operator while they explain why the number they need doesn't match any of the numbers that exist. Listen harder than you read.

7. Conclusion

Noble Gas started as a multi-day manual Excel exercise and is becoming an automated financial operating system, built largely by the operator himself, on his own data. The analytics portal gives Jack real-time visibility into his membership base, retention curves by acquisition campaign, and an auto-generated P&L. The reconciliation engine turns the monthly close from a multi-day hunt into a short list of specific questions.

The most valuable insight of the engagement didn't come from a dashboard. It came from Jack, in Chicago, using Claude Code, looking at his own numbers with real tooling for the first time.

The roadmap continues: more data sources, more entities brought into the reconciliation engine, and a consolidated reporting layer across the whole business. The architecture for all of it is already in place.

⭐ A Note on the Mission

The software the top 1% of operators take for granted (automated reconciliation, survival analysis, real-time retention dashboards) has historically required enterprise contracts, dedicated analytics teams, and IT infrastructure nobody in this market can afford. Benmore paid for a plane ticket to Chicago, and in two days of work together, Jack started building the portal himself.

That's the thesis. An operator with access to the same data infrastructure as the enterprise consolidators, built on their own POS data and owned by them, ends up holding asymmetric advantages over the operators still doing it on paper.

We're excited to keep building for operators who deserve better than a spreadsheet.

Noble Gas