I've always had side projects going. Most of them die on a Saturday afternoon when I get distracted by another idea. But AIBookArt — an AI tool that generates book cover art — actually shipped. And it actually made money. Not quit-your-job money, but real money from real strangers on the internet.
Here's what I learned.
The idea was obvious (in hindsight)
A friend was self-publishing a book and got quotes for cover design: $500 to $2,000. Meanwhile I was messing around with image generation models after work and thinking "this is getting scary good."
Indie authors need cover art. They don't have big budgets. AI image generation was getting good enough to bridge that gap. I bought the domain the same night.
I didn't do market research. I didn't build a pitch deck. I just thought "yeah, people would pay for this" and started building. Sometimes that's enough.
I kept the tech boring on purpose
My stack: Next.js, Stripe, PostgreSQL, Vercel. That's it.
I use React every day at Amazon, so Next.js was the obvious choice. I considered DynamoDB since I work with it constantly at work, but Postgres was simpler for this use case and I didn't need to think about partition keys at 11 PM.
The whole point was to spend my energy on the AI parts — prompt engineering, generation quality, making the output actually useful for authors — not on infrastructure. Every hour I spent configuring infrastructure was an hour I wasn't shipping features.
If I had a do-over I'd make the exact same tech choices. Boring is underrated when you're building at night after a full workday.
Prompt engineering was the actual product
Here's something that surprised me: the biggest improvements to AIBookArt didn't come from code changes. They came from better prompts.
I spent weeks crafting genre-specific prompt templates. Turns out a romance cover needs to look like a romance cover or readers scroll right past it. Same with thriller, sci-fi, fantasy — each genre has visual conventions that readers expect. I learned more about book cover design in a month than I ever planned to.
The code was maybe 30% of the work. The other 70% was understanding the domain, talking to users, and iterating on prompts until the output was genuinely useful.
I charged from day one
$4.99 per generation. Before I was comfortable with it. Before the product was "ready."
People paid.
That one signal — strangers handing over money — was worth more than any survey, any Reddit thread, any friend saying "yeah that's cool." When someone pays, they're voting with their wallet. Everything else is noise.
If you're building something and you're waiting until it's "good enough" to charge for it, you're probably waiting too long.
The "last mile" almost killed me
Generating a cool image is maybe 60% of the problem. The other 40% is the stuff nobody thinks about: correct dimensions for print vs. ebook, title text that looks professional and not like a Word Art disaster, handling different trim sizes, making sure the spine width is right for the page count.
The boring stuff is what makes a product usable. I wasted two weeks building an in-browser editor with layers and fancy tools. Nobody asked for it. People wanted quick, solid covers — not Photoshop. I ripped the whole thing out.
That was a $0 lesson that saved me months of building the wrong thing.
Making the first $100
Three weeks from launch to $100. The breakdown:
- Week 1: $12 — three sales, all from a Reddit post in r/selfpublish
- Week 2: $38 — got mentioned in a Facebook group for indie authors
- Week 3: $52 — someone found it through Google search
That Google sale was the moment it felt real. Someone I had zero connection to, who I didn't market to, found the product organically and paid for it. That's a business, not just a project.
My biggest regret? Not building an email list before launch. When those Reddit posts aged off, traffic dropped to zero and I had no way to re-engage the people who'd already shown interest. Classic mistake, and I knew better.
Side projects hit different than day-job work
At Amazon, I work on systems with months-long timelines, design reviews, and multi-team dependencies. The side project was the opposite — idea to shipped in a weekend, iterate based on real user feedback immediately.
Both are valuable. The day-job experience in distributed systems, production-quality code, and thinking at scale directly transfers to side projects. And the side project keeps me sharp on full-stack work and reminds me why I got into engineering in the first place.
There's something about taking an idea from zero to "people pay for this" that you just can't replicate at a big company. I needed that feeling again — that obsessive spark I used to have building things as a kid. AIBookArt gave me a taste of it back.
What I'd actually do differently
- Build the email list first. A landing page with "notify me when this launches" would have given me day-one customers instead of crickets.
- Talk to 10 potential users before writing any code. I got lucky that my assumption was right. Could easily have been wrong.
- Ship even smaller. My "MVP" still had features nobody used. The real MVP was a text box, a generate button, and a Stripe checkout. Everything else could wait.
The point
Building AIBookArt taught me that I can take something from zero to a product that strangers pay for. That's a fundamentally different skill than writing code at a big company, and it's one worth developing.
If you're sitting on an idea — just start. Pick a weekend, scope it absurdly small, and ship it. You'll learn more from one launched project than from fifty ideas sitting in your notes app.