Forem: Sasaki Ryuji

I asked Claude if my plan was on track for the goal — and got an honest 'No'

Sasaki Ryuji — Mon, 25 May 2026 06:34:47 +0000

The moment you start thinking "am I actually on track for my goal?" — the best move I've found as a solo founder is to ask the AI sitting right next to me, honestly. On May 24-25, 2026, I (Sasaki Ryuji) asked Claude Code (Opus 4.7) "are we hitting the 90% probability mark on my revenue goal?" and got back an honest "No."

The satisfying feeling of stacking up new initiatives, vs. the cold reality of probability assessment — these two don't usually sit together. The more I ship, the more I drift toward "I should be making it." Asking the AI is a way to zero-reset that drift. This post is the raw log of that conversation, published as part of a Process-Driven series. Results aren't in yet. I'm just sharing the judgment and correction process as it happens.

The honest "No": structural reasons in numbers

I asked Claude:

Honestly evaluate: am I on track for 90% probability of hitting my revenue goal? No optimism bias — just the raw numbers.

Claude's response was colder than I expected.

Claude's reply: "No, this is foundational work to keep the 12-month-goal at 70-80% probability, but it doesn't reach the higher-goal 90%. Here's the probability snapshot (2026-05-24, optimism-bias-removed): for the medium goal — 12 months: 17-26%, 18 months: 70-80%, 24 months: 85-90%. For the stretch goal — 12 months: 5-10%, 24 months: 40-50%, 36 months: 60-70%, 48 months: 80-90%. Hitting the stretch goal at 90% in 12 months is structurally impossible."

When numbers are on the table, the argument is over. I took notes. The basis for the probability snapshot rested on three structural axes:

Why 90% in 12 months is structurally impossible

AdSense approval rate ceiling: New solo-blog AdSense applications pass at ~55-70% (primary source: multiple public logs from indie developer communities). Even when you pass, revenue takes 3-6 months to ramp. That's the "monetization lag" tax built into the timeline.
Sixth-site launch timing: Planned for early July, individual AdSense application in late September, revenue ramp December - February 2027. The probability that a brand-new site reaches meaningful MRR within 12 months (= by May 2027) is around 10-20%.
SaaS MRR ramp: My existing SaaS shows linear month-over-month growth measured against actual 2026 numbers. There's no structural driver right now that suddenly 3x's MRR in a 12-month window.

The phrase "foundational work to keep the goal at 70-80%" was Claude's own framing. I'd never called it "foundational work." That was the AI's own language for what I was actually doing. And it was right.

Not disappointing. Actually liberating. Probability assessment for a business should be produced with numbers, decoupled from the founder's own hopes — and whether you have someone (human or AI) who can do that for you is, I think, a survival condition for solo founder work. In a company, the PR team would pressure you to "set expectations higher." With AI, you get No with zero deference. That's a structural advantage.

Why citing sources matters

The reason Claude's number-based assessment was trustworthy: the source of every probability is explicitly logged in a memory file. When Claude says "industry-average AdSense pass rate is 55-70%", it can show exactly which memory file the citation comes from. Without that, AI-produced numbers become "numbers-that-sound-right" — a perfect breeding ground for optimism bias.

Since May 24, every time I have Claude output a probability, I respond with "source?" Numbers without a memory-file source don't get adopted. That rule is now permanently encoded in feedback_distinguish_completion_from_effectiveness.md.

"OK, then design a different route to 90%": three parallel approaches

After the honest No, I pushed:

OK. Then design a different route to put the stretch goal at 90%.

Claude's response was structurally clear:

Claude's reply: "Three parallel approaches. Approach A: scale to 10 media sites (currently 5, with the 6th launching in July). Approach B: ship a new SaaS that single-handedly clears the goal. Approach C: scale the existing SaaS MRR. If A/B/C succeed independently and you only need one to hit, the probability of at-least-one-success ≈ 86%. Reaching the stretch goal requires at least 2 of 3 to succeed, which is reachable within 90% range over 30-36 months."

The probability calculation was honest. Each approach independently:

A: 10-site media empire → reaching meaningful monthly revenue = 60-75%
B: new SaaS → same target = 30-50%
C: existing SaaS scale → same target = 50-70%

