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

A Benmore Technologies case study.

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

1. Introduction

Overview

Noble Gas runs 8 Soapy Noble unlimited car wash locations and 6 to 15 gas station and convenience store operations across Connecticut and Massachusetts, 40 entities total under one 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. For the first time, he could see which locations were actually generating car wash revenue and which were hiding behind dispenser sales. 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 Noble Portal.

That workshop became two production systems. The first is Noble Portal, a real-time analytics platform for Soapy Noble's membership business that integrates directly with DRB Patheon. It gives Jack live visibility into 10,857 active members and $3.73M in annual recurring membership revenue, plus acquisition economics, Kaplan-Meier retention curves per campaign, and a GAAP P&L, all from his phone.

Challenge

Build a financially-authoritative analytics layer across two separate business verticals (car wash memberships via DRB Patheon; gas stations via CStoreOffice and QuickBooks Desktop), teach the operator to build it himself, and get every revenue number right to the cent. All of this across a rate-limited third-party API, a legacy POS system, a 40-entity QuickBooks structure, and a fleet that generates north of $12M in annual revenue from a single location.

2. The Problem

Background

Noble Gas operates at a scale most single-vertical operators never reach: 8 Soapy Noble car wash locations running a subscription membership business, and a portfolio of gas station and c-store operations that individually outsize the car wash revenue. East Windsor alone produced $12.13M in 2025 revenue across gasoline sales ($9.41M), c-store ($1.90M), and lottery ($820K).

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%. Soapy Noble had caught that wave with nearly 11,000 active unlimited-wash members at roughly $310K MRR, 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 promo run.

On the gas side, Noble Gas runs QuickBooks Desktop Enterprise for each of its 40 entities, with CStoreOffice (Petrosoft) as the POS. Every month, the CFO and Jack assembled financial statements by hand, pulling exports from CStoreOffice, cross-referencing against QB, and reconciling variances that were never fully explained.

Pain Points

• Financial visibility was manual and stale. Revenue data for the car washes lived in DRB Patheon, but extracting and reconciling it across 8 sites, multiple revenue streams, and multi-month periods required hours of Excel work each week. There was no live P&L, no dashboard, no alert when a site dropped 15% week-over-week.
• Member retention was a gut feel. Three different $0.99 acquisition campaigns had run at different times. Jack had no way to compare CAC, payback period, or survival curves between them. "Did our promo pay back?" was an unanswerable question.
• Some car washes weren't actually producing car wash revenue. Working through the data with Claude Code in Chicago, Jack found that several locations were generating revenue almost entirely from dispenser sales (WashCAP units) rather than actual car washes. The distinction was invisible in aggregate metrics, and it changes capital allocation decisions.
• The monthly close for 40 entities was a multi-day manual exercise. CStoreOffice exports in one format; QuickBooks books in another. The lottery line alone produces three different numbers depending on which system you look at: gross tickets sold, net after payouts and state remittance, or an intermediate CStoreOffice value that matched neither. Until the automation, no one had formally proven which was correct.
• EBITDA and lender documents had no audit trail. Preparing consolidated financials for the bank meant assembling data from multiple sources by hand, on a deadline. The numbers were directionally right but couldn't be traced back to source records.
• Campaign economics were inaccessible. No payback month, no CAC, no survival curve. An operator running a subscription business on $0.99 promo acquisition had no way to know whether those members were staying long enough to recoup the subsidy.

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 actual CFO actuals file, the Noble Consolidated (unaudited) Financials - 12 2025 Excel workbook covering all 40 entities, 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 DRB Patheon data. We pulled his Soapy Noble membership and transaction data, and the car wash revenue insight appeared: the dispenser sites were visible in the data if you looked at the right breakdowns. Jack built his first Claude skill for Noble Gas that afternoon, embedding his business context, site names, 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 Noble Portal.

Core Value Proposition

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

Proposed Solution

Noble Portal, the analytics layer Patheon never shipped:

