Creator economy for kids · Live in production
Shirt Elastic
Kids design t-shirts with AI, sell them for real, and earn a cut — with their school earning a cut too.
Role: Product design, safety model, flow design, and direction of the agents that wrote it.
Timeline: Live at shirtelastic.com — open to the public
- Kinds of information tracked
- 26
- Things it can do
- 153
- Pages
- 36
Distinct record types in the data model, from counting the table definitions in the schema file. Counted on 21 September 2026.
Separate operations the system can perform, from counting the HTTP endpoints registered in the server code. Counted on 21 September 2026.
Screens in the site, counted as page components. Counted on 21 September 2026.
What was actually broken
A kid has an idea for a shirt. Between that idea and a real shirt sits: design software they can't use, a print supplier with a minimum order, a storefront, a payment processor, and a tax form.
Every one of those is a wall. The idea dies at the first one.
Shirt Elastic removes all of them, and then adds the part that makes it stick — the kid earns money, and so does their school.
The flow I designed
The design is dominated by one decision, and everything else follows it.
You make the thing before you make an account. A child arrives, describes what they want, picks a style, generates it, reviews four versions, customises it — and only then, when there is something they want to keep, does the app ask for an email. A magic link claims the work already sitting in front of them.
This costs real engineering: designs have to exist without an owner, and be adoptable later. It is worth every line. The alternative — a signup wall in front of a 10-year-old with an idea — loses almost all of them, and the ones it loses are exactly the ones who hadn't yet decided the product was for them.
Nothing unsafe reaches a screen, ever. Two separate checks look at every image, and if a check cannot run at all, nothing publishes. This is the one place in the product where a false negative is unacceptable and a false positive is merely annoying, and the system is tuned accordingly.
Touch targets are sized for eight-year-olds. Bigger than an adult interface would use, with generous spacing, because a mis-tap on a design you're proud of is a small heartbreak.
Money is explained, not just calculated. Commission splits between creator, school and platform change during a fundraiser, so the interface shows the split rather than just the total. A kid who can see where the money went trusts the number.
The school is a growth loop, not a feature. Tagging a school that hasn't registered triggers outreach to that school. The kids do the distribution.
Interface notes
Three steps, and none of them is “sign up”
A child describes an idea and sees it made before anything is asked of them. The account comes after, when there is something worth keeping.
Sign in is in the corner, not the door
It is there for people coming back, and deliberately off the path of someone arriving with an idea.
“Surprise me” answers the blank page
The hardest moment is the empty box. Reacting to something is far easier than inventing from nothing.
The hard part
Nothing unsafe reaches a child's screen. Ever.
Two separate checks look at every image before it appears anywhere. What matters is what happens when a check cannot run. If the service is slow, down, or returns something unreadable, the design does not publish. Not "publish and review it later" — waiting is for genuine uncertainty, not for outages.
That sounds obvious written down. In practice almost every system does the opposite, because doing it this way ties your product to somebody else's reliability, and it feels like you have made your own thing worse. You have. It is the right trade when the users are children.
The rest of the work is making that waiting state not feel like a fault: honest wording about why something is held, and a queue a human actually clears.
Stack
| Frontend | React 18 + Vite, Wouter, TanStack Query |
|---|---|
| UI | shadcn/ui on Radix, Tailwind, framer-motion |
| Backend | Express 5 + TypeScript |
| Database | PostgreSQL + Drizzle ORM |
| Auth | Email magic links — no passwords anywhere in the product |
| Payments | Stripe Checkout + Stripe Connect Express, with automated daily payouts |
| Image AI | DALL·E 3 primary, Gemini fallback, Photoroom background removal |
| Safety | Gemini Vision moderation, fail-closed, with a human review queue |
| Fulfilment | Printful print-on-demand with shipping webhooks |
| Storage | Google Cloud Storage |
Outcome
Live at shirtelastic.com, open to anyone: design a shirt, order it, have it printed and shipped.
Running in production end to end — AI design generation, two-layer moderation, print-on-demand fulfilment, Stripe Connect creator payouts, school storefronts, fundraisers with prize pools, leaderboards, and an eleven-screen admin console.