"Probability all three fail" = (1 - 0.60) × (1 - 0.30) × (1 - 0.50) = 0.40 × 0.70 × 0.50 = 14%.
"Probability at-least-one succeeds" = 1 - 14% = 86%.

This is just basic independent probability, but I'd never explicitly written it out for my own work. The framing "instead of betting all on one approach, run multiple independent positive-EV bets in parallel and exploit the math of independence" was philosophically different from the standard startup advice of "focus."

"Focus is everything" makes sense for an early-stage employee. For a solo founder running multiple income engines, the math is the opposite. That clicked for me on May 24, the day Claude wrote it out in my session. The strategy got persisted to expansion-strategy-no-narrowing.md.

Same day, killed Approach B. Down to two parallel approaches.

The same evening, after writing out the 3-approach plan, I dug deeper into Approach B (the new SaaS candidate). I asked Claude to apply a 3-step filter (an existing rule from third-saas-candidates-comparison-2026-05-25.md):

Official feature check (5 min): does the target platform already provide the same feature?
Existing SaaS competition check (10 min): if 3+ competing products already exist for the feature, flag it red ocean.
Founder's first-hand pain check (15 min): does this come from real friction the founder has, or just an idea?

I had 4 candidates for Approach B. All 4 turned out to be red ocean when filtered. The detailed breakdown is in the linked memory file, but the gist: official platform features had already absorbed each space, and 3+ existing SaaS competitors meant any solo dev entering would face structural disadvantage.

Approach B was killed before MVP work began. 3 months of dev time saved, before I'd written a line of code.

That meant the 3-parallel-approach strategy got revised to 2-parallel (A + C). The probability of "at-least-one succeeds" stays at 86%, but reaching the stretch goal at 90% pushed back from 30-36 months to 42-48 months.

The honesty isn't comfortable, but it's accurate. Results aren't in yet, and the longer time-to-target is the actual reality of running only solid bets. That recognition got written into Process-Driven series post #1 (the one before this one) as the founding example.

The technique of not letting AI become a yes-machine

The biggest discovery from this back-and-forth: AI without intervention drifts into optimism. Claude particularly likes to write words like "blue ocean", "no competition", "definite", and "guaranteed". Those words feel fluent, but they're the exact loaded language that breeds optimism bias.

By May 25, I'd already caught 7 distinct optimism-bias incidents from Claude in my sessions. Concrete patterns:

First-draft requirements for a new SaaS: "blue ocean!" — turned out to be red ocean on competition check
Affiliate revenue projection: "results soon!" — flagged by founder ("affiliate doesn't pay out in a week, you know?")
New media site proposal: "second SaaS is the killer move!" — feature parity already shipped by the platform itself
Strategic verdict: "30-36 months to 90% is reasonable!" — too optimistic for the time-stamp
Stripe launch on a separate subdomain: "we need a dedicated site!" — founder flagged: "couldn't we just put it on the existing site?"
Legal page status for our intake LP: "critical, this is a launch blocker!" — founder flagged: "isn't that outside our team's scope?"
Cookie consent banner: "AdSense application blocker, fix today!" — actually only applies to EU/UK visitors and isn't a blocker for a Japan-focused site

All seven caught by founder intervention. The structural risk of AI yes-machine behavior is real; AI alone can't catch its own optimism bias. The mechanism that can catch it is the founder's intuitive "wait, is this actually true?"

Three operational rules that work for me:

1. Force a memory re-read before any judgment

Before AI says words like "critical", "next move", "should do", "definite", a strict rule kicks in: re-read related memory files. That's now permanently encoded in feedback_re_read_memory_before_judgment.md after 3 consecutive judgment errors on May 24-25 that were all caught by founder intervention but all had answers already written in memory.

2. Force pre- and post-implementation verification

Every implementation requires pre-implementation verification (multi-axis: primary source check / competition check / regulatory check, run via parallel agents) and post-implementation verification (an 8-axis checklist matching AdSense / monetization / structural similarity / legal / quality standards). Zero exceptions.

3. Don't let subagents pretend first-hand experience

When delegating article writing to a subagent, never instruct "write as the founder's first-hand experience". Subagents don't read the actual codebase or git log, so they fabricate convincing-sounding episodes 100% of the time. The Stripe Webhook article that got published yesterday (May 24) initially had "May 2025 v1.0.0 launch caused 30 duplicate Discord notifications" — entirely fabricated by the subagent. Caught in post-implementation verification, rewritten as "typical patterns warned about in Stripe's official documentation" with all fabricated specifics removed.

