← All posts
September 11, 2026SaaSAIBuilding products

From idea to first SaaS: building content-factory-web

Why I built a content-generation SaaS by hand, what tools I used, and what I learned after the first real users showed up.

Why I wanted to do this

After years as a Product Owner, I was used to writing products — requirements, user stories, specs for engineers to implement. I had never actually built one end to end, alone, without an engineering team behind me.

The reason I wanted to try content-factory-web was simple: I kept seeing small business owners and marketers struggle every day with the same thing — coming up with content to post: captions, short blog posts, product descriptions. They weren't short on ideas, they were short on time. I wanted to find out: if I built a tool that solved exactly that, and got real people to pay for it, could I actually pull it off — playing both the product owner and the person coding alongside AI?

The steps and the tools

Step 1 — Scope down to the smallest sellable thing. I didn't try to build an "all-purpose AI content tool." I picked one single flow: a customer describes their product or service, picks a tone of voice, and gets a few content options they can copy and use right away. Nothing extra.

Step 2 — Pick technology that lets you move fast. I used FastAPI (Python) for the backend because it's lightweight, readable, and I could fix logic myself without needing a DevOps team. The UI is simple server-rendered templates — no complex SPA, because the goal was a usable product, not a technology showcase.

Step 3 — Build the "real customer" flow, not just a demo. This is the part that took the most effort: account registration, email OTP verification, an internal wallet, usage-based deduction. Skip this step and you're stuck with a demo forever, never a sellable business.

Step 4 — Wire up a Telegram bot so I (and later, customers) get real-time notifications — new sign-ups, top-ups, system errors. This let me run the whole thing solo while still keeping an eye on system health, without babysitting a screen all day.

Step 5 — Automate reporting. I wrote a weekly cron job that aggregates numbers (new customers, revenue, usage) and pushes them straight to Telegram. A Product Owner without reporting has no idea whether their product is actually alive.

Step 6 — Deploy for real on a VPS, using Nginx as a reverse proxy and systemd to keep the service running and auto-restart it on crash.

Main tools used: Claude Code (an AI pair-programmer writing and fixing code with me in real time), FastAPI, SQLite, the Telegram Bot API, Nginx, and systemd on a Hetzner VPS.

If you want the details

This post is about approach, not a line-by-line technical tutorial — every product has its own problems to solve. If you're considering building something similar, or want to know exactly how I handled the registration/payment/notification flow, feel free to reach out by email or on LinkedIn — happy to go into more detail.