• Executive Dashboard. Fleet-level KPIs (today, 7d, 30d revenue; active members; MRR; ARR), auto-generated ops brief in plain English, site leaderboard with 30-day sparklines and WoW trend %, alerts for sites down >15% week-over-week.
• Sites Deep-Dive. Per-site cards with 30-day revenue, trend, members, MRR; daily revenue chart with fleet-average overlay; wash-sales vs. membership-recharge split; vs-fleet comparison.
• Members & Retention. Active subscriber tracking (~10,857), MRR by site ($310,781), member flow (new vs churned per site), MRR-by-site bar chart with active-member-count overlay, MRR fleet-share donut.
• Acquisition / LTV Tab. Kaplan-Meier survival curves per campaign, real CAC and payback month from user-entered ad spend, by-tier and by-site drill-downs, compare-with campaign overlays.
• Weekly Report. CEO-format weekly auto-generated from DRB data: car volume, counted cars, conversion rate, NET added members, dispenser washes by site.
• Financials Tab. GAAP-style P&L (Revenue, COGS, Gross Profit, OpEx, EBITDA, D&A, Net Income), editable assumptions, EBITDA-multiple valuation, 8 derived KPIs (best/worst day-of-week, top revenue site, recharge mix %, net member velocity, avg MRR per member).
• Smart Codes Import. CSV-based batch import of DRB SmartCodes into the Django backend via a secured portal-to-Django proxy pipeline.
• Persistence Layer. Redis + PostgreSQL dual-write so the dashboard loads from stored data (<100ms) on every Railway deploy, never from a cold API walk.

Noble Gas QB, the monthly close automation:

• Variance Reconciliation Engine. Outer-joins three sources (CFO actuals, QuickBooks SDK extract, CStoreOffice POS) on account number, computes per-line variance with classification (revenue 1% threshold, COGS 2%, OpEx 5%), and emits an auditor-ready .xlsx report with subtotal rows.
• Lottery Hypothesis Classifier. Automated three-value verdict on the lottery line's CStoreOffice anomaly ($390K vs $820K gross vs $30K net), identifying which accounting policy question needs CFO resolution.
• QBXML Extract Pipeline. HMAC-SHA256-signed Windows-resident QB SDK extraction via QBXMLRP2, posting to a Railway FastAPI service with idempotency, schema validation, and bounded clock-skew verification.
• FastAPI Reconciliation Service. Five endpoints: health, extract ingest, reconciliation status, lottery verdict, and a Vite status dashboard.
• Account Mapping Enforcer. Canonical chart_of_accounts_v1.csv bridging CStoreOffice category codes (4110 to 4001 gasoline, 4130 to 4002 lottery, etc.) to QuickBooks GL accounts, preventing the duplicate-account proliferation that happens at 40-entity scale.
• Alembic Schema + CI. Postgres-backed with async SQLAlchemy, GitHub Actions CI running pytest + pyright on every PR, 44 tests covering HMAC signing, webhook idempotency, reconciliation math, and lottery verdict.

Technology Stack

Noble Portal: - Backend: Bun runtime, Hono framework, TypeScript - Frontend: Vite, TypeScript, Chart.js - Database: PostgreSQL (persistence layer), Redis (hot cache) - Hosting: Railway (auto-deploy), Clerk (authentication) - POS Integration: DRB Patheon Data API (OAuth2 client-credentials, Auth0)

Noble Gas QB: - Backend: Python 3.12, FastAPI, SQLAlchemy 2, Pydantic v2 - Windows Integration: QuickBooks SDK (QBXMLRP2), pywin32 - POS Integration: CStoreOffice (Petrosoft), HTML-as-Excel exports + QB Sync Web Connector - Hosting: Railway (FastAPI service + Postgres plugin) - CI: GitHub Actions (pytest + pyright against Postgres 16 service)