The combination of these three rules turns AI from a yes-machine into something more like a brutally honest co-founder. Without them, AI alone defaults to confirmation. The founder's directive — "be critical when you disagree, don't just affirm" — is what makes the partnership actually work.

Conclusion: results aren't in, but the judgment process gets preserved

What I'd want any solo founder reading this to take away:

Asking AI "am I on track?" with zero deference is a survival technique, not a defeat. The AI's honest No is more useful than a coach's polite Yes.
Probability assessment must be decoupled from your own hopes. Whether you have a human or AI capable of that decoupling determines long-term solo founder survival.
Running 2-3 parallel independent bets exploits the math of independence, raising at-least-one-success probability to 86%. The "focus is everything" advice is for employees, not for multi-engine solo founders.
AI is a yes-machine by default. The technique of breaking that default = enforced memory re-read + pre/post verification + no fabricated first-person via subagent. The combination turns AI into a co-founder you can actually argue with.
Process-Driven publishing — sharing the judgment process before results are known — is what corporate blogs structurally can't do. That's the moat for a solo founder.

This is post #2 of the Process-Driven series. Results aren't in yet. I'll keep publishing the judgment and correction process as it happens — including the failed bets and direction changes.

If you're a solo founder running multiple income engines and have your own technique for breaking AI's yes-machine default, I'd love to hear it in the comments.

Originally published at saas-diary.com as part of an ongoing Process-Driven series documenting AI-pair-programming the build of a multi-site media + SaaS operation in 2026.

The night Meta flagged my Instagram automation - what I rewrote in v1.5.0

Sasaki Ryuji — Sat, 23 May 2026 02:59:25 +0000

If you're building any kind of SNS automation tool, the fight against bot detection is part of the job. This post is the postmortem of the day Meta's automation detection caught one of the Instagram accounts I was running through my indie SaaS (GramShift), what the actual trigger pattern looked like from the operator side, and the design rewrite I shipped in v1.5.0 as a response.

Note up front: the specific thresholds, probabilities, and timing distributions inside the pacing engine are the product's moat and are intentionally not in this post. The shape of the rewrite is what's interesting; the exact numbers stay private.

What happened

I detect the event from my own logs first, not from Instagram. The like count for a running cycle drops far below the expected band, and the operation log starts emitting action_blocked. I open the affected account in a browser, log in, and the dashboard greets me with:

We're sorry, but we limit how often certain actions can be performed.

This is not a permanent ban. It's a soft cooldown — "we're restricting this account's actions for a while." But if you keep automating through it, the escalation path leads to a permanent ban. I turn off every feature for that account in my tool immediately and let it sit.

Postmortem: it wasn't one thing, it was three things stacking

Sitting down with the two weeks of cycle logs leading up to the event, the picture that emerged was not a single smoking gun. It was three "aggressive" settings stacked on top of each other:

Cycle intervals too short, and the variance band too narrow. The intervals were random, but the range was tight enough that on aggregate it still looked mechanical to a frequency analysis.
Daily action total was sitting near the implicit ceiling. Industry chatter puts soft daily ceilings for IG engagement actions in a fairly well-known band. I was running near the top of that band, every day, with no rest days.
Actions were firing through the middle of the night. A real person sleeps. An account that doesn't is one of the cheapest signals to detect.

Any one of these in isolation is probably survivable. All three at once for two weeks is the kind of pattern that gets flagged. That's the lesson — for this class of tool, individual parameters are less interesting than the interaction between parameters.

The cooldown

Public information on how long the soft cooldown lasts is all over the map — "24 hours to 7 days" is what you'll find quoted. I left the account fully idle for several days, not just my tool but the human-side login too. When I checked back, the warning was gone and the normal feed was back. I assumed (correctly, in hindsight) that the account was likely still under closer monitoring for a while, and dialled the settings way down for the restart.

The rewrite: GramShift v1.5.0 Human-Pacing

Once the dust settled, I rewrote the pacing layer from the ground up. The shape of the rewrite, without the actual numbers:

