"A full SaaS app with Stripe in 90 seconds" — a swarm of specialized model-agents building in parallel. Real, but bounded by an old law of parallel computing. Press BUILD. Drag to orbit.
An app build is a pipeline of phases. Some are sequential — the spec must exist before anyone codes, integration happens after the parts exist, deploy comes last. Others are parallel — frontend, backend, database and payments can be built simultaneously by different agents. Amdahl's Law (1967) says the sequential slice caps your speedup no matter how many workers you add:
speedup(N) = 1 / ( s + (1−s)/N ) → max speedup = 1/s
In this simulation the sequential work (spec, architecture, integration, deploy) is roughly s ≈ 0.31 of the total — so even an infinite swarm tops out near 3.2× faster than one agent. Slide the swarm from 6 to 12 and watch the predicted time barely move: extra agents idle once the four parallel tracks are staffed. That's why "add more agents" plateaus in real products too.
Boilerplate at superhuman speed: CRUD endpoints, auth scaffolding, Stripe checkout wiring, UI kits — patterns seen millions of times in training data. Parallel independent modules: when interfaces are crisp, four agents on four services really do finish ~4× faster. Tireless first drafts: a swarm gets you from zero to "something runs" faster than any human team, which is exactly what the 90-second demo shows.
Integration bugs: each agent's code is locally plausible, but Agent A's API returns camelCase while Agent B's frontend expects snake_case. The seams are where swarms break — and seams are sequential work. Spec ambiguity: "build a SaaS with payments" leaves a thousand decisions (trial length? refunds? webhooks retries?) that agents resolve by guessing differently. Compounding errors: a wrong early architectural choice propagates into every downstream agent's output. Review debt: the demo ends at "it runs," not "it's secure, tested, and handles Stripe webhook replay attacks." Production readiness is mostly the sequential 31%.
Swarms compress the parallelizable middle of software work toward zero. What remains — specification, interface design, integration, review — becomes the whole job. The 90-second video is real footage of the middle disappearing; the invisible part is the human hours before (deciding what to build) and after (verifying it). Speed is the demo; verification is the product.
Work units per phase (at MVP complexity): spec 8, DB 6, backend 10, frontend 10, payments 6 (parallel group), integration 6, QA 8 (max 3 agents help), deploy 3. Complexity multiplies parallel work ×1–2.5 and — realistically — sequential work even more (×1–3), because bigger apps mean more interfaces to reconcile. One agent processes 1 unit/sec on screen.
At the default complexity two, parallel work is multiplied by one point five and sequential work by one point six seven. Specification, integration and deployment total twenty-eight point three nine modeled seconds. Database, backend, frontend and payments have durations nine, fifteen, fifteen and nine. The scheduler assigns these whole tasks longest-first across at most four workers; with six configured agents the parallel group takes fifteen seconds. QA has twelve work units divided across at most three workers, taking four seconds. The total is forty-seven point three nine seconds versus eighty-eight point three nine for one agent. These are source-defined estimates, not real software builds. The bars use five pixels per modeled second. Increasing the configured swarm from six to twelve does not shorten the default schedule. The four-task group caps worker allocation at four, QA caps at three, and the serial phases keep one worker. Both schedules remain forty-seven point three nine modeled seconds. Speedup is roughly one point eight seven relative to the solo sum. Efficiency, speedup divided by configured agent count, falls from about thirty-one percent to about sixteen percent. A dozen animated agent objects are not twelve useful schedule workers, and this page is not running Codex authors or a backend fleet. The bars use the same duration scale to show equality rather than imply additional capacity automatically improves throughput. The displayed Amdahl ceiling is solo work divided by serial work, about three point one times at default complexity. That bound imagines all parallel work disappearing; the actual scheduler retains a fifteen-second group and four seconds of QA, so it reaches only about one point eight seven. The bars compare the ideal serial floor to the source schedule at five pixels per second. The simulator never generates application code or deploys a product; it animates phases. Offline Three is blocked, causing the original script to fail during scene creation, while earlier control listeners exist. Native verification must disclose that failure and preserve the existing viewport spacer and layout behavior. This video invokes no model backend or publishing.