Weekend Micro-SaaS Series

A playbook for shipping many small SaaS products as a portfolio, constrained to a single weekend each, sharing a single infra footprint, and distributed through marketplaces or uncontested niches.

The abstract pattern. mini-apps/overview is kulify’s concrete instance; this page is the rules of the game, decoupled from the current portfolio.

Why a series instead of one big product

The default solo-founder path — pick one idea, spend 6 months, hope it works — has bad expected value. The series flips the variance budget:

One product: high variance, single bet, optimization target = “this works”
Series: low variance per product, portfolio bet, optimization target = “≥1 of these works + the rest cover infra”

The series only beats the single bet when per-product cost is low. That’s what every rule below exists to enforce.

The five rules

A candidate product is in if at least four of five hold. Most ideas fail; that’s the point.

#	Rule	Why
1	Buildable + deployable in one weekend by one person	The fixed cost of a failed product must be ~16h, not 6 months
2	No/minimal database and no own billing for v1	Stateless = no migrations to maintain; marketplace billing = no Stripe to build
3	Distribution channel exists (marketplace, directory, SEO, niche)	Cold outreach is incompatible with 2 hrs/week upkeep per product
4	Recurring or per-call revenue	One-off sales force constant marketing — kills the portfolio model
5	Reuses the shared infra pattern	Per-product ops overhead must stay near zero or the portfolio collapses under maintenance

These are not aspirational — they’re a brutal filter. If you find yourself arguing why a product is worth breaking a rule, you’ve found a single-bet product, not a series candidate. Park it.

The shared substrate

Every product in the series sits on the same infra:

                  ┌─────────────────────────────────────────┐
                  │              Cloudflare zone            │
                  │  (DNS, cache, WAF, hide origin IPs)     │
                  └──────────────────┬──────────────────────┘
                                     │
                  ┌──────────────────▼──────────────────────┐
                  │              Coolify host               │
                  │       (one Hetzner box, many apps)      │
                  │                                         │
                  │  app-1 ─┐                               │
                  │  app-2 ─┼─→ Redis (shared, multi-DB)    │
                  │  app-N ─┘                               │
                  │                                         │
                  │  + Postgres for the few that need it    │
                  └─────────────────────────────────────────┘

The host is fixed. Adding a product = new Coolify app, same Dockerfile template, same [name].kulify.me subdomain pattern.

Idle products cost effectively €0 (no DB, no compute when no traffic). Winners amortize the host. The portfolio breakeven on a €40/mo host is one €50/mo product.

Two product lanes

The series runs two lanes against the same substrate:

Lane A — Demand-proven categories

Categories where demand is known and incumbents are doing fine (Microlink for URL intel, ScreenshotOne for screenshots, “AI extraction” wrappers). You enter on price, simplicity, or a feature gap. Predictable revenue per product, predictable build time, low variance.

Example for kulify: url-intel/overview, the MCP wrapper, AI extraction API.

Lane B — Demand-radar bets

Trend-sourced quick builds against rising queries with tool intent. (demand-radar describes the pipeline.) Each is a portfolio bet: €50–500/mo each, occasional breakout.

Lane A is predictable income. Lane B is upside. Run both, weight time toward A early, shift toward B as A funds the portfolio.

Selection process

Idea pops up (your head | demand radar | conversation)
      │
      ▼
Five-rule gate ── fail any 2+ ──→ Park (with reasons)
      │
      ▼ pass ≥ 4
Competitive check (3 marketplaces, 3 SEO pages)
      │
      ├─ already commoditized to floor pricing ──→ Park
      │
      ▼
Sizing: weekend build vs partial-weekend?
      │
      ▼
Validate (one-pager + pre-sale button or marketplace listing)
      │
      ├─ ~200–300 visitors, 0 signups ──→ Change the IDEA, not the copy
      │
      ▼
Build (weekend) → Ship → Measure → Iterate or idle

Time budget

A working series rhythm looks like:

Slot	Activity	Hours
Weekend (every 1–2 weeks)	Build / launch a product	8–16
Weeknight (weekly)	Demand radar review + small tweaks	2
Per-product (after launch)	Updates, support, bug fixes	~2 / month

10 live products = ~20 hrs/month maintenance. 20 = ~40. Past that, kill the laggards or productize the ops layer (status pages, automated billing escalation, etc.).

Validation: charge from day one

The biggest mistake the playbook warns against: free tier as a strategy, not a hook.

Free tier = acquisition funnel. Caps at the level where someone with real use must upgrade (e.g., 50 calls/mo for URL intel).
Paid tiers from day one. No “we’ll figure out pricing later.”
~200–300 visitors to the marketplace listing with zero signups = the idea is wrong, not the copy. Move on.

The faster you charge, the faster you learn whether the product matters.

Killing products

A live product is killed (or quietly idled — same thing) when:

Revenue covers neither host share nor maintenance time
A competitor moves to a price point you can’t profitably match
The marketplace changes terms in a way that destroys margins
Maintenance burden creeps past 4 hrs/month consistently

Killing is fine. The portfolio model expects it. Park the docs (note the reason in shipped.json / equivalent), let the Coolify app idle, move on. Don’t sunk-cost.

Bias picks toward what you know

The BACKLOG’s strongest rule: domain knowledge is the #1 predictor of success. Pick categories where you can:

Recognize good UX without user testing
Spot the missing feature competitors are too big to ship
Talk to customers in their language
Diagnose problems from a stack trace, not a support ticket

For kulify: dev-tools / infra (what kula knows) and Dalmatia / tourism (where kula lives — “big swing” once the portfolio funds the in-person validation needed).

Avoid: regulated verticals (compliance), CAD/lab/scientific (domain you don’t have), team-collaboration tools (need sales motion).

Failure modes the playbook prevents

Without the playbook	With the playbook
6 months building one product that no one buys	16 hours building one product; learn fast, move on
Stripe + auth + dashboard burn every product launch	Marketplace handles it; 20 lines of middleware
Cold outreach exhaustion	Marketplace discovery is the channel
Infrastructure cost per product = €40/mo	Shared host; marginal product cost ≈ €0
No idea pipeline → ideas dry up after 2 builds	Demand radar keeps the candidate queue stocked

Relationship to other patterns

Pattern	How it fits
marketplace-distribution	Rule 3 (distribution channel) — marketplaces are the cheapest way to satisfy it
ssrf-guard, headless-browser-pool	Reusable building blocks; second URL-fetching product gets these for free
demand-radar	The idea pipeline for Lane B
Model Context Protocol	A second marketplace channel layered on the same backend

Where this matters in kulify

mini-apps/overview is the umbrella where this plays out concretely. The playbook applies to that program specifically; it explicitly doesn’t apply to fajb-next (work project, custom contracts), katastar (regulated data + government users), hegnar-web (FA’s flagship), or manzas (B2B SaaS with dashboards).

mini-apps/overview — kulify’s concrete instance of this playbook
url-intel/overview — first product in the series
marketplace-distribution — the channel pattern that makes rule 3 satisfiable
demand-radar — the idea pipeline for Lane B
ssrf-guard, headless-browser-pool — reusable building blocks across the series
coolify — the shared substrate