Intro: Why I Even Tried This
I didn’t set out to build a polished, investor-ready SaaS. I was scratching my own itch.
AI is expensive. Especially for students. I kept looking at subscription costs and thinking: why does access have to be locked behind $20+/month plans that most students can’t justify? At the same time, I didn’t want to reinvent the wheel by building everything from scratch — payments, auth, dashboards, all that glue code that eats up weeks before you even get to the actual product.
So I asked myself a question: How far can I get in a weekend by just wiring existing tools together?
Spoiler: pretty far. In fact, far enough to have a working, subscription-driven AI platform live and usable.
This is the story of how I glued together OpenWebUI, Supabase, LemonSqueezy, and Cloudflare to build a scrappy but real SaaS.
The Stack: Parts I Borrowed Instead of Building
Instead of writing custom services for everything, I leaned hard on tools that already solved the boring parts.
OpenWebUI → This is the interface, the brains of the operation. It gives me a chat frontend and orchestration without me needing to design from scratch. On top of that, I can plug in my own models, embed textbooks for tutoring, and generally make it feel like a purpose-built student AI assistant without touching every line of code myself.
Supabase → Auth and database in one neat package. Out of the box, I had login, signup, password reset, and a place to track users. No need to spin up my own Postgres cluster or deal with JWT tokens manually — Supabase handled it.
LemonSqueezy (plus a webhook) → Payment processing. I didn’t want to touch PCI compliance, and Stripe can be overkill if you’re just testing ideas. LemonSqueezy let me set up subscription tiers — $5 student, $10 standard, $20 pro — and I wired their webhook into my flow so that successful payments automatically sync to Supabase.
Cloudflare Worker → The glue. This worker listens for LemonSqueezy webhooks, talks to Supabase, and updates user entitlements. It’s basically the translator between the money side and the auth side. Plus, Cloudflare Workers are cheap, global, and fast. I didn’t have to worry about hosting a backend.
That’s it. Four moving parts. No custom servers for the business logic. No reinventing login screens. Just glue.
The Architecture (Simple but Effective)
Here’s how it flows:
User lands on the site → Sign up via Supabase Auth.
They pick a plan → LemonSqueezy checkout handles the payment.
Webhook fires → Cloudflare Worker receives the event, verifies it, and updates Supabase.
Access unlocked → OpenWebUI checks Supabase to see what tier they’re on, then gives them the right access.
I drew this out in boxes and arrows, and it honestly looked too simple. But simple was the point. The less custom backend I wrote, the faster I could ship.
Lessons Learned Along the Way
Glue code beats greenfield.
If I had tried to code auth + payments + user tiers myself, I’d still be debugging. By stitching services together, I got to focus on the actual product — delivering affordable AI access.Scaling surprised me.
I ran a stress test: 10,000 simulated users, 10 messages each, firing every 2 seconds. The little HP ProDesk mini PC running the relay hit ~70% CPU, 56% RAM, and didn’t break. That’s insane efficiency considering the heavy lifting is offloaded to Nebius endpoints. It means even modest hardware can relay a lot of traffic if the bottlenecks are elsewhere.Trade-offs are real.
The flip side of glue stacks is dependency. If LemonSqueezy changes their webhook schema, I’m on the hook to adjust my worker. If Supabase has downtime, logins break. But for an MVP? Totally worth it.Developer time is the real currency.
Sure, I could eventually build my own auth or billing system. But the hours saved by outsourcing to Supabase and LemonSqueezy are worth way more than the server costs.Users don’t care how pretty the backend is.
As long as signup, payment, and access work smoothly, nobody cares whether you hand-coded it in Go or stitched it together with duct tape and Workers.
What Makes This a "Real Platform?"
This question hit me while listening to a talk: what actually makes something a platform? Right now, my system is technically just a series of bolt-ons — a website, POS, auth, webhook, and OpenWebUI stitched together.
But if you strip it back, what I really have is:
A reliable entry point (auth)
A monetization engine (payments)
A delivery mechanism (OpenWebUI + models)
A feedback loop (SEO + organic growth)
Is that enough to be a platform? I think yes. It’s not pretty, but it’s usable, scalable, and it solves a problem: affordable AI access for students.
A platform doesn’t need to be perfect. It just needs to provide value and be extensible. And mine does both.
Where I’m Taking This Next
This MVP is just step one. Here’s what’s on the roadmap:
Free tier: Give students a taste before they commit.
More models: Expand beyond the core tutors into creative tools, essay assistants, and even image generation.
TTS + notifications: Right now, you can even hack the system by editing AI messages and having the TTS read them out loud. Next step is to make features like this intentional.
Better scaling hardware: Eventually, I’ll swap the mini PCs for an X99 dual E5 build with 128GB RAM and GPUs for image workloads. That’ll let me run Stable Diffusion locally with daily caps + waitlist notifications.
Long-term, I like the idea of sovereign clusters (yes, even on a boat one day). But for now, the goal is simple: keep costs low, keep access affordable, and keep growing.
Closing Thoughts
I didn’t build this to impress investors. I built it because students shouldn’t have to pay premium SaaS prices to use AI. And the cool part? I didn’t need a huge team or millions in funding to get it running. I just glued the right tools together.
If you’re thinking about building something — don’t wait until you’ve got the “perfect” architecture. Use what’s already out there. Glue it, test it, ship it. Real users don’t care about elegance. They care about whether it works and whether it’s worth paying for.
And for me, the answer so far is yes.
What about you? Have you ever built a product mostly out of glue code? Would you trust a stack like this to scale? I’d love to hear your thoughts.
Top comments (0)