Stop Building Platforms: 6 Tiny SaaS Products Worth Shipping This Year

Six small products a solo backend engineer can ship in five months

Last year, I spent four months building a “platform.” It had multi-tenancy, a plugin system, and zero paying users. Meanwhile, a friend shipped a single-purpose tool in three weekends and had customers before I had auth working.

The lesson cost me a quarter of a year: the SaaS ideas still worth building in 2026 are small, boring, and attached to a deadline someone else created. Here are six of them, filtered through what I’d actually build with a Python/Go/AWS background and five months left in the year.

Why everyone tells you to build big (and why that advice is stale)

The standard playbook says find a large market, build a platform, and raise money. That advice exists because it’s how venture-backed companies work, and venture-backed companies write most of the content you read.

But if you’re one engineer shipping nights and weekends, your edge isn’t market size. It’s speed and specificity. You want problems where the buyer already knows they have the problem, ideally because a regulator, an end-of-life date, or a 3 a.m. page told them.

Every idea below has that property. None of them needs a novel algorithm. All of them need the thing most engineers skip: shipping.

1. A CRA Article 14 reporting copilot

On 11 September 2026, the EU Cyber Resilience Act’s reporting obligations kick in. Any manufacturer of “products with digital elements” sold in the EU must report actively exploited vulnerabilities and severe incidents: an early warning within 24 hours of becoming aware, a full notification within 72 hours, and a final report within 14 days of a fix (one month for severe incidents), all through ENISA’s Single Reporting Platform. It applies to legacy products already on the market, not just new launches. Source: the European Commission’s CRA reporting page.

Big vendors have legal teams. The long tail of small ISVs and hardware shops has nobody, and the clock starts in under two months.

The product: a deadline tracker plus structured report drafting. Product inventory in, PagerDuty-style escalation when someone flags a suspected exploited vuln, prefilled report templates with the 24h/72h/14d timers running visibly. You’re selling a workflow, not legal advice — say so explicitly in your terms.

Ship-by milestone: inventory + timers + templates. Skip SRP API integration until the platform’s interface stabilizes; export-to-clipboard is fine for v1.

2. A dependency EOL radar

Related, but sellable on its own: teams don’t know when their stack dies. PostgreSQL 14 stops receiving fixes on 12 November 2026 — it’s on the official versioning page — and I’d bet money most teams running it will find out from an incident, not a calendar.

The product: upload an SBOM (CycloneDX or SPDX), get back a mortality calendar for every component, with Slack/email alerts at 90, 30, and 7 days before each EOL. The raw data largely exists in endoflife.date, which is open source. Your value is the mapping — from their actual dependency graph to those dates — plus the nagging.

The CRA gives these teeth: shipping EOL components into the EU is shifting from a risk decision to a compliance question. That’s your cold email opener.

Ship-by milestone: CycloneDX parser, endoflife.date matcher, and one Slack integration. A weekend each.

3. A backup restore verification service

Everyone has backups. Almost nobody has restored. I learned this the standard way: a client’s nightly pg_dump had been silently producing truncated files for six weeks because a cron wrapper swallowed a disk-full error. The backup job was green the whole time.

The product: nightly, pull the customer’s latest dump, spin up a throwaway database, restore it, run their assertions (row counts, critical tables exist, latest timestamp is recent), and send a report. Charge per database. The pitch writes itself: “your backups are Schrödinger’s data until you restore one.”

Here’s the core loop as a script — this is genuinely most of the MVP. Tested against PostgreSQL 18.4 (current stable as of this writing, per the May 2026 release announcement) with Docker on Linux, bash 5:

#!/usr/bin/env bash
# restore-check.sh — verify a pg_dump custom-format file actually restores.
# Usage: ./restore-check.sh /path/to/dump.custom
set -euo pipefail

DUMP="${1:?usage: restore-check.sh /path/to/dump.custom}"
CONTAINER="restore-check-$$"

docker run -d --name "$CONTAINER" -e POSTGRES_PASSWORD=throwaway postgres:18.4 >/dev/null
trap 'docker rm -f "$CONTAINER" >/dev/null' EXIT

until docker exec "$CONTAINER" pg_isready -U postgres -q; do sleep 1; done

docker exec "$CONTAINER" createdb -U postgres restorecheck
docker cp "$DUMP" "$CONTAINER:/tmp/dump.custom"
docker exec "$CONTAINER" pg_restore -U postgres -d restorecheck \
  --no-owner --exit-on-error /tmp/dump.custom

