Abstract

We deployed 43 browser-based AI tools—spanning image generation, video creation, photo editing, and design—across a unified domain portfolio in under one week using a coordinated swarm of AI coding agents. This article documents the architecture, coordination protocols, and failure modes we encountered, with practical lessons for teams building multi-agent development systems.

The Problem

A solo founder with 90+ repositories needed to ship a portfolio of AI-powered web tools quickly. Each tool shared a common template (Next.js 16, Stripe billing, fal.ai generation backend) but required product-specific customization: unique UI themes, model configurations, SEO metadata, and pricing tiers. Traditional serial development—one product at a time—would have taken months.

Architecture: The Clone Factory

We built a saas-clone-template containing the shared infrastructure: authentication (Better Auth + Google OAuth), payment processing (Stripe checkout + webhooks with advisory-lock idempotency), credit-based billing, rate limiting, and i18n support for English and Spanish.

Each new product was scaffolded by copying the template, customizing 8 configuration files (site config, product config, API route, generation service, theme, metadata, pricing, FAQ content), and deploying to Vercel with a *.symplyai.io subdomain.

The key insight: differentiation lives in configuration, not code. The generation route, auth flow, billing webhook, and rate limiter are identical across all 43 products. Only the fal.ai model ID, theme colors, marketing copy, and pricing change.

Coordination: BridgeMind + File Ownership

The swarm operated under a single coordination protocol:

  1. BridgeMind (an MCP-based task management system) served as the single source of truth for task ownership. Before writing any code, agents queried BridgeMind for existing tasks to avoid duplicate work.

  2. File ownership was tracked per swarm wave. Each agent declared which files it would modify, and no two agents could edit the same file simultaneously.

  3. Computer control (VCC/BCL) for browser-based tasks (account creation, DNS configuration, dashboard verification) was serialized through a single operator agent (BC1) with a mutex protocol: CLAIM → WAIT → RUN → RELEASE.

  4. Swarm messages (.swarmmessage files) provided real-time coordination. Each agent maintained one file with their current work, planned work, and overlap checks.

Failure Modes and Mitigations

1. Template Bugs Multiplied Across Clones

Every bug in the template propagated to all 43 products. We identified 5 recurring template bugs (auth mismatch, Stripe build-time crash, missing exports, outdated API version, peer dependency conflicts) that each builder independently discovered and fixed. The fix: template bugs must be fixed upstream first, then propagated.

2. Advisory Lock Idempotency vs Read-Then-Write

Our Stripe webhook initially used a read-then-write pattern for credit deduplication. Under concurrent Stripe retries, this was race-prone. We migrated to Postgres advisory transaction locks (pg_advisory_xact_lock(hashtext(reason))) which serialize concurrent deliveries on the same key, achieving practical exactly-once credit allocation.

3. Google Doesn’t Know Your Sites Exist

The most surprising finding: after deploying 43 production sites with sitemaps, robots.txt, and structured data, Google had indexed fewer than 5 of them after one week. The bottleneck was backlinks and discovery, not technical SEO. Internal cross-linking between indexed and unindexed sites, GSC sitemap submissions, and IndexNow API calls were the actual accelerants.

4. Rate Limiting Before Auth

Clone apps using next-intl middleware had a matcher pattern that explicitly excluded /api/ routes: /((?!api|_next|_vercel|.*\\..*).*). This meant zero middleware protection on any API path. The fix was a per-route in-memory IP rate limiter that runs before auth and before vendor API calls, so over-limit requests cost zero credits.

Quality Gates

We established 10 mandatory quality gates for clone apps, including:

  • Build verification before push
  • Environment variable safety (graceful degradation at build time)
  • Post-deploy smoke tests with browser E2E proof
  • Cookie consent with GA4 consent mode
  • Privacy policy naming all data processors
  • Paid API exposure audit (no unauthenticated paths to billed vendors)

Results

  • 43 products deployed and live on HTTPS
  • 45/45 fleet health check: HTTP 200
  • 36/36 Playwright E2E tests passing on flagship product
  • Full CSP headers, rate limiting, and webhook idempotency across all Tier 1 products
  • 13 GSC sitemaps + 53 IndexNow submissions completed

Conclusions

Multi-agent swarms can dramatically accelerate shipping, but the coordination overhead is real. The winning pattern was: shared template + configuration-level differentiation + centralized task ownership + serialized computer control. The biggest lesson: shipping code is only half the job. Distribution, indexing, and conversion are equally hard and require their own automation strategy.

The portfolio is live at symplyai.io/tools.