An abandoned eight-lane bowling center cost $105k. Replacing its scoring and control system alone was quoted at $80k to $120k, with replacement parts at $4,000 per pair of lanes, according to a recent Show HN post . That price ratio is the story.
Once you look at the machine boundary, the magic shrinks. The same post describes 70-year-old bowling machinery where much of the actual actuation reduces to triggering a single relay. After that, the rebuild stack looks almost boring: ESP32 nodes, ESPNow, RS485 fallback, a Raspberry Pi, Redis, a state machine, React, and websockets.
My read is that the lesson here is larger than bowling. A lot of expensive vertical software has quietly collapsed into three cheap layers: edge I/O, a narrow event backend, and a boring operator UI. Small teams can win in these markets now, but only if they want the part incumbents were really selling: ownership of ugly hardware boundaries, uptime, and support.
The expensive part was always the boundary
Customers think they are buying scoring software. What they are actually buying is trusted control over odd sensors, foul detection, pin state, noisy power, and late-night repairs when league night backs up. The screen is the visible part. It is not the scarce part.
The architecture in the HN post makes that plain. Edge nodes sit on sensors and controls. An ESPNow star mesh moves events to a gateway. RS485 sits underneath as a wired fallback for noisy RF. The gateway talks over UART to a Raspberry Pi lane computer. The Pi translates packets into Redis, a state machine drives the game logic, and the rest is familiar middleware plus a web UI.
What matters in the picture is where the expensive mystery disappeared.
flowchart LR
A[Sensors and relays] --> B[ESP32 nodes]
B -->|ESPNow| C[Gateway ESP32]
B -. RS485 fallback .-> C
C -->|UART| D[Raspberry Pi]
D --> E[Redis]
E --> F[State machine]
F --> G[Websocket and middleware]
G --> H[Operator UI]
For a TypeScript and Node engineer, once events land in Redis the rest is familiar territory. The post even says that once the data is there, any React developer can build the UI and bowling animations. I believe it. Sensor events in, commands out, local state in the middle. The loop is the entire trick.
The author also says the hard part outright: writing the firmware and protocol. That is the whole machine. The UI can be polished later. The business value is in making weird hardware dependable enough that an owner stops calling vendor support for every hiccup and stops paying to “white label” equipment they already own.
Cheap hardware only helps when the physical loop is narrow
This is where people usually over-generalize. Bowling matters here because the physical problem looks bounded.
The prototype reportedly landed around $200 per lane pair, or $400 if you are fancy, using commodity parts: relays, optocouplers, IR break-beam sensors, and ESP32s. Spare controllers sit pre-flashed in a drawer. Repairs take five minutes. A rig swap takes under ten. The author even bets a house like his could go from zero to running in an hour or two.
Those details matter more than the headline dollar figure because they tell you which domains are now ownable by a small team:
Actuation is simple. A relay, motor signal, valve, or a small set of commands, not a thousand tightly coupled motions.State is event-shaped. Sensor transitions and commands fit a state machine better than continuous interpretation of messy physics.Hardware is commodity. You can buy the parts, pre-flash spares, and keep them on a shelf.Failure is recoverable. A bad box gets swapped, not nursed back to life with field surgery.Incumbent pricing still assumes scarce compute and captive support.
That last bullet is the entire filter.
If the domain needs deep calibration, invasive mechanical work, or a safety case every time a controller fails, the economics change fast. Start where a failure is annoying and expensive, but still fixable with a screwdriver and a spare unit.
Draw the cloud boundary above the control loop
Jenna Pederson’s piece , “You can build it. Should you?”, is the right counterweight here. Her point is simple: building got cheaper; maintenance did not. Experiments become production, and every new app becomes somebody’s responsibility.
That warning lands especially hard in these verticals. The moat is not writing a dashboard faster than the incumbent. The moat is being the adult in the room when radios get noisy, power surges hit, a sensor drifts, or a site manager calls at 9:12 p.m.
That means owning a pile of work that pure software teams like to wave away:
Provisioning and firmware updates Spare-part strategy Observability and remote support Safe degraded modes when network or RF misbehaves Clear swap procedures for non-experts on site
For an Azure and TypeScript team, I would keep the control loop local and boring. The site controller owns sensors, state transitions, and commands. Azure owns fleet concerns: device registry, operator auth, telemetry, audit logs, OTA manifests, alerting, and the support console. If the site cannot keep scoring, measuring, or controlling because your cloud has a bad afternoon, the boundary is in the wrong place.
The bowling rebuild already hints at that mindset. RS485 fallback is an ops decision. A fistful of pre-flashed spare ESP32 boards is an ops decision. Redis on a local Raspberry Pi is an ops decision. None of that reads like product marketing. All of it is product.
This is also where AI fits, if it fits at all. LLMs can help you generate admin screens, summarize support notes, write test scaffolding, or speed up the boring backend. They do nothing for relay timing, bad RF, or a failed controller in a dusty cabinet. The expensive part remains the same.
The good target is an ugly domain with an oversized bundle
The HN comments are useful because they show the same shape elsewhere. One commenter described retrofitting old machine tools with a converter box that translated analog position signals into something newer motion controllers could read. The first iteration reportedly took under $50 in parts and less than 50 hours of development time. Another said abandoned river level meters that once cost about €100k each and €15k per year to maintain were rebuilt for roughly €80 each using ESP32, an ultrasonic transducer, GSM, and LoRa.
Treat those as anecdotes, not market sizing. The point is the repeated structure: the incumbent bundle is priced for another era, the physical interface is simpler than the sales deck implies, local operators are neglected, and the buyer mostly wants the thing to work without begging the vendor for customization.
For a Node and Azure engineer, that should change the Monday-morning question. Do not start with “what AI app should I build?” Start with “which domain mess is now cheap enough to own end to end?”
Your software side will look ordinary, and that is good news: event ingestion, device registry, telemetry, alert rules, operator UI, auth, audit trails, OTA workflows, maybe a note field for support calls. The thin app is the point. The business value comes from pairing that boring web layer with cheap edge control and disciplined operations.
I would bias toward domains where downtime is costly but bounded, regulation is light enough that a small team can survive it, and the operator already hates the current vendor. Bowling fits that shape. Plenty of forgotten local infrastructure probably does too.
Find the system where the vendor still sells a cathedral, but the machine only needs a relay, some sensors, an event stream, and a web app. That is the domain worth investigating.
Steal this
If you are screening a candidate vertical, fill this out before you write a line of code.
Vertical scorecard
Domain:
Buyer/operator:
Incumbent replacement quote:
Annual support/customization spend:
Estimated commodity BOM per site:
Estimated spare kit cost:
1. Machine boundary
- Exact inputs (sensors, switches, meters):
- Exact outputs (relays, commands, actuators):
- Can the control loop be modeled as events + state? yes / no
2. Failure and repair
- Can a failed controller be swapped in under 15 minutes? yes / no
- Can the site keep operating locally if internet is down? yes / no
- Can I keep pre-flashed spares on a shelf? yes / no
3. Business pain
- What vendor lock-in hurts today?
- What customization is absurdly expensive?
- Who loses money or sleep when the system fails?
4. Founder reality
- Who handles firmware, support, and OTA updates?
- Am I willing to own this system for five years? yes / no
Pass only if:
- actuation is simple
- state is event-shaped
- failure is recoverable with a swap
- incumbents are overpriced relative to the BOM
- you are willing to run support like a real business