Fully functional web app with Neon (in 40 minutes)

Forty minutes. That is roughly what sat between an empty repository and pastmonday.com taking signups — auth, a weekly calendar, tiered billing, referral credits, file uploads, and an AI chat that reads the user's own calendar. Work that used to be a quarter of somebody's year, described to an agent in plain English and shipped before the coffee went cold.

We are not that interested in the speed, honestly. Speed is what every demo advertises. What made this run worth writing up is where the human time went: four reusable skills carried the build stage by stage, and the person at the keyboard spent almost all of those forty minutes at approval gates, looking at screens and deciding whether they were good enough. No glue code, no tab full of API docs. An older industry has a word for that arrangement — a factory — and the longer we sat with it the less it felt like a metaphor.

TL;DR

• Four staged skills — foundation, landing page, backend, dashboard — took an agent from an empty repository to a shipped product in about forty minutes.
• The human time went into approval gates between stages: taste decisions, not integration work.
• The entire backend is one vendor. Neon Postgres holds the data, Neon Auth holds identity, the Data API serves reads, object storage takes the uploads, and the AI gateway routes the chat — plus Stripe for money.
• Every operation that touches money or limits is a single atomic SQL statement. Quota first, then credits, else nothing gets inserted.
• The skill is the how. The brief is the what. Same four skills, different one-page brief, different product next time.
• You can run the whole line yourself — the four stages are on the shelf below, and the second half of this post is the how-to.

Resources

The factory, the product it shipped, and the platform it runs on:

The line, at a glance

One page goes in, a product comes out, and a human stands at four gates in between. Everything else in this post is detail on this picture.

Each diamond is a stop. The agent does not roll through them; it parks, shows its work, and waits. The four stops are the entire human footprint on the build.

The brief is the what

A factory only works if the spec and the production line are separate things. Here the line is the four skills — each one an opinionated, staged procedure with its own gates and its own banned-pattern lists. The spec is a single page called PROJECT.md: what the product is, who it is for, what the tiers cost, which reference sites the design should argue with. The skills never learn what you are building. The brief never says how.

# PROJECT.md — the one page the factory reads

What: a weekly review app — plan Monday, review Friday.
Who: individual operators who live in their calendar.
Tiers: free (1 entry, small AI budget), pro, max.
Design: warm, editorial, no dashboard-gray. Reference: (two sites).
Voice: direct, second person, no exclamation marks.

This is the part that makes forty minutes repeatable instead of a stunt. Point the same four skills at a different page and you get a different product built to the same standards — same schema conventions, same quota paranoia, same design gates. When a stage produces something you dislike, you improve either the brief or the skill, and the fix carries into every future run. A prompt gets you one app. A line gets you the next one too.

Running the line yourself

Before anything else you need accounts and keys, and it is the least glamorous five minutes of the process: a Neon project (the free tier is fine to start), a Stripe account in test mode, an empty git repository, and an agent that runs skills — we used Claude Code. Then stock the shelf. Each listing on the site has a copy button for its install prompt; pasted into your agent, it pulls the files down and the skill shows up as a slash command:

Install this skill:
api.generalized.dev/install/kubeden/set-project-structure

Install this skill:
api.generalized.dev/install/kubeden/set-landing-page

Install this skill:
api.generalized.dev/install/kubeden/set-app-backend

Install this skill:
api.generalized.dev/install/kubeden/set-dashboard-gated-app-ui

Write your PROJECT.md (steal the shape above), drop it in the repo root, and run the stages in order. The sequence looks like this from the inside:

$ mkdir pastmonday && cd pastmonday && git init
$ # write PROJECT.md, then:
$ claude

> /set-project-structure
    reads the brief, asks what it can't infer, lays the skeleton:
    schema, env keys, design tokens, placeholder service clients.
    STOPS — approve the plan before any UI exists.

> /set-landing-page
    real copy from the brief, marketing page, motion.
    STOPS at a design gate — approve it or say what's off.

> /set-app-backend
    wires auth, data, storage, AI gateway, Stripe, quotas.
    STOPS once, at a plan gate, before touching money.

> /set-dashboard-gated-app-ui
    app shell, calendar, settings modal, streaming chat —
    then reviews its own screens before handing over.

Between the first and second stage there is a chore the fence above glosses over: the foundation stage leaves an env file full of named slots, and you fill them — the Neon connection string, the Stripe test keys, the auth secrets. Five minutes of copy-paste from two dashboards. After that the stages pick their keys up from the seams the foundation laid, which is the point of laying seams.

