The State of AI in the Binocular Viewer Industry

Up front: "guy builds software with AI" is not a scarce genre right now, and I'm about to add to it. But I'd note that every industry gets a state-of-AI report eventually, and nobody else was going to write this one.

If you've stood at the Top of the Rock, walked around Niagara Falls, or looked out at the Manhattan skyline from the Statue of Liberty, you've probably used one of our machines: the chrome binocular viewers that have been part of the American landmark experience for nearly a century. You’ve certainly at least seen one of our machines. The Tower Optical Company has been building them since 1933. There are nearly 2,000 of our machines in the field today, across 800-plus sites. Drop in a quarter or two, or these days, tap your phone or a card, and the skyline snaps into focus.

My partners and I acquired the business in June of 2025. What we bought was a genuine American icon with serious logistical problems attached: thousands of machines across hundreds of sites, most of them a long drive from anyone who could service them, and no real way to know what any of them were doing. Every unit was coin-operated. A machine's earnings were whatever came out of it on collection day, recorded on paper slips. Venue partners were paid by written check, and everything got typed into QuickBooks after the fact. A viewer that stopped working stayed broken until a person noticed and alerted our team at headquarters. This wasn't neglect, it was a system built for the world the machines were born into, and it had run that way, more or less, for decades.

Two things had to change. The machines needed to take payment the way people actually pay now and we needed a way to manage the fleet efficiently.

So we developed a tap-to-pay retrofit kit for the machines with an engineering partner, then did the conversion work ourselves, 150 units retrofitted in-house. We finally began rolling them out this past June. The new units do something the old ones never could: they report back to HQ in near real-time.

That solved one problem and created another. For the first time, we had real data coming from the fleet and, at first, it went into spreadsheets. Every tap became a row. Figuring out which machines were earning, which had gone quiet, and figuring out why (Dead battery? Payment terminal frozen? Just a rainy Tuesday?) meant downloading files and squinting at rows & columns.

And the transaction data was only part of it. Each converted machine is its own small logistics problem: a merchant ID for card processing, a payment terminal with its own serial number, a control board with another, a firmware version, a cellular connection, two battery packs, GPS coordinates, a specific physical key to unlock it, an on-site contact, a maintenance contact, and a negotiated revenue split with the partner venue. Multiply that by 150 machines, with the rest of the fleet still to come, and a jumble of spreadsheets and pivot tables was never going to cut it.

What I built

It started as a single HTML file to visualize transaction data so we could see how our new machines were performing – a simple CSV file exported from our payment processor, visualized in a web browser. About six weeks later, it’s a production web application (built on Next.js and Supabase, deployed on Vercel) running the operational heart of the connected fleet that our team and partners use daily:

• Live revenue, per machine, per site: Every location in its own time zone, every figure traceable back to transaction records delivered by our payment processor.
• Machines that tell us how they're doing: The viewers report telemetry data such as battery voltage, firmware versions, and cellular signal, which our dashboard ingests & displays through Google Pub/Sub. The dashboard predicts battery swaps before a unit dies and flags viewers that go quiet within hours while knowing the difference between “broken” and “rained out”. It cross-references local weather and venue closure patterns, so we chase down real problems instead of false alarms.
• A single system of record for every machine: All of it… serial numbers, firmware versions, merchant IDs, SIM cards, physical key types, contacts, coordinates, revenue splits, and site maps live in one place, attached to the machine they belong to, instead of scattered across files and someone's memory.
• An AI assistant that knows the fleet: Built into the dashboard: ask it a question in plain English (for example, which machines went quiet this week, when a viewer was last serviced, how a site trended since launch) and it answers from the live data. The same system of record that ended the spreadsheet hunting also means the AI has one trustworthy place to look.
• Machine health reports and maintenance lists: Every unit generates a health report (signal, battery, uptime, recent/suspected issues) and a service checklist to match. A tech heading to a site, whether someone on our team or a venue's own maintenance crew, walks in knowing what's going on with each machine and what needs to be done.
• Simplified revenue sharing: For every converted machine, the partner's revenue share statement is generated automatically from settled transactions. No math, no manual reconciliation, and a full audit trail. We can remit payment to our partners via ACH or check from our bank account with one click via API and simultaneously send them their revenue sharing statement in PDF form directly from our dashboard.
• A view for every role: The field service team gets a mobile version built for standing in front of a machine – pull it up, capture GPS coordinates, update its status, add notes, take a photo, swap a battery, move on. Venue partners get a live dashboard of their own machines, with health alerts, so they hear about a problem from us before they discover it themselves.

I'm a product guy, not an engineer – a tech enthusiast who's spent years of his career adjacent to code, mostly without writing it. That didn't change here. Claude Code definitely needed a lot of hand-holding, and the hand-holding was the point. The necessary context comes from running the business. AI didn't replace domain knowledge. It removed the translation layer between the person who has domain expertise and building working software.

What it's done for the business

A machine that stops reporting gets flagged almost immediately, instead of whenever someone next happens to visit the site. At a dollar a view, downtime at a busy landmark adds up quickly, and it used to be invisible until it turned up on a phone call from a partner or a maintenance visit.

The coordination around fixing things, such as who's responsible for which machine, what needs doing, and what's already been done, no longer lives in phone calls and email threads between our team and venue staff. The flag, the checklist, and the maintenance record travel together, so managing fleet health across internal and external parties has stopped being a major administrative job in itself.

Remittance work went from hours of paperwork & spreadsheet reconciliation to minutes of review each month.

The question "what do we know about this machine?" now has one answer instead of five. Serial numbers, firmware, contacts, key numbers, revenue splits, service history, precise physical locations -- none of it lives in a filing cabinet, a spreadsheet, or only in somebody's memory anymore.

Partners with tap-to-pay machines can watch their numbers live rather than waiting on a statement. Now, we place machines based on what the data says, rather than on what we assume.

The takeaway

We're 150 units into a fleet of a couple thousand. The platform that runs them was built in about six weeks, by a person who runs the business, on a $200/month Claude subscription. I want to be clear about what that number replaced: an engineering hire we couldn't justify, a contract dev shop that would have needed weeks or months just to understand the operational nuances of our business, or, most likely, the version where the project simply never happens and we run a modernized fleet on spreadsheets forever.

That third option is the honest counterfactual. A few years ago, a business like ours – physical, distributed, ninety-plus years old, no engineering team – didn't get custom software. A full-stack team is a six-figure decision before it writes a line of code, and teaching that team the operational nuances of the business requires a lot of time. AI took both of these costs to virtually zero. The people who don’t need the nuances explained to them can just build the product.

What stays with me is how repeatable this feels. Every niche industry, businesses too specific, too physical, too small for custom software to ever make sense, just got access to it.