TABLES=$(docker exec "$CONTAINER" psql -U postgres -d restorecheck -tAc \
  "SELECT count(*) FROM information_schema.tables WHERE table_schema='public'")

if [ "$TABLES" -gt 0 ]; then
  echo "OK: restore succeeded, $TABLES tables present"
else
  echo "FAIL: restored zero tables"
  exit 1
fi

The SaaS wrapper is scheduling, credentials handling, customer-defined assertions, and the report email. That’s it.

4. A webhook inbox with replay

If you’ve integrated Stripe, GitHub, or any payment provider, you know the pain: webhooks fail silently, local development is miserable, and “can you resend that event from Tuesday?” is a support ticket.

The product: a durable receiving endpoint that verifies signatures, stores every event, and replays them on demand — to localhost via a tunnel, to staging, or back to prod after you fix the bug. Add per-endpoint filtering and transformation, and you’ve got something teams pay for monthly without thinking.

Yes, competitors exist in this space. That’s evidence of a market, not a reason to quit — your wedge is a specific niche (say, EU payment providers, or a specific framework’s idioms) and better developer experience. In Go 1.26 (current release, go.dev/doc/go1.26), the entire ingest path is a few hundred lines of net/http and a Postgres table.

Ship-by milestone: receive, verify HMAC, store, replay. Charge before building transformations.

5. A Kubernetes rightsizing report

Every cluster I’ve audited had the same disease: resource requests set once, during a panic, then never touched. The result is paying for a CPU nobody uses while the one-starved deployment OOMKills weekly.

The product is deliberately not an autoscaler. It’s a read-only agent that compares requests against actual usage over 30 days, then emails the platform team a weekly report with PR-ready YAML patches. Recommendations, not actions — that’s what makes it installable without a change-review board meeting.

I won’t quote savings percentages because I’d be making them up, and vendors in this space already inflate enough. What I saw in my own audits, representatively: the gap between requested and used resources was consistently large enough that the report pays for itself the first month. Let the customer’s own numbers make the argument.

Ship-by milestone: agent reading metrics-server data, one report template, Helm chart install.

6. An IAM least-privilege digest

AWS accounts accumulate permissions like attics accumulate boxes. Everyone knows their IAM policies are too broad; nobody has time to prove which permissions are actually unused across twelve accounts.

AWS ships native tooling here (IAM Access Analyzer), so be honest about the overlap. Your wedge is the workflow: a cross-account weekly digest, human-readable (“this role hasn’t used s3:DeleteObject in 90 days”), and generated pull requests that tighten the policy in Terraform — because a finding without a PR is just guilt.

This one has the longest sales cycle of the six, because the buyer is a security lead, not a developer. But it also has the stickiest retention, because auditors ask for exactly this evidence every year.

Ship-by milestone: CloudTrail analysis for one account, one readable report. Multi-account comes after the first customer demands it.

Where this advice breaks

Don’t build any of this if you want a venture-scale outcome. These are €2–20k MRR businesses. That’s a life-changing side income and a terrible pitch deck.

Don’t build the compliance-adjacent ones (1, 2, 6) if you’re unwilling to write careful terms of service. You are selling tooling and reminders, not legal or audit opinions, and blurring that line is how solo founders get hurt.

And run the payment math before you pick a price point. A merchant of record like Paddle charges an all-inclusive rate — 5% + $0.50 per transaction on the standard plan at the time of writing (paddle.com/pricing) — which is a great trade at $30/month per seat and a punishing one on $5 micro-plans, where the flat fifty cents alone is 10% of the ticket. The price is high enough that the fee disappears into the margin.

Finally, an idea on this list is worth nothing. Six of them shipped as landing pages with a Stripe or Paddle link, and one validated with ten paying users — that’s worth a lot.

Takeaways

• Pick problems with external deadlines: the CRA’s 11 September 2026 reporting start and PostgreSQL 14’s 12 November 2026 EOL are urgent issues you didn’t have to manufacture.
• Sell reports and workflows before automation. Read-only tools get installed; write-access tools get meetings.
• The MVP for most of these is a script, scheduling, plus email. Resist the platform urge — I lost four months to it, so you don’t have to.
• Competition is validation. Your wedge is a niche and better DX, not a bigger feature grid.
• Price for merchant-of-record fees from day one; flat per-transaction fees quietly kill cheap plans.

I write weekly about DevOps, backend engineering, and security — follow for the next one.