TerraGreetings

The idea

Greeting cards are a strange product category. The emotional value is in the message and the moment, but the delivery mechanism — drive to a store, pick through a rack, pay five dollars, mail it — hasn’t changed in decades. TerraGreetings tests a different model for a specific audience: people who care about the outdoors, printing original nature artwork at home, on demand.

The interesting problem wasn’t the storefront. It was building a catalog of hundreds of original cards without an illustration budget, and making a home-printed card actually feel like a card.

Building the catalog

The artwork is generative, but the pipeline around it is the real work. Rather than prompting ad hoc, I built a structured prompt system with composable dimensions — characters, national parks, moods, occasions — so a card concept is assembled from controlled vocabularies instead of improvised each time.

That has two effects. Visual consistency holds across hundreds of cards because the descriptive language is shared. And the catalog becomes expandable by combination: a new park or occasion multiplies against everything already defined, rather than requiring a new creative brief.

The prompt builder lives in the admin panel, and there’s a separate standalone Prompt Lab app for experimenting with card concepts outside the production system.

Printing is the hard part

A card is not a document. It’s a single sheet that has to fold into four panels with artwork on the correct faces and the message right-reading when folded — which means duplex printing with the back face rotated, fold guides that help without printing over the design, and consistent bleed on consumer printers nobody can control.

I built the print generation client-side with jsPDF, laying out the duplex geometry and fold lines directly. Doing it in the browser means no server-side rendering pipeline to run or pay for, and the file is produced on the user’s machine from the same asset the preview shows. Card art is served in separate display and print variants — WebP for browsing, full-resolution PNG for output — from a CDN, so browsing stays fast without compromising print quality.

The platform underneath

• Auth and subscriptions — Clerk for identity, Stripe for checkout, with subscription state resolved against Supabase profiles and gating premium access
• Data layer — Supabase Postgres across cards, collections, categories, profiles, subscriptions, shared cards, FAQs and promotions, with role-based access control and 34 schema migrations to date
• Admin CMS — I manage the entire catalog through an admin panel I built: cards, categories, collections, promotions, FAQs, users, and the prompt builder
• Sharing — cards can be sent as links, not just printed
• Content — an MDX-based editorial section with 22 posts

What I’d tell you about it

This is a working product with real infrastructure, and I’m not going to claim revenue figures for it. What it demonstrates is scope: I designed the concept, built the generative art pipeline, solved the print engineering, implemented auth and payments, modeled the database, and built the admin tooling to run it — then shipped it and kept iterating.

The reason that matters professionally isn’t the cards. It’s that the same instincts that make an enterprise knowledge base work — controlled vocabularies, structured metadata, consistent presentation, tooling that lets non-engineers maintain content — are exactly what made a few hundred greeting cards tractable for one person.