MyColoringBook.io: an AI SaaS from idea to launch

The problem

Parents, teachers and homeschool families want coloring pages about specific things: a triceratops in a spacesuit, this week’s spelling words, a child’s own pet. Stock coloring sites offer thousands of generic pages and none of the one you need. General-purpose image generators can draw anything, but they don’t produce what a coloring page needs: bold, closed outlines, no shading, and something that prints cleanly on a home printer.

The goal was a product where anyone types a sentence and gets a printable page in seconds — and a business that could reach those families without a paid-acquisition budget.

How we approached it

We treated the model as one component, not the product. The work split into four problems, each with its own success criteria:

1. Output quality. A generation pipeline that consistently produces line art a child can actually color: thick outlines, open white space, no gray fills.
2. Product and accounts. Fast sign-up, a personal library of saved pages, and printing and download that work on every device.
3. Billing. Plans and credits that map to real generation cost, with entitlements that can’t drift out of sync with payments.
4. Distribution. A content engine that ranks in search and gets cited when people ask an AI assistant for coloring resources.

Architecture

• Next.js + TypeScript for the app and server routes, so the UI, generation endpoints and content pages share one codebase and one type system.
• Supabase for authentication, Postgres and file storage — each user’s generated pages live in their own library and can be re-downloaded or re-printed.
• Stripe for checkout and billing. Webhooks are the source of truth for entitlements, so what a customer can generate always matches what they’ve paid for.
• A prompt pipeline that wraps the user’s sentence in the constraints that make a good coloring page, so quality doesn’t depend on users knowing how to prompt.

Built to be found by search engines and AI assistants

For a consumer product, distribution is the hard part. Instead of bolting a blog on later, we built the content system as part of the product:

• An MDX pipeline with TypeScript schemas for every post’s frontmatter, so titles, descriptions, dates and structured data are validated at build time rather than remembered by hand.
• Reusable React components inside posts — galleries, printable previews and calls to action that link straight into the generator.
• Topic clusters aimed at the audiences who need custom pages most, with homeschool families and “AI coloring page” searches as the first two.
• Generative engine optimization alongside classic SEO: direct answers early on the page, question-led headings, clean structured data and specific facts, so AI assistants have something concrete to cite.

Treat the content engine as product code. When the schema is typed, every page ships with correct metadata by default.

What we’d tell a team doing this next

• Constrain the model for the use case. Most of the quality came from the pipeline around the model, not from the choice of model.
• Let payments drive entitlements. Webhook-driven credits removed a whole class of “I paid but can’t generate” support issues.
• Ship distribution with the product. A typed content system on day one compounds; a blog added in month six starts from zero.

Updated 2026-09-25