4. Implementation

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 40-entity consolidated P&L, identify structural revenue anomalies, 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 the Noble Consolidated (unaudited) Financials - 12 2025 workbook (40 entities, 12 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 the CFO hadn't been asked before: why gasoline purchases tracked so tightly to sales in some months but not others, which line items were computed versus hardcoded, where the lottery income reconciliation broke down. He'd moved from receiving reports to doing the analysis himself.

Day two we turned to the DRB Patheon membership data. Using Claude Code to pull and reshape the transaction exports, the dispenser revenue insight surfaced: multiple Soapy Noble locations were generating the majority of their revenue from WashCAP dispenser sales rather than car washes. In aggregate metrics the sites looked normal. Broken out by revenue type, the picture was fundamentally 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 40-entity business structure (gas stations, car washes, the QB org IDs)
• His site names, DRB site IDs, and CStoreOffice location codes
• Revenue category vocabulary (WashCAP vs retail wash vs membership recharge)
• Common analysis patterns and the questions his CFO asks each month
• The lottery accounting puzzle and what the three values represent

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.

Noble Portal: The Analytics Build

The portal was built through pair programming after the Chicago workshop. Noble Portal integrates with DRB Patheon's rate-limited Data API, a token-bucket throttle (burst capacity ≈ 4, refill ≈ 1 per 3s) 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. DRB lineItems[] contains both the product line and the tender line. Summing all extended amounts doubled every transaction. Feeding Hills reported $6,688 instead of $3,344.
• Timezone attribution. UTC timestamps with a separate offset field. Slicing UTC for the date produced a 10% undercount across all sites from evening transactions being attributed to the next day.
• Null MRR. 85% of active plans have null priceForScheduledPayment. Without the plan-definition price fallback, the dashboard reported $44K MRR instead of $310K.

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

Noble Gas QB: The Reconciliation Engine

The QuickBooks automation was built in roughly 3 hours of pair programming: 19 commits, 44 passing tests, 11 production modules. The variance engine outer-joins the CFO actuals file, the QB SDK extract, and the CStoreOffice POS export on GL account number, canonicalizing three different account-number dialects into one schema.

East Windsor 2025 YTD results against CFO actuals:

Gasoline and c-store reconcile within $15 and $501 on combined $11.3M of volume. The lottery variance is the only open question, and the system automatically classified it: CStoreOffice is emitting a third value matching neither gross nor net, most likely gross minus state settlement. The investigation went from "something is wrong" to a single question for the CFO.

5. Results

Product Outcomes

• Noble Portal live in production at noble-portal.com on Railway, with Clerk authentication, Redis + PostgreSQL persistence, 8 fully-functional analytics tabs, and full DRB Patheon integration covering executive KPIs, member retention, acquisition economics, weekly CEO reports, GAAP P&L, and Smart Codes import.

Technical Achievements

• Instant Load After Every Deploy. PostgreSQL + Redis dual-write means the dashboard loads from stored data in <100ms on every Railway redeploy. Background scans keep data fresh without blocking any user.
• Empirical Rate-Limit Characterization. DRB's API fully characterized: token bucket (capacity 4, refill 1/3s), 403 daily quota vs 429 throttle, PageSize ceiling of 500 silently enforced, gzip giving 5× wire reduction. None of this was in DRB's documentation.

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 is pair-programming on the portal features. He shipped dashboards himself. The engagement built capability instead of creating dependency.

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 the dispenser revenue insight, the QB 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, "WashCAP dispensers vs actual washes" in car washes, "gross vs net vs CSO mid-value" in lottery income. 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 a fully automated financial operating system, built largely by the operator himself, on his own data. Noble Portal gives Jack real-time visibility into 10,857 car wash members, Kaplan-Meier retention curves by acquisition campaign, and an auto-generated GAAP P&L. Noble Gas QB reconciles $11.3M+ of annual gas station and c-store revenue to within 0.03% of CFO actuals, automatically, with a single diagnostic question left for the CFO about lottery accounting policy.

The dispenser revenue insight, identifying which car wash locations weren't producing car wash revenue, is a structural finding that changes a business. It 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: Webster Bank feed integration for 5 East Windsor accounts, Tier 3 account-mapping enforcer, scaling to all 11 gas station OpCos, the 40-entity Master P&L consolidation engine, and eventually a lender dashboard with consolidated EBITDA and DSCR. 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 2 days of work together for a 9-figure business, Jack built 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.