• Static pages on the same serverless hosting pattern as my other sites: pennies a month, nothing to maintain, nothing to get hacked at 2am.
• I post from a simple form behind passwordless sign-in; Claude posts through a small CLI — fitting, since half this dev log is generated from the work itself.
• One email box does two jobs: joins the app waitlist and registers you to comment.
• Even the domain had a story. I almost bought paydownaffirm.com (trademark trouble waiting to happen) and paydownbnpl.com (try saying "b-n-p-l" out loud in a video) before landing on getpaydown.com.

If you're reading this before the beta: join the waitlist. The debt-free date is the product. The weekly artifact is the promise. This is week one.

Marketing, compressed: position as the BNPL-sprawl app, not another budget app — that fight is unwinnable against incumbent ad budgets. Build in public (this blog). Seed the beta in debt-free communities with honest walkthroughs. Launch on low-competition App Store keywords like "bnpl tracker." Grow with a free payoff calculator and share cards. Zero ad spend until organic numbers prove out.

Accounts: yes, but look at why Rocket Money needs heavy account infrastructure — they hold your bank credentials. PayDown never does. Accounts here are opt-in, exist only for sync, use passwordless email links, and sit on database-enforced row-level security.

Security, plainly: data lives on your phone by default, protected by device encryption. Cloud sync is opt-in, encrypted in transit and at rest, one user per row, enforced below the application layer. No bank logins, no Plaid, no transaction feeds. Worst-case breach exposes a list of self-reported balances — bad — not credentials to anyone's bank — catastrophic. Smallest possible attack surface, as a product decision. It's all on the privacy page in plain English.

The answer I got back from Claude was uncomfortable because it was true, so I'm publishing it where I can't un-see it:

Building was never the problem. Thirty-seven shipped apps in eighteen years is an elite shipping record. But each one got months of engineering and roughly zero sustained distribution. That's not bad luck thirty-seven times; it's the same allocation decision thirty-seven times.

There's no guaranteed money on the App Store. What exists instead: a niche with real pain (BNPL sprawl qualifies), a product that solves it honestly (this one does), and then the part I've always skipped — showing up in public every single week. A post, a video, a build log, an answer in a community. Boring, repeatable, compounding.

So that's the standing rule now: from beta onward, every week ships one marketing artifact alongside the code. This post is one. This whole blog is the enforcement mechanism.

The architecture Claude and I settled on:

Local-first stays the default. Data lives on the phone. The cloud is opt-in, for people who want a web dashboard or multi-device sync.

For those who opt in: a Postgres backend where every row is tagged with its owner and row-level security is enforced by the database itself — not by app code that might have a bug. Sign-in is a passwordless email link. Timestamps and tombstones make sync last-write-wins with no server brain to maintain.

The web dashboard reuses the exact same engine package as the phone — same math, same golden tests, running in the browser. Two clients, one truth.

And no bank logins anywhere in any of it. That's not a missing feature; it's the design.

I sent Claude both screenshots. The culprit: statements list an "Amount Financed" — the principal at origination. For a loan that's already been paid on, that number overstates today's payoff, and the import was trusting it anyway.

The fix draws a clean line:

• No payments made yet? Amount Financed is correct — use it.
• Otherwise, compute today's payoff as the present value of the remaining payments at the plan's rate — which is exactly what the provider's own payoff quote is.

Plus the usual one-time repair for anything imported before the fix. That was build 7. My totals now match Affirm to the dollar, and that's the standard going forward: if PayDown and the provider ever disagree, it's a bug, not a rounding story.

Now the slider's range scales with your actual monthly obligations, and next to it is a plain dollar field that accepts any number at all. Sliders are for exploring; the text field is for deciding.

Small fix, but the lesson generalizes: every hardcoded limit in an app is a guess somebody made on a Tuesday. When a user asks "why is it limited?", the answer needs to be better than "the slider needed a max." If it isn't, the limit shouldn't exist.

That's the normal case, not the edge case. Nobody starts tracking a loan the day they open it. Builds 5 and 6 filled the gap:

• A history screen per account: paid-so-far on top, still-owed below.
• Log a past payment — and after I caught the first version getting this backwards, logging a payment now reduces the balance by default, with a toggle for the exceptions.
• Backfill for the other case: the balance was already correct, and I just wanted the record to show the installments I'd paid. History only, balance untouched.

The difference between those last two matters more than it looks — one changes what you owe, the other changes what the record shows. Collapsing them was the first version's mistake.

The interesting one is what I think of as the Lead Bank problem. One of my loans showed an "L" icon — for Lead Bank, the underwriter on the statement. Technically correct. But I didn't borrow from Lead Bank in any way I think about; I borrowed from Affirm. An app that's technically correct and intuitively wrong is still wrong.

So: a provider picker with the known BNPL brands and their colors, plus an underwriter map that auto-resolves statement names like Lead Bank to the brand you actually used.

The other two:

• Swipe navigation between the main screens — reaching for the tab bar every time felt clunky on a phone.
• A note on every account. A loan called "Affirm #4823" means nothing; a loan called "necklace" is a thing I remember buying. Debt is personal; the labels should be too.

