SlabSquad — phone-camera trading-card grading in seconds
Constraint
The box they were trapped in
Pro card grading at PSA or BGS takes weeks, costs $20+ per card, and forces the collector to ship the card before they know whether it's worth grading. The natural pre-screen is the collector's phone — but a phone camera doesn't have the lighting, macro, or fixed-distance setup pro graders use, and four grade axes (centering, corners, edges, surface) need separate visual reasoning that has to hold up against PSA-style rubrics.
Approach
How we attacked it
A Flutter app for iOS and Android with a computer-vision pipeline behind it: OpenAI vision for the open-domain reasoning, custom CV layers we trained on card-specific failure modes (corner softness, surface scratching, edge whitening, off-centering) for the per-axis scoring. Users capture or upload front, back, and corner shots and the pipeline returns a per-axis breakdown plus an overall Apex grade. Inference runs on AWS Lambda for the routine path, EC2 for the heavier model passes, S3 for image storage. Node.js backend wires Firebase auth and Stripe billing into the grading API.
Decisions
What we picked, and what we rejected
Position as a pre-screen, not a PSA replacement
Pro grading is a chain of certification, trust, and physical slabbing that a phone camera can't replace and that we shouldn't pretend to replace. The honest product is the pre-screen — let a collector decide which cards in the binder are worth the $20 and the wait before they send them off. That's a defensible position; the alternative would have been chasing trust signals we couldn't deliver.
OpenAI vision plus custom CV layers, not one or the other
Open-domain vision is good at "this is a card" but blind to the failure modes graders score — corner softness, surface scratching, edge whitening. Pure custom models score those axes well but are slow to ship. The hybrid uses OpenAI vision for open reasoning and custom CV for per-axis scoring trained on the failures graders call out — defensible breakdown, faster than either path alone.
Flutter over separate native iOS + Android
One team, one codebase, parity across both platforms from day one — and the camera + ML pipeline runs cleanly through Flutter's platform channels. Splitting into native would have doubled the build cost and slowed the model-update cadence, which is the part of this product that needs to move fastest as the dataset grows.
Lambda for the routine path, EC2 for the heavier model passes
Most grading requests are cheap and bursty — a handful of cards in a session, then nothing for hours. Lambda scales down to zero between bursts and up under load without pre-provisioning. The heavier model passes that need a warm GPU live on EC2 so they don't pay the cold-start tax on every invocation. Mixing the two kept the per-grade cost low without choking on the harder cards.
Trade-off
What we didn't build
We did not try to replace PSA. Their certification, trust, and slabbing service aren't replaceable by a phone camera, and chasing them would have asked for things we couldn't deliver from a handheld shot. SlabSquad is the pre-screen — figure out which cards in the binder are worth the $20 and the wait before sending them off. We also did not build native iOS and native Android side by side; Flutter shipped parity across both platforms with one team and the camera + ML calls run cleanly through platform channels.
Outcome
What changed after we shipped
Live cross-platform app where collectors and resellers capture card photos and get per-axis grading scores against a PSA-style rubric in seconds, with an overall Apex grade alongside the breakdown. Subscriptions through Stripe, accounts through Firebase, the inference round-trip running through AWS Lambda against the OpenAI + custom CV pipeline.
Talk to us
Have a similar project in mind?
Tell us what you're working on. We'll let you know whether it's a fit.