From Selfie to Trading Card: Shipping an AI Image Product on a Free Tier

Last August I built a trading card generator for my son's high school marching band. A parent uploads a phone photo of their kid, picks a theme, and a few seconds later the kid is the star of a Victorian-era band portrait card, complete with their name, instrument, and years in the program. The card flips in 3D to show stats on the back, and it downloads ready to print.

Real families used it during the fall season. Dozens of cards came out of the pilot, generated for real students. By November I had enough signal to pivot the idea from one school band to the broader youth sports market under a new name: SportsCard AI.

This post is about the part that surprised people most when I demoed it. Not the AI generation, which is genuinely the easy part now. The surprise was the bill: the entire pilot ran on infrastructure that cost me almost nothing, and I think that math is an underrated advantage for anyone building an AI image product right now.

## One photo in, eight styles out

The product premise is simple. Parents already take hundreds of photos a season. Professional photo packages run $30 to $150 and take two to four weeks to come back. Custom card printing needs $500-plus minimum runs, which makes a one-family order impossible. So the photos sit on phones and nothing ever feels keepsake-worthy.

SportsCard AI offers eight themed card designs: Victorian Era, Jazz Age, Vintage Brass, Retro Star, Modern Marching Hero, Drumline Legend, Color Guard Champion, and Section Leader Elite. The model re-renders the subject in the chosen era while keeping them recognizable. That likeness preservation was the hardest technical problem in the whole product, and it's the thing that makes a parent gasp instead of shrug.

The generation engine is Gemini 2.5 Flash Image doing image-to-image work. Each theme is a carefully written prompt that describes the era, the styling, the lighting, and the card composition, with the uploaded photo as the reference. I did not fine-tune anything. The base model handles it.

## The pipeline is one serverless function

Here is the whole architecture. A React and TypeScript client built with Vite handles photo upload or webcam capture, cropping, and the card UI. When the user hits generate, the client calls a single Netlify Function. That function holds the Gemini API key, sends the photo plus the themed prompt to the model, and returns the image.

That's it. No queue, no GPU fleet, no image storage service.

Two implementation details earned their keep. First, the function retries with a fallback prompt when the model returns text instead of an image, which happens often enough that you need to plan for it. If your pipeline assumes every generation call yields a picture, your users will hit a blank card at the worst possible moment.

Second, the API key never touches the client. The Netlify Function is the only thing that talks to Gemini, and it also enforces authentication and per-user limits. During the pilot, every tester got a password login and a cap of ten renders, tracked server-side. That cap is not just abuse prevention. It is the spend throttle for the whole business.

## Designing for zero storage

The app stores no images. Not as a shortcut, as a decision.

The subjects are kids. Before any camera or upload activates, a consent modal explains what happens to the photo. The image goes to the generation call and comes back as a card, all within the session. When the session ends, nothing remains on a server anywhere. There is no bucket of children's photos for me to secure, leak, or explain.

The privacy posture came first, but the architecture benefit followed: no storage means no storage bill, no retention policy engineering, and no database to migrate when the product changes shape. The roadmap eventually adds short-lived sharing with seven-day expiry, and a real backend is gated behind a COPPA compliance audit. Until a lawyer signs off, the cheapest and safest amount of stored user data is zero.

## The free-tier capacity math

Now the part I actually want to sell you on.

A static site plus serverless functions on Netlify fits comfortably inside the free tier for a pilot-scale product. There is no server idling overnight, no monthly database instance, no object storage accruing charges. The fixed cost of keeping SportsCard AI live, month after month, rounds to zero.

That leaves exactly one metered cost: the generation call itself. The cost structure of the entire product is a single variable that scales with renders, and renders are capped per user. Ten renders per pilot tester meant I knew my worst-case spend before a single person logged in. When I think about pricing, the question is one division problem: what does a generation cost, and what will a parent pay for the result?

Compare that to what this product replaces. A photography studio carries gear, sitting time, editing labor, and weeks of turnaround. A traditional card printer carries minimum runs and inventory. My November business plan pencils out a 64 percent margin on a $9.99 digital card, and the reason that works for a solo builder is that there is nothing else to pay for. The free tier is not a budgeting trick. It is what lets a one-person product sit in the market indefinitely, collecting validation, without a burn rate forcing decisions on a timeline the product isn't ready for.

I'll be precise about where things stand, because I think founder posts that blur this are useless: the pilot is live, the technology is field-tested, and revenue is zero. No Stripe checkout yet, no paying customers. The free-tier math is exactly why that's fine. A product with near-zero fixed costs can wait for its market. A product with a monthly infrastructure bill cannot.

## Print-on-demand finishes the economics

The physical side follows the same principle: never own inventory.

The plan is Gelato's print-on-demand API for physical fulfillment, standard 2.5 by 3.5 inch cards on premium cardstock, printed and shipped per order. The pricing tiers stack from a $9.99 digital single up to a $17.99 digital-plus-physical card, a $49.99 season pass, and a $199 team bundle. A planned affiliate program would pay team coordinators and band directors a 30 percent commission through Stripe Connect, turning the people who already organize these kids into the distribution channel.

None of that is built yet. It is specified in the roadmap, and I am deliberate about the sequencing: sharing first, then storage, then commerce. But notice the shape of the whole stack, planned and built alike. Generation is pay-per-call. Hosting is free tier. Printing is per-order. Distribution is commission on sales that already happened. At no point does money leave before money arrives.

## What the field test killed

The original plan was printing cards at the stadium during games. The field test killed it fast: no reliable electricity at the field, a season only a few months long, and parents at a Friday night game are watching their kid, not making purchase decisions.

That failure was cheap because the infrastructure was cheap. I didn't have to recoup a hardware investment or unwind contracts. I rewrote the plan around remote, digital-first delivery and kept everything that worked: the generation pipeline, the themes, the privacy model. When your fixed costs are near zero, a pivot is a document edit, not a layoff.

The market the pivot points at is real. Youth sports in the US is a $40 to $56 billion annual market, families average about $1,016 per child per year, and parents already spend $100 to $300 a year on sports photography. The same engine extends to dance, scouts, and any activity where a kid wears a uniform and a parent holds a phone.

## What to steal from this

If you're building an AI image product, here is what I'd carry over from this one:

1. **Make the generation call your only variable cost.** Static hosting plus serverless functions can carry a pilot for free. If your architecture has a second meter running, ask why.
2. **Cap renders per user from day one.** A server-side usage limit is your spend ceiling, your abuse defense, and your pricing research instrument in one mechanism.
3. **Handle the model's failure modes in the pipeline.** Image models sometimes return text. Build the fallback retry before launch, not after the first confused user.
4. **Keep the API key behind a function.** A serverless proxy costs you one file and buys you auth, limits, and key safety.
5. **Store nothing until you must.** Especially with photos of minors, zero retention is both the strongest privacy stance and the cheapest architecture. Let compliance work gate the database, not the other way around.
6. **Let free-tier economics set your tempo.** A product that costs nothing to keep alive can afford to validate slowly. That patience is a competitive position most funded competitors can't hold.

The pilot proved the pipeline with real families in one school community. The next phase is sharing, then payments. I'll write that post when there's revenue to report honestly.