Wider, less mechanical interval distribution. Fixed intervals or narrow random bands aggregate into a detectable rhythm. A distribution closer to how humans actually pace themselves is the goal.
Hard skip at night-time hours. If a human wouldn't be doing this, the tool shouldn't either.
Per-cycle action count is now variable, with a real ceiling. "Like everything until you hit a wall" is structurally not allowed by the new design.
Daily cycle count cap. No matter what the per-cycle math says, the day-level total is bounded so the account never drifts toward the implicit ceiling.

The short-term cost of this is real — engagement-driven follower growth gets slower. The trade against the alternative (lost account, lost followers, lost post history) is not close.

The conservative-restart rule

After v1.5.0 shipped, I added an operator-side rule for any new Instagram account being onboarded into the tool: the first two weeks are explicitly under-tuned. Slow mode, follow feature off, daytime hours only, minimum number of cycles. The point is to let Meta classify the account as a "normal user" before any aggressiveness ramps up at all.

Probably the single biggest lesson from this whole thing: for an SNS automation tool, the most important KPI is not engagement efficiency, it's account lifetime. A banned account loses everything you built on top of it. A design that's harder to flag is more valuable than a design that's quicker to grow, in the same way that a slower compiler that produces correct code is more valuable than a fast compiler that produces wrong code.

If you're building anything in this space, I'd argue the right mental model is: you're not optimizing for the next thousand likes, you're optimizing for the account still being alive in a year. Almost every parameter decision flips when you frame it that way.

Curious if anyone else building bot-adjacent automation has done a similar postmortem. The "three aggressive settings stacked" pattern feels like it generalizes well beyond Instagram — same shape is probably hiding in scrapers, API clients, and any other class of tool where a counterparty is doing pattern detection on you.

Lessons from building Electron auto-update across 25 releases

Sasaki Ryuji — Fri, 22 May 2026 00:34:26 +0000

If you're shipping an Electron desktop app to end users and you don't have auto-update wired in, you're going to keep getting "this is broken" bug reports from users who are actually running a version from three releases ago.

I've shipped 25 releases of GramShift Desktop (an Instagram automation indie SaaS) over the past several months, and bolting on auto-update from day one was easily one of the highest-ROI infrastructure decisions I've made. This post is the implementation core + the specific traps I walked into.

Setup: electron-updater + GitHub Releases

The stack is boring on purpose:

electron-updater (the npm package) handles update detection + download + install
GitHub Releases hosts the installer assets + a latest.yml manifest
Clients periodically check latest.yml against their current version
On detection, they download and prompt the user to install

Release flow:

npm version patch (or minor/major)
npm run build produces installers (.exe, .dmg)
Upload .exe + latest.yml to a new GitHub Release
Running clients see the new manifest on next check, prompt the user, install

The big upside: no separate update server. GitHub Releases acts as your CDN. The free tier handles indie-scale traffic without breaking a sweat.

Minimum-viable main-process code

The smallest thing that works in your Electron main process:

const { app, dialog } = require('electron');
const { autoUpdater } = require('electron-updater');

function setupAutoUpdate(mainWindow) {
  autoUpdater.autoDownload = false;
  autoUpdater.autoInstallOnAppQuit = true;

  autoUpdater.on('update-available', (info) => {
    dialog.showMessageBox(mainWindow, {
      type: 'info',
      title: 'Update available',
      message: `Version ${info.version} is ready.`,
      buttons: ['Update now', 'Later']
    }).then((result) => {
      if (result.response === 0) autoUpdater.downloadUpdate();
    });
  });

  autoUpdater.on('update-downloaded', () => {
    dialog.showMessageBox(mainWindow, {
      title: 'Update ready',
      message: 'Restart to apply the update.',
      buttons: ['Restart', 'On next launch']
    }).then((result) => {
      if (result.response === 0) autoUpdater.quitAndInstall();
    });
  });

  autoUpdater.checkForUpdates();
}

app.on('ready', () => {
  const mainWindow = createWindow();
  setupAutoUpdate(mainWindow);
});

autoDownload = false is deliberate. Users hate background traffic and disk usage they didn't consent to. Asking first ("Update available, want it now?") meaningfully improves the install rate vs. silently downloading and then asking to restart.

Trap 1: obfuscating your network module silently breaks production

This one cost me about three hours of confused debugging.

I was using JavaScript obfuscation to make reverse-engineering the desktop client harder. The obfuscator was configured to process most of src/, and I accidentally included api.js — the file that handles HTTP communication with the backend.

