I was a 3D developer for 15 years. Blender, Three.js, Unity — the kind of work where you build something visual, ship it, and move on.
3 years ago I started building n8n automations for clients. Within a year I had a second service brand (LOVIZ AI). Within 2 years I had a third — inboundy.app, a LinkedIn automation SaaS.
All solo. All from Leipzig, Germany. Sächsische InnoStartBonus (SAB) funding in the bank, no employees.
The meta part: I built loviz-ai.de using AI coding agents. OpenClaw (a Telegram-orchestrated agent, predecessor of Hermes Agent) plus Cursor CLI running on a single VPS. No OpenRouter markup. Direct access to Claude Opus 4.8 and GPT 5.5 for ~€40/month flat.
Here's what 6 months of building a real business with AI agents taught me:
The agent isn't the bottleneck. Your process discipline is. I lost a full week to "the AI didn't do what I wanted" before realizing my spec was the problem. I had to learn to brief the way I brief junior devs: explicit, testable, with examples.
VPS > SaaS for prototyping. Cursor CLI on a VPS gives me 10× the iteration speed vs. web UIs. Especially for ops-heavy automations where I need to restart services, watch logs, run cron jobs.
Cost optimization compounds. Cutting OpenRouter out of the loop saved ~€200/month at our usage. That's an extra "founder salary day" per month — and it forced me to actually understand what each model call was doing.
The real win is speed of decision. When a wrong-direction idea costs 30 minutes of agent time instead of 3 days of dev time, you take more shots. Some hit. Most don't. The ones that hit, hit hard.
The thing nobody tells you: building a business this way feels like cheating until you realize everyone is about to be able to do it. The moat isn't the AI — it's the process knowledge that comes from 2 years of doing it wrong first.
Currently:
AMA about AI-agent-built businesses, n8n orchestration, or solo-founder chaos.
One thing I'd be careful with:
The post makes the AI-agent process very memorable, but the next 100 users probably won't care how Inboundy was built.
The risk is that the build story becomes clearer than the buying story.
That's not necessarily a problem today, but it can become one when attention and user growth start telling different stories.
I wouldn't make the actual positioning call casually in-thread because that decision tends to affect acquisition, onboarding, and what users think they're signing up for in the first place.
You're right, and thanks for naming it cleanly. Post 1 was intentionally the build-in-public version — OpenClaw + Cursor CLI is what I want this thread to remember. The inboundy pitch wasn't the goal.
The actual inboundy origin is shorter: I'm a 3D dev, built a Blender add-on (GLB Optimizer) I needed to promote, hated manual social media, was already automating client workflows with n8n — so LinkedIn was the obvious next thing to automate. Worked for the add-on AND for agency clients, so I pushed it far enough to ship a SaaS.
Build story vs buying story is a real lesson — positioning calls don't live in thread comments, they live in the next thing I publish. Next post leads with the origin.
— Lorenz
Makes sense.
The reason I flagged it is that founders often discover the buying story only after the build story starts attracting attention.
Interesting to see whether the first 100 users respond to the same narrative that made the product worth building in the first place.