I built a profitable SaaS in 32 days without writing code, got paying customers, then open-sourced everything

Noor Aziz — Thu, 16 Jul 2026 14:15:46 +0000

A month ago, I put the entire codebase of my SaaS on GitHub under an MIT license; payments logic, tenant isolation, LLM pipeline, the lot. It had paying customers. The unit economics worked out to roughly $67 per teacher per month with margins most SaaS founders would frame on their wall.

People keep asking me why. This post is the honest answer, one month in.

What Kaplen is

Kaplen converts curriculum PDFs and long-form writing into structured YouTube scripts: timed sections, narrative beats, thumbnails, titles, DOCX export. It runs as a multi-tenant B2B platform on AWS (EC2, RDS PostgreSQL, S3, Nginx) serving Iraqi schoolteachers: row-level tenant isolation, a provider-agnostic LLM layer (Anthropic, OpenAI, Groq, Ollama; swappable via one env var), SSE streaming for long-form generation, JWT auth, Stripe billing, dual-hash deduplication.

It processed 200 textbooks across 18 subjects from the Iraqi Ministry of Education curriculum and held 99.7% uptime over its production period.

But I have a confession: I didn't write the code. Any of it.

Kaplen was never really a startup. It was a research question wearing a startup costume:

Can one person with engineering judgment, but delegating 100% of implementation to an AI, design, ship, and operate a real production business?

Not a demo. Not a weekend project with a landing page. A real system with real customers paying real money, where "it works on my machine" isn't good enough because a teacher in Baghdad is depending on it before her class.

The constraints I set: one operator (me), all implementation delegated to Claude, and the company had to be run genuinely: customer acquisition, support, billing, incidents, everything.

The numbers at the end:

32 calendar days from nothing to production
~$500 total tooling cost
34 production modules, 45 API routes, 12 database tables
3,662 operator–model turns across 18 documented sessions
Real paying customers at $67/teacher/month

What I actually learned:

The interesting findings weren't "AI can code." Everyone knows AI can code. The interesting findings were the specific ways an LLM-as-sole-implementer fails and what the human has to do to compensate. Four failure modes showed up repeatedly:

Configuration blindness: the model writes correct code against an environment it can't see, and drifts from reality.
Fragmentation: solutions that are locally correct but globally incoherent, because each session optimizes for the request in front of it.
Accumulation without consolidation: code piles up; nothing gets refactored unless the operator forces it.
Scope creep: the model will happily build everything you mention, including things you shouldn't build.

None of these are fixed by better prompting. They're fixed by engineering judgment: architecture decisions, invariants, saying no, knowing what "done" means. My conclusion after 3,662 turns: coding ability and engineering competence are separable skills, and the second one was the entire job.

I wrote this up properly as a practitioner study: "Engineering Without Coding: A Practitioner Study of Operator-Driven AI Development" (still scared to publish, 2026).

So why open source a profitable product?

Because the research question got answered, continuing to run the company would have proven nothing new.

Startup Bros culture has two sanctioned endings: grow it or sell it. But my payoff function was never MRR. Once the experiment demonstrated what it was designed to demonstrate, the most valuable version of Kaplen wasn't a private revenue stream I'd babysit for years. It was a public artifact: the codebase, the architecture docs, the failure-modes analysis, the honest known-tradeoffs section. The repo and the paper are the results.

Keeping it closed to protect a modest revenue stream would have been optimizing the small number and burning the big one.

One month later: what actually happened

The repo did not go viral. As I write this, it has a handful of stars and no forks. No acquisition offers, no recruiters sliding into my inbox because of a trending badge.

And it still holds up as the right call, for reasons that have nothing to do with GitHub metrics:

It's a career artifact I couldn't have bought. A junior CV says "familiar with AWS." Mine links to a production system with a documented incident history, failure-mode tables, and design-decision rationale anyone can audit. Every technical conversation I've had since starts from a different baseline.
"I built a profitable SaaS" is a story. A public repo with the tenant-isolation decorator you can actually read is evidence. Open sourcing converted my biggest claim from " trust me " to check-yourself.
It ended cleanly. A $67/month/tenant SaaS that exists to prove a point becomes a prison the day the point is proven. I got my time back for the next research question instead of doing support forever for an experiment.

The month of silence was itself informative: if your reason for open sourcing requires applause to be valid, it wasn't a reason.

Should you do this?

Probably not, if your product is your income. Definitely consider it if, like me, the product was always a means: the artifact of record for something you learned. Ask what you're actually optimizing for. Mine was never the revenue; it was the finding, and findings want to be published.

Repo: https://github.com/MoeNoorAzeez/KaplenOpen
Paper: https://shorturl.at/B56xj

Happy to answer anything about the build process, the failure modes, or what operating an AI-built system in production was actually like.

DEV Community: Noor Aziz

I built a profitable SaaS in 32 days without writing code, got paying customers, then open-sourced everything