I sent Claude screenshots of exactly what I pasted and exactly what came out, and the eval harness went to work reproducing it. Three separate bugs:

• APR ×100. The model returned 33.61% as "3361". The fix is deterministic: any parsed rate over 100 gets normalized down, and the prompt now pins rates to a sane range. Never trust a language model with a decimal point.
• The balance trap. Statements are full of numbers that look like balances. The extraction now follows a formula rule for which one is real — and the app computes the balance from the installment terms rather than trusting what was scraped.
• Two-digit years. "6/11/26" parsed as 2023. A date-format rule fixed it.

For data already imported wrong, Claude added one-time repair migrations that detect impossible values and fix them in place. All of it shipped as build 3, same day.

First: the schedule showed when money was due but not who it went to. Every row looked the same.

Second, and sneakier: the app said my total debt was $4,267 when the honest number was $3,907. It was summing my remaining payments — principal plus the interest baked into future installments — and calling that "debt."

Both fixed in build 2:

• Every payment row got a provider avatar — brand colors for known BNPL providers, a tinted initial for everything else, green for income.
• The headline number became principal owed: what it would cost to be done today. Future interest belongs in the projection, not in the scary big number.

That second fix became a rule the app still follows: the balance is the payoff amount, not the sum of remaining payments. Sounds obvious. Half the import bugs that came later were violations of exactly that rule.

• Cloud signing rejected the App Store Connect API key with a cryptic "No Account for Team." The workaround was fully manual signing — certificate and provisioning profile created through Apple's REST API, archive and upload scripted with xcodebuild. No Xcode GUI, no interactive logins anywhere.
• The first build uploaded successfully and then didn't show up for testing. The reason: the tester group had zero testers in it. One API call fixed what an hour of staring couldn't.
• The newest Xcode broke a dependency with a Swift compiler error; a one-line patch, applied automatically on every install, un-broke it.

What came out the other side is a fully scripted release pipeline: bump the build number, archive, upload, wait ten minutes, it's on my phone. Seven builds went through it in the first week — which is why every piece of feedback in the next few posts turned into a new build the same evening.

It works in whole days: no timezones, no DST, no clock. Dates are stored as integers. That sounds academic until you see the bugs it surfaced during the build:

• The weekday off-by-one. Twice, "biweekly on Friday" landed on Thursday because of a wrong assumption about which day is day zero. Claude fixed it with tests pinned to calendar truth — dates a human can verify against a wall calendar.
• Month-end drift. A payment anchored to Jan 31 must hit Feb 28, then Mar 31 — not slide to the 28th forever. Anchor-preserving month math handles it.

Every projection — daily interest accrual, extra-payment cascades, freed-minimum rollovers — is pinned against an independent Python implementation Claude wrote separately. Dates must match exactly; interest within a dollar. If the two ever disagree, a test fails.

The rule that came out of this build: AI parses, deterministic code computes. Always.

When it came time to test the parsing, the default path was the Claude API. I pushed back: I run Ollama on a box at home, and I wanted the extraction tested against my model, on my hardware, where iterating costs nothing.

Claude built me a small eval harness: sample statements (Klarna emails, Affirm statements, virtual-card schedules) run through my local qwen2.5 model, with the structured output diffed against known-correct values.

That harness turned out to be the best investment of the whole project. Over the following days it caught six-plus real extraction bugs from my actual statements — for free, before any user would have hit them. A $0 local model you can hammer beats a paid API you're afraid to iterate on.

It's a spreadsheet. What Claude and I landed on as the features that make it an app people open:

• The debt-free date. One number that moves. That's the emotional core of the whole product.
• Safe-to-spend — after every scheduled payment clears, what's actually yours this pay period.
• Strategy comparison — avalanche vs. snowball, with interest saved shown in dollars, not lectures.
• Paste-to-import — nobody types eleven installment plans in by hand.
• Milestones — paying off a plan should feel like something.

BNPL management is the wedge, the underserved pain nobody else centers. But the payoff date is the product.

Claude pitched a shortlist and three survived: ZeroDue, Burndown, and PayDown.

I picked PayDown because it's literally what the app does. You pay down debt; the app shows the date you're done. Nothing to explain in an App Store listing.

Burndown didn't lose entirely — it became the brand mark. The icon is a burndown chart line heading to zero, which is exactly the chart the app draws for your balances.

I've been writing software since 1996 and shipping mobile apps since 2008, and this is the first one I'm building primarily for myself. I sat down with Claude and laid out what I wanted: every payment — monthly, bi-weekly, weekly, BNPL installments — on one schedule, a debt-free date, and suggestions for moving that date up. Personal tool first; if it earns the right to be a business, there's a monetization plan waiting.

Day one produced the unglamorous foundation: a private repo, GitHub Issues split into five milestones (tracker, payoff engine, AI import, beta, monetization), and planning docs for the product, the math, and the marketing.

This blog is the build log for all of it.