DEV Community: kttherealest

3 Weeks Solo-Building Toolstack: 15 Products Shipped

kttherealest — Mon, 28 Sep 2026 18:10:53 +0000

3 weeks into building Toolstack solo — here's where things stand.

Launched on Product Hunt, and since then I've been heads-down shipping: 15 products so far, ranging from one-click browser extensions to fully tested Next.js SaaS starters with real auth, Stripe billing, and working code.

Everything ships tested — real checkouts, real webhook deliveries, real API calls — before it goes out. I'd rather ship something small and working than something big and half-finished.

Still early days. Still building in public. If you're a developer looking for a starting point instead of building auth/billing/DB from scratch again, take a look: https://whop.com/table-export-tools/products

Would genuinely appreciate feedback, even the harsh kind.

How to Actually Set Up Stripe's Billing Meters in 2026 (Most Tutorials Are Wrong)

kttherealest — Sun, 13 Sep 2026 19:49:53 +0000

If you've searched for "Stripe usage-based billing" or "Stripe metered pricing" recently, there's a good chance you found a tutorial referencing stripe.subscriptionItems.createUsageRecord(). That approach is dead. Stripe fully deprecated it in 2025, and you can no longer even create a new metered price the old way in the Dashboard.

I found this out mid-build, while working on a usage-based billing starter kit. Here's the current, correct way to do it.

What actually changed

The old model: attach a metered price directly to a subscription item, then report usage against that specific item's ID.

The new model: create a Meter object first (a named, reusable event definition), attach a price to that meter, and report usage against the customer, not a subscription item.

This is a meaningful simplification once you know it — you no longer need to track a subscription item ID in your database at all.

Step 1: Create the Meter

In the Stripe Dashboard: Billing → Meters → Create meter.

You'll set:

A display name (for your own reference)
An event name — a string you choose, e.g. api_requests. This is the identifier your code will use to report usage, so pick something meaningful and stable.
Aggregation: usually "Sum" (adds up every reported value over the billing period).

Step 2: Create a metered Price attached to that Meter

Product catalog → Add product → when setting the price, choose "Usage-based" (not "Standard"), and select the Meter you just created. Set your per-unit price.

Copy the resulting Price ID — you'll use it for Checkout.

Step 3: Create a Checkout Session (no quantity!)

This is a small but important detail: metered prices don't take a quantity. If you pass one, Stripe rejects the request.

\js const session = await stripe.checkout.sessions.create({ customer: customerId, mode: 'subscription', line_items: [{ price: process.env.STRIPE_PRICE_ID }], // no quantity success_url: '...', cancel_url: '...', }); \\

Step 4: Report usage

This is the actual replacement for the old createUsageRecord call:

\js await stripe.billing.meterEvents.create({ event_name: 'api_requests', // must match what you set up in Step 1 payload: { value: '1', stripe_customer_id: customerId, }, }); \\

Note it's keyed to stripe_customer_id, not a subscription item ID. Stripe aggregates these events per meter, per customer, per billing period, and calculates the invoice automatically.

A reliability note

If this call fails (network blip, wrong event name, etc.), decide deliberately what happens to the user's request. In my case, I chose to still fulfill the request and just log the error — a billing-reporting failure shouldn't break the actual feature. But that does mean a failed report is usage that goes unbilled silently. For anything handling real revenue, you want a retry queue (store failed events, retry on a schedule) rather than a bare console.error.

Common gotchas

Test-mode and live-mode Meters are separate objects. Don't assume the Meter you created in test mode carries over — you'll need to create a live one too before going to production.
The event name is exact-match. A typo between what you configured in the Dashboard and what your code sends means silently-uncounted usage, not an error.
Webhooks still work the same way for tracking subscription status (customer.subscription.updated, etc.) — that part of the integration didn't change.

Working example

I built this into a full starter kit (Next.js + Prisma + NextAuth + Stripe) if you want to see it wired together end-to-end, including the free-tier gating before metered billing kicks in: https://whop.com/table-export-tools/meter-usage-based-billing-saas-starter-stripe-meters/

I Built 15 Digital Products in a Week Using Claude — Here's What Actually Broke

kttherealest — Sun, 06 Sep 2026 17:33:34 +0000

Over the past week I built and shipped 15 digital products — 2 Chrome extensions, a resume scanner, a UI template, and 11 SaaS starter kits with genuinely different architectures: invoicing, feature flags with percentage rollouts, outbound webhooks with HMAC signing, usage-based billing via Stripe, and one that ships a real browser extension alongside the web app.

Everything was built through Claude. But the part worth writing about isn't the generation — it's what testing actually surfaced.

Bug #1: A hash function that wasn't as random as it looked

The feature-flag starter needed deterministic percentage rollouts — the same user should always get the same result for a given flag, computed by hashing flagKey:distinctId into a 0-99 bucket.

The first version used a simple polynomial rolling hash:

\js let hash = 0; for (let i = 0; i < seed.length; i++) { hash = (hash * 31 + seed.charCodeAt(i)) >>> 0; } \\

Looked fine in isolation. But a test script checking independence between two different flags for the same user turned up a problem: users "in" one flag's rollout were suspiciously likely to also be in an unrelated flag's rollout.

The cause: two strings of the same length differing by one character in the same position produce hashes that differ by a fixed offset with this kind of hash — not an independent, unpredictable one. "flagA:user-0" and "flagB:user-0" differ by a constant delta, and that delta is the same regardless of the user number.

Fixed by switching to FNV-1a:

\js let hash = 0x811c9dc5; for (let i = 0; i < seed.length; i++) { hash ^= seed.charCodeAt(i); hash = Math.imul(hash, 0x01000193); } hash = hash >>> 0; \\

Re-ran the independence test: two unrelated flags for the same 1,000 simulated users now disagreed about 47% of the time — right where independent 50/50 decisions should land.

Bug #2: Building on an API that got deprecated mid-build

The usage-based billing starter needed to report metered usage to Stripe. I started implementing it against stripe.subscriptionItems.createUsageRecord() — the classic approach for metered billing.

Turns out Stripe fully deprecated that approach in 2025 in favor of a new Billing Meters system. The old flow (attach a metered price directly to a subscription item, report usage against that item) doesn't exist anymore for new integrations — you now create a Meter object first, then report usage against a customer ID via stripe.billing.meterEvents.create().

Had to redo the schema (no longer need to track a subscription item ID at all — usage reports against the customer directly) and the reporting call. A reminder that "I've seen this pattern before" isn't the same as "this pattern is still current."

What's actually live

12 of the 15 are live under one storefront if you want to look at the code or the live demos: https://whop.com/table-export-tools/products/

Happy to go deeper on any of the architectures — team-based billing vs. per-user billing, CORS setup for a browser extension talking to an API, HMAC signing for outbound webhooks, whatever's interesting.