Why I'm Open Sourcing Small Tales

For a minute there, I thought Small Tales was about to become a cash-printing machine.

You know the fantasy. Put $1 into Instagram ads, get $2 back. Repeat until your laptop starts looking like an ATM.

That is not what happened.

What did happen is I learned a ton about building an AI business from scratch. I learned how to go from idea to prototype fast. I learned where my instincts were right. I learned where my ego got a little too loud. And most importantly, I learned that even when a business idea does not immediately click, the lessons you pick up along the way can still be incredibly valuable.

I also learned something that feels more true every month: coding is quickly becoming the easy part. The hard part is everything around the code.

That is why I am open sourcing Small Tales.

The code is on GitHub. Small Tales is no longer actively maintained. I'm sharing it as a learning resource, and you're welcome to fork it and build your own version.

How Small Tales Started

We first got exposed to the custom children's book market when a friend bought a personalized book from Wonderbly for our 2-year-old son. I thought it was awesome. Seeing your kid's name inside the story is one of those simple ideas that just works.

Then Christmas rolled around and my brother-in-law bought another personalized children's book, this time for his daughter. It was around $60, and I could pretty quickly tell the images were likely generated with a custom AI model trained on photos of the child.

That was the moment the light bulb went on for me.

Custom AI children's books felt like the perfect overlap of a few things I care a lot about:

• AI
• content creation
• being a parent

That is a dangerous combination for me. Give me an idea that sits at the intersection of all three and I am going to convince myself I need to build it immediately.

So that is exactly what I did.

Enter Cursor, Stage Left

I started this project when I opened Cursor for the first time. I really did not know what I was in for. I just had an idea and an appetite to learn. I have always been bullish on side projects, and this one had all the ingredients of a fun one.

About a month later, I had a working prototype.

And honestly, it felt pretty good.

Every time I showed it to a friend, they loved the concept. My confidence kept climbing. I started thinking this thing had real legs. Me, a product manager by day and builder by night, paired with my wife, an incredible author and creative partner, felt like a pretty fun duo to bet on.

On top of that, I had some experience with paid acquisition. I had bought Facebook ads professionally. I had spent my own money on ads to grow a Udemy course. I knew enough to be dangerous, which, as many of you probably know, is sometimes the exact amount of knowledge required to become wildly overconfident.

I looked at the competitors I knew about and thought, "Yeah, I can build something just as good. Maybe better."

I was especially excited about trying to make the experience work with just one photo instead of asking parents to upload a bunch. That felt like a real product wedge.

In my head, it was already happening.

Then Instagram Started Telling Me the Truth

At some point, I started doing the usual competitor research on Instagram.

I was clicking ads. Going through funnels. Watching videos. Getting all the way to checkout. Which, unsurprisingly, told the Instagram algorithm, "This guy is exactly the type of person who might impulse-buy a custom AI children's book."

Then the floodgates opened.

At first I would see an ad and think, "Okay, they are new. Nothing crazy."

Then I would see another and think, "Oh, that is a nice slice on the landing page."

Then another:

"That is a smart way to capture the phone number."

Then another:

"That how-to video is pretty solid."

Then another:

"Good use of social proof."

And another. And another. And another.

It felt like I had stumbled into the Instagram underbelly of custom AI children's books.

The market was way more crowded than I originally thought.

Now, my first reaction was not exactly mature or strategic. My first reaction was basically: who cares, let's brute force our way in.

Very healthy founder behavior.

So I did what a lot of first-time builders do. I ran ads. I tested things. I tweaked pages. I kept thinking I was one iteration away from cracking it.

But after a month of trying to force it, I had to admit something to myself:

I was not going to one-shot customer acquisition cost.

And that is okay.

The Pivot

Once I stopped pretending brute force was a strategy, the next move became a lot more obvious.

The most valuable thing I had built was not just the product. It was everything I had learned while building the product.

I had gone from zero to a real prototype. I had learned how to use AI tools to move quickly. I had explored the custom children's book market. I had made mistakes. I had spent money. I had hit friction. I had seen where the opportunity was real and where it was much harder than I expected.

That knowledge is worth something.

And here is the bigger realization: coding is not the moat here.

In a world where tools like Cursor, Claude Code, and Codex can help you build much faster, the code is becoming more and more commoditized. That does not mean building is worthless. It just means the advantage is shifting.

The hard part is everything around the product:

