惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

阮一峰的网络日志
阮一峰的网络日志
J
Java Code Geeks
Martin Fowler
Martin Fowler
宝玉的分享
宝玉的分享
V
Visual Studio Blog
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
M
MIT News - Artificial intelligence
U
Unit 42
博客园 - 三生石上(FineUI控件)
博客园 - 聂微东
The GitHub Blog
The GitHub Blog
I
InfoQ
WordPress大学
WordPress大学
H
Help Net Security
D
Docker
B
Blog
腾讯CDC
A
About on SuperTechFans
Recent Announcements
Recent Announcements
雷峰网
雷峰网
有赞技术团队
有赞技术团队
C
Check Point Blog
Y
Y Combinator Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC

DEV Community

Authentication Security Deep Dive: From Brute Force to Salted Hashing (With Java Examples) Why AI Systems Don’t Fail — They Drift Spilling beans for how i learn for exam😁"Reinforcement Learning Cheat Sheet" I Replaced Chrome with Safari for AI Browser Automation. Here's What Broke (and What Finally Worked) How Python Borrows Other People's Work The $40 Architecture: Processing 1 Billion API Requests with 99.99% Uptime Vibe Coding: A Workflow Guide (From Zero to SaaS) Most webhook security guides protect the wrong side. The scary part is delivery. Headless CMS for TanStack Start: Build a Blog with Cosmic EU Age Verification App "Hacked in 2 Minutes" — What Actually Happened Comfy Cloud’s delete function does not actually remove files Running AI Models on GPU Cloud Servers: A Beginner Guide Event-driven media intelligence with AWS Step Functions and Bedrock I scored 500 AI prompts across 8 quality dimensions — here's what broke How to Call Google Gemini API from Next.js (Free Tier, No Backend Needed) The Portal Protocol: Reclaiming Human Connection in the Age of AI How to Fix Your Team's Scattered Knowledge Problem With a Self-Hosted Forum Intro to tc Cloud Functors: A Graph-First Mental Model for the Modern Cloud Designing Multi-Tenant Backends With Both Ownership and Team Access I Built a Neumorphic CSS Library with 77+ Components — Here's What I Learned PostgreSQL Performance Optimization: Why Connection Pooling Is Critical at Scale Cómo construí un SaaS multi-rubro para gestionar expensas en Argentina con FastAPI + Vue 3 🚀 I Built an Ethical Hacking Scanner Tool – Open Source Project I Replaced /usage and /context in Claude Code With a Single Statusline A Pythonic Way to Handle Emails (IMAP/SMTP) with Auto-Discovery and AI-Ready Design I Collected 8.9 Million Polymarket Price Points — Here's What I Found About How Markets Really Move EcoTrack AI — Carbon Footprint Tracker & Dashboard Everyone's Using AI. No One Agrees How. 5 self-hosted ebook managers worth trying in 2026 Building Your First AI Agent with LangChain: From Chatbot to Autonomous Assistant
The boring 80% nobody warns you about when an AI demo bec...
Velobase · 2026-06-17 · via DEV Community

This month the front page filled up with AI agents going off the rails — one reportedly ran its operator's bill into the ground, another tore through a Linux box unsupervised. Funny, until it's your credits and your customers. We learned that lesson the slower, more expensive way.

Our team shipped an AI demo in a weekend. Turning it into something people could actually pay for took the next four months, and almost none of that time went into the AI part.

That gap surprised us more than it should have. The model call was maybe 30 lines. Everything around it — getting paid, knowing who to thank for a signup, stopping one script from burning $400 of credits overnight — was the real product. Below is what we got wrong on the way there, in roughly the order it hurt.

Pitfall 1: "We'll just add Stripe later"

Later is a lie. The moment you charge for AI usage, billing stops being a checkout button and becomes a metering problem.

A flat $20/month subscription is easy. The trouble starts when usage is the cost. A heavy user can run you negative on a plan a light user is wildly overpaying for. So you end up needing both: a subscription and a usage meter that counts tokens (or images, or minutes) and reconciles them against credits the customer actually has left.

