How We Shipped 31 SaaS Products in a Single Saturday

I want to describe what a typical Dangercorn build day looks like, because it's the thing that makes the whole strategy work and it's the thing that sounds most implausible when you hear it described.

On Saturday, March 14, we shipped 31 new vertical SaaS products. Thirty-one. Not "31 landing pages." Not "31 repos with a README." Actual working Flask apps, each with a real domain, a real landing page, real features, real SQLite-backed data, and a public GitHub repo under the Dangercorn-Enterprises org. Most of them have AI features powered by our shared Claude wrapper. All of them have a $0 self-host tier and a hosted plan. From template-clone to deployed: about 15-25 minutes per vertical.

Here's what the day looked like and what made it possible.

6 AM — Coffee and a List

I started the morning with a list of 35 candidate verticals that had been sitting in the backlog. Each had a one-line description from when Jess and I had brainstormed it weeks earlier. Things like "shift scheduling for hourly staff," "book club CRM," "catering event manager," "homeschool portfolio generator."

The rule was: if I couldn't picture the user and the features clearly by the end of the coffee, the vertical got dropped for today. Four got dropped. That left 31 on the shipping list.

7 AM — The Spec Generator

Each vertical starts as a spec.json file in scripts/specs/. The spec has a slug, an emoji, a title, a tagline, a hero description, six feature blocks, pricing tiers, a pro/top feature list, and a list of related products for cross-linking. Claude writes the first draft of the spec given the one-line description, I edit it for voice and to kill anything that sounds too SaaS-y, and we're done in about two minutes per spec.

By 8 AM I had 31 spec files sitting in the repo, each around 40 lines of clean JSON. These are the source of truth for both the landing page and the app features.

8-11 AM — Landing Pages

We have a Python script called build_landing.py that takes a spec.json and outputs a full Dangercorn-style landing page with the house design system baked in — gold on deep brown, DM Serif Display headings, the whole kit. The command is roughly:

python scripts/build_landing.py scripts/specs/shiftfill.json net/shiftfill/index.html

Each landing page took about 6-8 minutes on average, including me re-reading the hero copy and cleaning up anything that sounded like it was written by an LLM that hadn't met a real human in weeks. "Leverage" and "unlock" are banned words. So is "transform." If the generated text used those, I re-wrote those sentences by hand.

By 11 AM, 31 landing pages were done, all following the same visual grammar as the cheesemaking and honeybees pages that were already live.

11 AM - 2 PM — The Flask Apps

This is where the template earns its keep. Every Dangercorn vertical starts as a clone of dangercorn-saas-template with a rename script that swaps in the new slug. Out of the box you get: Flask + Jinja, SQLite with a schema helper, single-password auth, Stripe wiring, deterministic port assignment via dcst.config, a base template that matches the landing page design, a shared Claude wrapper via dcch, and a GitHub Actions CI that runs on every push.

For each vertical, the work is:

Clone + rename: 30 seconds.
Write the 2-4 core models (e.g., Hive, Queen, Inspection for honeybees). Claude drafts the SQLAlchemy models from the feature list in the spec. 3-5 minutes.
Write the handful of Flask routes (index, CRUD pages for each model, auth). 5-8 minutes.
Templates. We have a library of Jinja fragments for common patterns (CRUD list, detail view, form). 3-5 minutes.
Any AI feature that the spec calls for (the vision frame reader, the discussion question generator, etc). Most of these are a single function call into the shared Claude wrapper. 2-4 minutes.

Total per vertical: around 15-25 minutes. Faster when the vertical is close to one we've already built. Slower when it has an unusual feature that needs custom work.

2-4 PM — Deploy Pipeline

Push to main. The GitHub Action runs the test suite, builds a wheel, and our deploy script drops the app onto a fleet node with a deterministic port assignment so nothing collides. The landing page deploys via Vercel on push.

By 4 PM, every vertical had a live landing page, a running app on its assigned port, and a GitHub repo with a clean first commit.

4-6 PM — Sitemap, Products Page, QA

The last pass: update net/sitemap.xml with the new URLs, extend the products page to include the new verticals, click through each landing page to catch any typos or broken links. I found about six small issues across the 31 pages — a bad anchor link, a pricing tier with the wrong number, a feature description that still had a placeholder in it. Fixed them, pushed, done.

At 6:30 PM I closed the laptop. 31 new products shipped.

What Made It Possible

It wasn't one thing. It was a stack of things that had been built up over months before this Saturday:

The template itself — dangercorn-saas-template handles the 80% that every app needs. I wasn't reinventing auth or Stripe or port assignment on the 17th vertical.
The shared Claude wrapper — dcch means AI features are one import + one function call.
The landing page generator — consistent design means I don't redesign every vertical.
The deploy pipeline — push to main, done. No manual server config. No fiddling with ports — deterministic port assignment handles that.
Claude as the second pair of hands. Claude wrote the first draft of most spec files and most model definitions. I edited, kept the voice, deleted the fluff, kept the code.

You don't ship 31 products in a day by working fast. You ship 31 products in a day because you spent four months making each individual ship take 15 minutes instead of 15 days.

What This Doesn't Mean

I want to be clear about something. Shipping is not the hard part. Shipping 31 apps on a Saturday doesn't mean we have 31 businesses on Sunday. Each of those apps now has to find its audience, earn its first users, maybe get its first paying customer. That process takes months to years, and most of them will plateau at modest numbers. Some will never find product-market fit at all.

Shipping fast is the precondition for the 220-app strategy, not the strategy itself. The strategy is: ship fast, distribute broadly, watch which ones start to show signal, then invest more time in those. You can't run that strategy if each app takes a month to build, because you can't afford to be wrong 200 times. You can afford to be wrong 200 times if each wrong guess cost 20 minutes.

The 31 products from that Saturday are live now. A couple have started picking up users organically. Most haven't. That's the expected distribution and it doesn't change anything — we'll do it again next month with the next batch.