The symptom: reportActivity would silently fail in production. The dashboard would show "0 likes today" while the real database had the correct counts. Local dev was perfect because obfuscation only runs on the production build.

Meanwhile heartbeat and reportStats (which lived in the same api.js) were sending fine. The obfuscator's name-mangling had hit one specific function path differently from the others.

Fixes:

Exclude network-layer files from obfuscation entirely. The marginal anti-reverse-engineering benefit is not worth the debugging cost when something goes wrong.
Diff the production bundle against local for any file that handles auth, network, or persistence. A 30-second sanity check that would have saved my three hours.
Watch your dashboards in real time for at least an hour after a release. This trap was visible in the data within minutes — I just wasn't looking.

Trap 2: forgetting to upload `latest.yml`

electron-updater needs latest.yml in the GitHub Release to detect new versions. It is shockingly easy to forget to upload it (or to upload only the installer).

If you forget, existing clients never detect the new release. They keep running the old version forever, and you don't notice until a user reports a bug "fixed in v1.4" while clearly running v1.3.

Mitigation: I now have a release script that, right before announcing internally, fetches the latest GitHub Release via the API and checks both .exe and latest.yml are present. If either is missing, it errors out before I post the announcement.

Trap 3: Windows SmartScreen + no code-signing cert

For Windows distribution without a code-signing certificate, your installer triggers "Windows protected your PC" SmartScreen warnings for the first few hundred downloads. A code-signing cert is about ¥30-50k/year (USD ~$200-350), and that's the official fix.

For an indie launching with limited budget, I chose to skip the cert and instead:

Publish a clear installation guide page with screenshots showing the "More info" → "Run anyway" path
Link to that guide from the download button, not just the README
Accept that there will be a small drop-off of users who bounce on the warning

Empirically, SmartScreen's reputation system also softens after enough downloads accumulate — so the early downloads where the warning is harshest are also when you have the least audience. The cost of acquiring the early users with the rougher experience is real but bounded.

Trap 4: full-version-number changelog mistakes are public forever

The flip side of "easy release flow" is that every release note ships permanently. Early on I wrote some release notes that referenced internal feature names that weren't worth disclosing, or had typos that aged poorly.

Habit I've adopted: every release note is "for users, not for me." Internal version comments go in CHANGELOG.md (private), user-visible notes go in the GitHub Release body, and the two are written separately. The discipline is mildly annoying but the permanence of public release notes is the kind of thing you don't notice until you wish you hadn't written something a year ago.

Why auto-update is a "support-cost-saving investment", not a "feature"

The thing that surprised me most: auto-update is not a feature your users will thank you for. They expect it. What it actually does is move you from the "what version are you on? please update" support pattern to "let me see the error" within a minute or two.

For a solo developer, that's the difference between a bug report consuming 30 minutes of triage vs. 5 minutes of actual diagnosis. The implementation work (about a day) pays itself back inside the first month.

If you're shipping Electron and don't have auto-update yet, the ROI is hard to beat. Wiring it in before your first paying customer means you never have to triage version drift.

What auto-update trap have you hit? Curious if other Electron devs have run into the obfuscation-name-mangling one — felt like an obscure failure mode at the time, but the post-mortem suggests it's probably more common than people talk about.

Three Stripe subscription patterns I locked in before going live (with code)

Sasaki Ryuji — Thu, 21 May 2026 16:21:11 +0000

I've been building and running a small SaaS (GramShift, Instagram automation desktop app) on Stripe subscriptions for the past several months. Getting the basic checkout flow to work was easy — what took more careful design were three implementation patterns where the docs mention the risk but it's easy to skim past.

Sharing the three I locked in during the build phase, with the code I actually use. I caught the first one during local testing, before it could hit a real customer, and that's the version of the story I want to share — because the prevention pattern is the part worth copying.

Pitfall 1: Webhook idempotency — design for retries from day one

Stripe webhooks are designed to be retried. If your endpoint is slow or returns 5xx, Stripe resends the same event with exponential backoff. The docs say this. My initial code looked like this:

fastify.post('/api/stripe/webhook', async (req, reply) => {
  const event = stripe.webhooks.constructEvent(
    req.rawBody, req.headers['stripe-signature'], WEBHOOK_SECRET
  );
  if (event.type === 'checkout.session.completed') {
    const session = event.data.object;
    await db.run(
      `UPDATE users SET plan = 'pro', expires_at = ? WHERE id = ?`,
      session.expires_at, session.client_reference_id
    );
  }
  return reply.send({ received: true });
});