• setting up a real business with Stripe
• getting your site crawled and indexed by Google
• running Instagram ads without lighting cash on fire
• building an organic TikTok channel
• getting notifications flowing into Slack
• setting up proper logging
• wiring up PostHog analytics so you can actually learn from user behavior
• reviewing books, approving them, and figuring out how to print and fulfill them

That is where the game gets interesting.

There is a great business idea that has been stuck in my head throughout this whole process: commoditize your complements.

If coding is becoming cheaper and more accessible, then the valuable complements are the things around the code. The distribution. The positioning. The operations. The content. The playbook for getting a real business off the ground.

So instead of only trying to compete on selling custom AI children's books directly, I started thinking about how to compete on the content around it.

That is the new plan.

I want to turn those lessons into something useful for beginner builders. Opening up the code is the first step.

Why Open Source It?

Because I think more people should be able to try this for themselves.

If I can make it easier for someone else to build their own version of an AI children's book business, that is a good thing. It lowers the barrier to entry. It helps other builders move faster. And it creates more demand for the skills that actually matter once the code is no longer the hard part.

Things like:

• figuring out distribution
• understanding your niche
• building a real funnel
• creating content people care about
• learning how to test ideas without lighting too much money on fire

That is really the lesson here.

The code matters. The product matters. But those things are only part of the game. The ecosystem around the business matters too.

And if I can teach that part while showing the real code, real decisions, and real mistakes behind Small Tales, I think that is more useful than pretending I found a magic formula.

What You Can Fork

The public repository includes the application code and setup documentation for photo upload, image generation, previews, Stripe checkout, background jobs, PDF creation, approval, and print fulfillment.

It is a code-only release. Customer data, credentials, original branding and artwork, sample books, unpublished course chapters, and the private repository's history are not included. You'll need your own service accounts, reference artwork, and print template to run your own version. The README walks through those requirements.

The code is available under the MIT license, with the included third-party notices. It is an unmaintained reference project, so review the security notes, local dependency repairs, and service costs before deploying it. Forking the repo doesn't set up those services for you.

What About the Course?

A few reasons.

First, a course is a way to make the lessons useful beyond this one side project. I'm not promising ongoing maintenance of the app or a finished course today.

Second, I genuinely love teaching. I love making content. I love taking something I just learned the hard way and turning it into something useful for someone else.

Third, I think this project is bigger than one niche idea.

Even if you have zero interest in custom AI children's books, a lot of what I learned here still applies:

• how to go from idea to prototype quickly
• how to use tools like Cursor, Claude Code, and Codex without getting totally lost
• how to handle the non-coding work that actually makes a product viable
• how to evaluate a market before you get too emotionally attached
• how to think about paid acquisition, positioning, distribution, and product wedges
• how to recover when the first plan does not work

You could swap out "AI children's books" for plenty of other ideas and the underlying lessons would still hold up.

That is what makes this worth teaching.

It is also why I think the course itself can become part of the distribution strategy. I want to document the process publicly, share what I am learning on Twitter, and use the course as a way to create useful content that gets more eyes on Small Tales.

That part feels important too.

I am not just building a product. I am trying to build an audience around the process of building the product.

What the Course Is and What It Is Not

Right now, I have a strong sense of what I want this course to become.

I know the story I want to tell. I know the lessons I want to share. I know there is real value in showing people how I built Small Tales, what worked, what did not, and what I would do differently if I were starting again today.

I started this journey with Cursor. If I develop the course further, I want it to reflect the tools I now use too, including Claude Code and Codex.

What I do not want to do is disappear for weeks polishing a giant video course before I know whether people actually want it.

So for now, I am treating this like I treat most things: get the first version out, see if there is demand, and then go deeper.

If enough people are interested, I will happily put in the extra time to polish the videos, tighten the curriculum, and make the whole thing much more robust.

That is the fun part.

Final Thought

Small Tales did not become an overnight growth machine.

But it did become something else that I am genuinely excited about: a real case study in what it looks like to build an AI business in public, make mistakes, learn quickly, and turn those lessons into something useful.

So that is the announcement.

Small Tales is open source and no longer actively maintained. I'm sharing the code and the messy middle, not just the polished parts.

If you are a beginner builder and you want to learn how to go from idea to real product, handle all the messy non-coding work around it, keep the lights on, and maybe avoid a few of the mistakes I made along the way, I think you are going to like where this is headed.

Fork Small Tales on GitHub, or tweet at @learnwithjabe if you build something with it. I'd love to see what you make.