What we underestimated was the bookkeeping. Every generation has to decrement a balance, that decrement has to survive a crash mid-request, and the customer needs a dashboard that agrees with what Stripe charged them — to the cent — or you get support tickets you can't answer. We rebuilt this twice. The second time we finally separated "what the model did" (an event) from "what we charged" (a ledger entry), and the bugs stopped.

If you take one thing from this post: model the usage event and the billing entry as two different things from day one. Collapsing them feels simpler and costs you a weekend later.

Pitfall 2: Free credits are a free lunch — for abusers

We gave new signups some free credits so people could try the thing without a card. Reasonable. Within a week someone had scripted a few hundred throwaway accounts and was draining the free tier in a loop.

There's no single fix. What actually worked was a stack of cheap, boring checks layered together:

  • Rate limits per account and per IP (Redis, sliding window).
  • A CAPTCHA on signup — we used Turnstile, but anything that adds friction for bots helps.
  • Blocking disposable email domains at signup.
  • Small signup signals (is this account an hour old with 200 generations?) feeding a guest quota.
  • And the unglamorous one: credit clawbacks, so when you do catch fraud after the fact, you can actually take the credits back instead of eating the loss.

None of these is clever. The lesson was that abuse control isn't a feature you build once — it's a posture. You assume the free tier will be attacked and you make abuse slightly more annoying than it's worth.

Pitfall 3: You will not know which channel actually works

We spent money on a few channels and had no idea which one produced paying customers. Client-side analytics told us about pageviews. It told us nothing trustworthy about purchases, because ad blockers and the gap between "clicked an ad on Monday" and "paid on Thursday" quietly destroy attribution.

The thing that fixed it was moving attribution server-side: stamp the acquisition source when the account is created, carry it through, and fire the conversion from the backend when money actually changes hands — including the offline-conversion uploads back to Google Ads and the pixel events platforms expect. Suddenly "this campaign cost $X and produced Y paying users" was a sentence we could finish.

If you're running any paid acquisition for an AI product, do the server-side version early. The client-side numbers feel fine right up until you try to make a budget decision with them.

Pitfall 4: An affiliate program is an accounting system wearing a marketing hat

This one humbled us. "Let people refer others for a cut" sounds like a referral link and a counter. It is not.

The instant real money is owed to real people, you're running double-entry accounting whether you meant to or not. A referred customer asks for a refund — now you have to claw back the commission you already credited the affiliate. Someone wants to cash out (in our case people asked for USDT). Promo codes stack in ways you didn't intend. Get any of this slightly wrong and you're not shipping a bug, you owe someone the wrong amount of money.

We ended up treating the whole thing as a proper ledger — every credit and clawback is a balanced entry — because that's the only way the numbers stay defensible when an affiliate disputes their payout.

Pitfall 5: The "rest of the backend" is a second full-time job

Auth. Background workers for anything slower than a request (we used BullMQ on Redis). Lifecycle email so trials don't silently lapse. An admin panel so you can actually look at a customer when they email you. Then Docker, then Kubernetes, then CI/CD so a deploy isn't a held breath.

Each of these is a known, solved problem. The cost isn't difficulty — it's count. There are a dozen of them, none is the thing you set out to build, and together they're where the months go.

So what did we do about it

We kept ripping these pieces out of one product and into something reusable, and eventually it became its own open-source project: Velobase Harness — MIT licensed, Next.js 15 / React 19 / tRPC / Prisma / Postgres, with the usage billing, server-side attribution, affiliate ledger, anti-abuse stack, workers, and deploy config already wired together. It's the scaffolding we wish we'd had before pitfall 1.

We're not going to pretend it's the only way to do this — plenty of people would (and do) assemble these from separate services, and that's a legitimate choice. We just got tired of rebuilding the same plumbing for every AI idea.

What we're actually curious about, and the reason we wrote this down: for those of you who've taken an AI product past the demo — which of these bit you hardest? And did you build the billing/abuse/attribution layer yourself, reach for something off-the-shelf, or just... not, and hope? We're collecting war stories and genuinely want to hear how other people drew the line.