Last weekend I challenged myself: ship 2 working SaaS products from scratch. Not MVPs sitting in a repo — actually deployed, functional products with auth, payments, and real features.
Here's how it went.
The Products
1. rilo.chat — Community Chat Widget
Think Chatango meets Discord, but modern. A real-time chat widget you embed on any website with a single <script> tag.
What it does:
- Real-time WebSocket chat
- AI-powered content moderation
- Custom themes and branding
- WordPress plugin for one-click install
- Stripe billing (Free / Pro $19/mo / Business $49/mo)
Why I built it: Every community tool is either too complex (Discord requires users to leave your site) or too basic (most chat widgets are support-focused, not community-focused). There's a gap for lightweight, embeddable community chat.
2. WaitlistKit — Waitlist Management with Referrals
A tool for indie makers to collect signups before launch, with built-in referral tracking so your waitlist grows itself.
What it does:
- Create multiple waitlists
- Embeddable signup widget (single script tag)
- Referral tracking with unique links
- Subscriber management + CSV export
- Public waitlist pages (
/w/your-slug) - Email notifications via Resend
Why I built it: Every time I launch something, I need a waitlist. Existing tools are either $50+/mo or missing referral tracking. So I built my own.
The Stack (Same for Both)
Backend: Go + Fiber
Frontend: React 18 + TypeScript + Vite + shadcn/ui
Database: PostgreSQL
Auth: JWT
Payments: Stripe
Deploy: Coolify (self-hosted)
Why Go?
I know everyone's shipping with Next.js these days, but hear me out:
- Single binary deployment — no node_modules, no runtime dependencies
- Insanely fast — cold starts under 50ms
- Concurrency built-in — goroutines for WebSocket connections
- Small memory footprint — my chat server handles thousands of connections on 128MB RAM
For a solo developer shipping fast, Go is underrated. The standard library covers 80% of what you need.
Why shadcn/ui?
Because it's components you own, not a library you depend on. Copy-paste what you need, customize everything, no version lock-in. Combined with Tailwind, it's the fastest way to build good-looking UIs.
The Strategy: Product Factory
I'm not betting everything on one product. The plan:
- Ship 1-2 products per week (reuse the same stack)
- Launch everywhere — DEV, Product Hunt, HN, Reddit, Twitter
- Watch the numbers — which one gets traction?
- Double down on winners, kill losers
The goal: $10K MRR in 3 months across multiple small products.
Why this works better than building one thing for 6 months:
- You learn what people actually want
- You build distribution (audience) across launches
- Each product cross-promotes the others
- If one fails, you haven't lost everything
What I Learned
1. Reusable boilerplate is everything
Both products share the same Go backend structure:
cmd/server/main.go
internal/
config/
database/
handlers/
middleware/
models/
routes/
services/
migrations/
Once you have auth, CORS, database migrations, and error handling working, spinning up a new product takes hours, not days.
2. Ship ugly, iterate pretty
The first version of both UIs was basic. Functional, but basic. That's fine. Users don't care about pixel-perfect design — they care about whether it solves their problem.
3. Distribution > Product
Building in public on Twitter, posting on Reddit, writing on DEV — this matters more than the product itself in the early days. Nobody finds your SaaS by accident.
What's Next
- Product Hunt launch (next week)
- Stripe integration for WaitlistKit
- More products from the factory
- Documenting everything along the way
If you're interested in following the journey, I'm @egeindie on Twitter. Real numbers, real lessons, no fluff.
What's your approach to shipping fast? One product at a time or multiple bets? Would love to hear your strategies in the comments.
Top comments (1)
The "strategy" half is what makes this more than a flex - a repeatable stack you don't have to re-decide every time is the real unlock. Most of a weekend build's time goes to re-litigating settled questions (which auth, which DB, which deploy), so having a default stack you trust turns a weekend into actual product time. That's the meta-lesson: speed comes from not re-deciding the boring stuff.
The natural endpoint of "I have a repeatable stack and strategy" is automating the repeatable part entirely - which is basically what I built Moonshift into (a multi-agent pipeline that ships a prompt to a deployed SaaS on your own GitHub+Vercel). Your weekend stack, but the agent wires up the auth/billing/deploy defaults so you skip straight to the parts that are actually unique to each product, ~$3 flat per build, first run free no card. Same philosophy, more automated. Genuinely strong post. Quick one: across the 2, how much of the weekend was the unique product logic vs the repeated plumbing you'd already solved before? If plumbing was still a big chunk, that's the part most worth automating away.