The 20 SaaS Gauntlet: Why we're building a product every weekend

Follow our journey as we build 20 micro-SaaS products using Swirls to test and prove our AI workflow infrastructure.

byCJ Brewer

We're stuck.

Not the bad kind of stuck, more like the kind where you realize the thing you're building is way bigger than you thought, and you need to make a call on what to do about it.

Swirls was supposed to be straightforward. A graph-based workflow platform for deterministic AI operations. The kind of thing GTM engineers and dev shops could use to build type-safe integrations without burning thousands of tokens on orchestration.

But as we've been building it out, we keep bumping into the same reality: this isn't just a nice-to-have tool. It's actually becoming infrastructure for how you build AI-powered systems.

The market timing problem

We had a good chat with our buddy Drew from dbt Labs and he shared his playbook to success: You build the thing, you go do consulting, you implement it at a handful of like-minded customers, you iterate based on their feedback, and eventually you have a product ready for broader release.

That timeline made sense when shipping an application took months. Maybe a really good weekend if you were hustling.

Now? People are shipping in five minutes.

The irony is brutal. As we are building a product for AI workflows, AI tools have made development so accessible that the traditional "build, polish, launch" approach feels outdated before you even finish the polish phase. Claude Cowork, OpenClaw, etc. are moving fast and solving adjacent problems.

Swirls is still the most deterministic option for daily workflows and application development. We genuinely believe that. But belief doesn't equal adoption, and adoption requires proof.

Dogfooding

So we're trying something different.

Starting this weekend, we're building a micro-SaaS product on top of Swirls. Then we're doing it again next weekend. And the weekend after that. Goal: 20 products over the next 3-6 months.

Same tech stack every time to keep costs low: TanStack Start for the app framework, Better Auth for authentication, SQLite for the database. We're bootstrapped, so this needs to be lean.

First up: FormFlip.

It's deliberately simple. Open source self-hosted forms (think Typeform, but yours) that trigger Swirls workflows when someone submits. Process the data through an LLM, email you the results, maybe ping Slack. Charge $5 a month, keep the pricing generous, don't let users do anything too wild.

Nothing fancy. Just a working product that solves a real problem using Swirls under the hood.

Why this might actually work

If we can pull off 20 of these, we'll have something no amount of polishing in isolation could give us: real-world validation across different use cases.

Each product becomes a stress test. Each implementation surfaces edge cases we wouldn't have thought of. Each integration proves (or disproves) whether Swirls actually delivers on the promise of making AI workflows less painful to build and maintain.

We're essentially forcing ourselves into a position where we can't hide behind "we're still building it." Either Swirls makes it easier to ship these products, or it doesn't. Either the abstractions hold up under different requirements, or they fall apart.

Plus we're building the kind of products our target users would actually build. GTM engineers aren't trying to recreate Claude Opus 4.6. They're trying to automate lead enrichment, process form submissions, sync data between tools, generate reports. Practical stuff.

By the time we open the waitlist, we won't be asking people to trust our vision. We'll be showing them 20 working examples of what's possible.

The uncomfortable truth

This could absolutely backfire.

Maybe we ship three products and realize Swirls isn't ready. Maybe the weekend cadence is unsustainable. Maybe nobody wants to pay $5/month for a one of the products because there are already a dozen alternatives that do the same thing.

But holding off to build the "perfect" platform feels riskier right now. The market is moving too fast. Developer expectations are evolving too quickly. The gap between "I want to build this" and "I built this" is shrinking by the day.

We'd rather learn fast and adapt than polish ourselves into irrelevance.

So that's the plan. Build, ship, repeat. Use Swirls to prove Swirls. See what breaks, fix it, keep moving.

First product drops this weekend. Let's see what happens.