Building Quincena · July 12, 2026 · 7 min read

I built a real, payment-taking SaaS for $27. Here's what actually was hard.

Quincena is a live product. Not a landing page, not a prototype — a working app at quincena.moneywith passwordless login, a real database, a paycheck-based budgeting engine, Stripe subscriptions (monthly and annual, with receipts and cancellation emails), and a free/paid split that's actually enforced on the server — not just hidden in the interface.

My out-of-pocket cost to build it was $27, for the domain. Everything else — hosting, database, email — runs on free tiers until real traffic arrives. A dev shop would quote somewhere between $60,000 and $150,000 for the same scope. I know, because partway through I stopped and added up everything it actually takes to do properly.

That gap is the interesting part. But the more useful story isn't “AI built my app.” It's which parts were easy, which were genuinely hard, and why the hard parts had almost nothing to do with writing code.

The easy 80%

The scaffolding came fast: the pages, the layout, the budgeting math, the forms, the styling. If you've watched an AI coding tool lately, you know this part. Describe a feature, get a working version, refine it. For the visible surface of an app, the tools really are a step-change faster than they were a year ago.

If building software were only that 80%, everyone would ship. It isn't. The other 20% is where products quietly become broken, insecure, or embarrassing — and it's invisible until it bites.

The invisible 20%, in specifics

A paid tier that was free if you knew where to click

The first version gated the paid features in the interface — hide the button, hide the feature. Standard, and completely fake. The budget data was still writable directly through the API regardless of subscription status. Anyone who opened the network tab could grant themselves the paid tier for free.

The fix was moving the truth to the server: row-level security in the database so a request can only touch its own account, and enforcing the subscription check on the write path, not the render path. This is the difference between a demo and a product that can take money — and it's exactly the kind of thing a fast build skips because everything looks fine.

Gmail eats your magic link before you click it

Passwordless login sends you a one-time link. Simple — until testers reported their links were “already expired” the instant they arrived. The culprit: email security scanners, Gmail's especially, pre-fetch links in your inbox to check them for malware. That click consumes a one-time login link before the human ever sees it.

The fix was to offer a typed code alongside the link — scanners don't consume a code the way they consume a URL. It's a one-line problem to describe and a genuinely non-obvious one to diagnose if you've never hit it.

Testing that the money actually moves

Wiring up Stripe is easy to fake and hard to get right. Signature-verified webhooks so nobody can forge a “payment succeeded” event. Cancel-at-period-end so a cancellation keeps access until the paid time runs out instead of yanking it immediately. Handling the difference between a subscription being created, updated, and deleted. Receipts. Tax settings. I didn't trust any of it until I ran real checkouts and watched the right emails fire and the right database rows flip.

Fake demo data that confused real users

Early on, new accounts started seeded with sample numbers so the app didn't look empty. It backfired — people couldn't tell the sample from their own data and thought the app had invented a budget for them. The right call was to start empty and make the empty stateteachinstead of impress. That's not a coding decision. It's a product-judgment one, and the tools have no opinion about it.

The real skill wasn't prompting. It was steering.

None of the hard parts above were solved by a clever prompt. They were solved by knowing they existed — catching the security hole, insisting on a real payment test, recognizing the magic-link symptom, killing the confusing demo data, and making a hundred small judgment calls about what “done” means.

The tools got 10x better at the typing. Knowing what to point them at, and what “correct” looks like, matters more than ever — not less.

Why this matters beyond one budgeting app

The old question was “what would it cost to build this?” The new one is “what did it cost?” — and the distance between those two numbers is the whole opportunity right now. A working, payment-taking product for the price of a domain wasn't realistic a year ago. If you've been waiting on a big budget or a technical co-founder to start, that wall is a lot lower than it was.

The catch, and it's a real one: it was never “magic prompt → finished app.” It was steering, testing, and judgment, over and over. The leverage is enormous. The taste to aim it is still yours to bring.

And the app itself? It's a genuinely useful thing — a budget built around how you're actually paid. Try it free, or read how it handles biweekly vs. semi-monthly pay.