Two pieces of advice from having done it. First, do not rubber-stamp the gates — they are the only place your taste enters the product, and a stage will happily regenerate against specific complaints ("the hero type is too tight, the tier cards read like pricing spam") far better than vague ones. Second, resist the urge to touch the code between stages. If something bothers you, say it at the gate. Editing under a running factory is how you end up owning the glue again.

What each stage actually did

Stage one, the foundation. It reads the brief, asks about anything it cannot infer, and lays everything the later stages will stand on — then stops before a single screen exists. The gate here is a plan review: you are approving a schema and a set of seams, which is the cheapest possible moment to change your mind.

Stage two, the landing page. Real copy from the brief, tasteful motion, and a banned-pattern list that refuses the generic AI-landing look by instruction rather than by luck. This is the gate we lean on hardest, because a marketing page is pure taste.

Stage three, the backend. The stubs become a server-authoritative backend: auth, data, storage, AI routing, payments, quotas. One plan gate before it touches money, and every enforcement rule lands in the database rather than in a client that can be argued with.

Stage four, the dashboard. The product itself — app shell, the weekly calendar with its entry modals, settings and billing, the streaming chat that reads the user's own calendar. It reviews its own screens against the design language before asking for the last approval, which catches most of the visual drift before you ever see it.

Four stages, four stops. Everything between the stops — the part that used to be the job — ran without a hand on the keyboard.

One vendor, five services

The backend consolidated on Neon entirely, and the shape of it matters more than the logo. Postgres holds the data. Neon Auth holds identity, and the factory has a hard rule about it: never mirror the auth schema. Application tables hold foreign keys straight into the auth schema's user table, so there is no sync job and no second source of truth to drift out of agreement at 2 a.m. The Data API serves HTTP reads. Object storage takes uploads through presigned PUTs — and since Neon's storage branches with the database, a preview environment gets matching files and rows rather than production leftovers. The AI gateway routes the chat and meters the tokens.

Two of the five services were in private preview during the run, which produced our favorite moment of the build. The gateway's official SDK provider was not installable yet. The agent did not stop to complain. It probed the gateway, found the OpenAI-compatible endpoint, and wired the chat against that instead. If your primitives answer HTTP, agents will integrate you before your SDK ships — that is not a prediction, it happened here, against a preview service, unsupervised.

Money is one statement

The backend stage carries one conviction worth spelling out: a feature can be wrong and apologize later. Money cannot. So every operation that touches billing or limits compiles down to a single atomic SQL statement. Creating an entry checks the tier's quota and spends the credit inside the same statement that inserts the row — quota first, then credits, else nothing gets inserted. Two concurrent requests cannot both squeeze through the last slot of a free tier, because there is no gap between the check and the write for them to race in.

Stripe gets the same paranoia. Webhooks are deduplicated against an event-id ledger, so a retried delivery cannot credit an account twice. The tiers — one entry and a small token budget free, ten entries and a bigger budget on pro, unlimited above — are enforced where the data lives, not in a client that can be talked out of its convictions. None of this is exotic. It is exactly the discipline that erodes first when a tired human is hand-integrating five services at 11 p.m., and it is the reason the backend skill exists: the rule got written down once, and now it does not get forgotten.

A full working SaaS — identity, data, files, AI, money — now fits in one brief, four skills, one backend vendor, and one Stripe account.

The product, forty minutes later

Receipts, as always. This is what came off the line — no design pass afterward, no cleanup sprint, the screens as the fourth stage left them.

Where the assembly line points

While we were publishing factory skills that teach agents to build on Neon, Neon started shipping agent skills that teach agents to use Neon. Nobody coordinated that. The factory and the platform are meeting in the middle anyway, and that convergence is our answer to the question in the title. When the whole process is automated, producing a working web application stops being the scarce thing — the way weaving cloth stopped being the scarce thing. What is left over is the brief and the gates: knowing what is worth building, and having the taste to say "no, again" at four checkpoints. That was the entire human contribution to this run. It also decided whether the product came out good.

So the factory is on the shelf, install curves attached. Take the four stages as they are, or read them and disagree — the banned-pattern lists, the money rules, the gate placements are opinions, and the opinions are the part worth arguing with. Fork the line. Publish your stations. The next factory should have someone else's name on it.