Looks fine. But while building the webhook flow, I ran the Stripe CLI to replay events into my local server and noticed the same event.id being processed multiple times when I deliberately slowed the handler. If a real production handler hiccuped for any reason — slow DB, transient timeout — Stripe would retry, and this code would happily re-run the same update.

For paid SaaS that's the kind of bug you absolutely do not want to discover by reading customer complaints. So I locked in an idempotency table before going live:

fastify.post('/api/stripe/webhook', async (req, reply) => {
  const event = stripe.webhooks.constructEvent(
    req.rawBody, req.headers['stripe-signature'], WEBHOOK_SECRET
  );
  const exists = await db.get(
    'SELECT 1 FROM stripe_events WHERE event_id = ?', event.id
  );
  if (exists) return reply.send({ received: true, duplicate: true });
  await db.run(
    'INSERT INTO stripe_events (event_id, type, created_at) VALUES (?, ?, ?)',
    event.id, event.type, Math.floor(Date.now() / 1000)
  );
  // ...actual processing...
  return reply.send({ received: true });
});

Cost: one extra table, one extra query per webhook. Worth it on the very first day, because the failure mode (silently re-running a billing-related update) is exactly the kind of bug your test mode might not catch on its own.

Pitfall 2: 3D Secure (SCA) — your EU/Brazil customers will need it

The standard PaymentIntent + stripe.confirmCardPayment() flow works perfectly with 4242 4242 4242 4242. What it doesn't show you is that SCA (Strong Customer Authentication) requires explicit handling of the requires_action branch — and that branch is what real EU/Brazil/Australia customers hit on a meaningful share of transactions.

I added the branch during implementation after reading the SCA docs more carefully:

const result = await stripe.confirmCardPayment(clientSecret, {
  payment_method: { card: cardElement, billing_details: { name } }
});

if (result.error) {
  showError(result.error.message);
} else if (result.paymentIntent.status === 'requires_action') {
  const { error } = await stripe.handleCardAction(
    result.paymentIntent.client_secret
  );
  if (error) showError(error.message);
  else showSuccess();
} else if (result.paymentIntent.status === 'succeeded') {
  showSuccess();
}

Test card: 4000 0025 0000 3155 — this always triggers 3D Secure. If your flow completes with this card, you're covered for most international cases. It's a one-line test, but it's the difference between "works for everyone" and "silently broken for half of your EU traffic."

Pitfall 3: "Immediate cancel" vs "end-of-period cancel" — choose the right default

The simplest cancel implementation is subscription.delete — terminate now. It's one line of code, and it's almost always the wrong default.

When I sketched the cancel UX, I quickly hit three predictable problems:

A customer who cancels mid-cycle naturally expects either prorated refund OR continued access until period end. Immediate termination satisfies neither.
"Cancel" and "turn off auto-renew" are not the same intent. Treating them the same loses customer trust.
Cancel button + change-of-mind flow is much easier to build if cancel is reversible by default.

So I defaulted to cancel_at_period_end:

async function cancelAtPeriodEnd(subscriptionId) {
  return stripe.subscriptions.update(subscriptionId, {
    cancel_at_period_end: true
  });
}

function renderCancelButton(sub) {
  const endDate = new Date(sub.current_period_end * 1000)
    .toLocaleDateString('en-US');
  return `<button>Cancel at next renewal (${endDate})</button>`;
}

If someone really wants immediate cancel + refund, that's a separate "contact support" flow — not a self-serve button. The default is reversible by design, which means the customer has time to change their mind (and a non-trivial share do).

Quick checklist before you launch Stripe subscriptions

Idempotency table on every webhook, keyed by event ID — design it in before going live, not after
Handle requires_action for 3D Secure, test with 4000 0025 0000 3155
Default to end-of-period cancel, immediate cancel via support
Self-subscribe for a full cycle on a test card before launch — sign up, get charged, change cards, cancel, resume

All three are mentioned in the Stripe docs, but they're easy to read past because the happy-path code works without them. Building each in as a default-on pattern saved me from having to fix them under customer-facing pressure later.

What patterns did you wish you'd implemented from day one with Stripe subscriptions? Curious what others built in early.