usecases.sh
usecases.sh
Software & DevOps

Ship a SaaS in 30 days without typing any application code

A developer writing as Info Inlet banned himself from typing application code for a month and shipped a small SaaS with auth, Stripe billing, a dashboard and a public API, logging nine points where the rule broke.

What they did

The poster set one rule for 30 days: no application logic typed by hand. The AI writes; he describes, reads every line, rejects and re-prompts. Config, secrets and dashboard clicks stayed manual, and any time he was stuck for more than an hour counted as a logged break where he wrote the code himself. The product was a small SaaS with authentication, Stripe billing, a dashboard and a public API, scaffolded as a Next.js app with Postgres and Drizzle. The post never names the coding tool, only 'the AI'.

How it went

The product shipped and is in production. Scaffolding and boilerplate were one-shot and the first 40% went faster than anything he had built. He logged nine breaks: duplicate helpers and a second User type because the model could not see the rest of the codebase; a Stripe webhook handler that acknowledged events before persisting them, which would have left paying customers with no record after a database blip; a debugging loop where the model rewrote functions and reintroduced the bug; over-built settings pages and swallowed errors; and the last 10% of edge cases, which took three of the four weeks. He now runs a separate reviewer agent prompted to refute each diff and keeps a human on the merge.

Worth knowing

The author is pseudonymous and the post ends by pitching his own product, xenition, which sells the author, skeptic and human-merge pattern he describes. No repo, product name or metrics are shared, so the account cannot be checked. The Stripe webhook ordering bug is the concrete trap: ask for persistence before acknowledgement and verify it yourself.

Try it withCustom agent

For the next [30 days] you write all application code in [this repo] and I only describe, review and approve. Before each task, read the existing modules and reuse helpers, types and middleware that already exist instead of creating new ones; list what you reused. For [the billing webhook], persist the event before acknowledging it and show me the ordering. Keep features to what I asked for, no extra options. After each change, hand the diff to a second pass prompted to find why it is wrong, and show me both before anything is committed. Stop and ask when you cannot see enough of the system to be sure.

Square brackets are the parts to fill in. The prompt is ours; the story is theirs.

Where they said it

All Software & DevOps use cases

Every entry is something a person reported doing with an agent, rewritten in our words, with a link to where they said it. Found across the web every hour; reviewed before it ships.

Maintained by an agent that uses One for every integration it touches.