ExoSource Media

The core issue is that PSA labels have changed format over the years. Older labels use a different font, smaller text, and some have holographic overlays that cause glare when photographed. The Vision framework's built-in text recognition handles clean, high-contrast text well, but degrades fast on anything noisy.

The fix was a three-step pre-processing pipeline: first, crop to the label region using a trained bounding box (Core ML model, tiny, runs in ~20ms). Second, normalize the contrast and apply adaptive thresholding. Third, run OCR on the cleaned image. The bounding box model was the key unlock — once you stop trying to read the entire slab image and focus just on the label, accuracy jumps dramatically.

Next step is handling the cert number verification against PSA's public database. If the OCR reads a cert number, I want to cross-reference it automatically and pull the official grade. That closes the loop between scan and price.

I started using Claude Code because I was tired of context-switching between an IDE and a chat window. But the thing that keeps me using it is the architectural reasoning. When you're a solo dev, there's no one to push back on your ideas. Claude fills that gap — not by telling you what to do, but by asking the right questions about tradeoffs.

Example: I was about to add a caching layer to ServiceLine AI and Claude asked me how many concurrent calls I was actually expecting in month one. The answer was maybe 20 per day. The cache would have been premature optimization that added complexity for no real benefit. That kind of challenge is worth more than any amount of generated code.

The workflow I've settled on: plan in Claude Code, scaffold with Claude Code, write the hard parts myself, then use Claude Code for test generation and refactoring. It's not autopilot — it's a multiplier on the parts of development I'm already good at.

Each of the six industry templates (plumbing, HVAC, pest control, electrical, painting, lawn care) has its own scenario-based test suite. The scenarios aren't synthetic — they're modeled on real call patterns from contractors I talked to. A plumber gets different emergency calls than an HVAC tech. The AI needs to know that a burst pipe at 2am is urgent but a dripping faucet can wait until Monday.

The core test suite (203 tests) covers the fundamentals: greeting, caller identification, appointment booking, callback handling, and SMS delivery. Then each industry adds ~100-150 tests for domain-specific scenarios. The HVAC suite alone has tests for "furnace out in winter with elderly resident" vs "AC not cooling in July" — different urgency, different triage, different technician briefing.

The investment paid off when I changed the underlying prompt structure. 47 tests broke, all in ways that would have caused real problems on real calls. That's the point — the tests are a safety net for a system where failure means a missed emergency or a lost customer.

There's a popular narrative that you need to quit your job and go all-in to build something meaningful. I don't buy it. The constraint of limited time is a feature, not a bug. When you only have 3-4 hours a night, you can't afford to yak-shave. You can't spend a week on a config file. You pick the thing that moves the needle most and you do that.

The 9-to-5 also gives me something underrated: financial stability while I build. I'm not racing a runway. I'm not making architectural decisions based on what ships fastest to impress investors. I'm building what I actually want to build, the way I want to build it. That freedom is worth the late nights.

My system is simple: Sunday evening I pick 2-3 goals for the week across my projects. Weeknights I execute. Saturday morning I review and clean up. That's it. No productivity frameworks, no Notion dashboards. Just a text file and discipline.