The Boring Parts Are the Product
Everyone wants to talk about AI agents. Nobody wants to talk about the onboarding flow that makes them usable.
There's a specific moment in every build where the exciting part ends and the real work begins. For Handled — our AI operations platform for small businesses — that moment came about three weeks ago. We had thirteen Claude-powered agents running on Railway, doing genuinely useful things: drafting follow-up emails, triaging inbound leads, summarizing customer conversations. The demo was impressive. The product was not.
Because here's what nobody had: a way to sign up, pay, get credentials, log in, and actually see their data. You know, the product.
The unglamorous stack
I spent the better part of two weeks wiring together what I'd call "the boring stack." Stripe Checkout for payments. A Cloudflare Pages function that takes an intake form, provisions a business in the backend, hashes a temporary password with PBKDF2, mints a JWT, stores everything in KV, and fires off a welcome email through Resend with the customer's login credentials. Then a dashboard that pulls real data from the backend API — not mock data, not a Figma prototype, real numbers from a real database.
None of that is interesting to talk about at a meetup. All of it is required for someone to give you money.
This is the gap I keep seeing in the "AI tools" space. Builders get high on the agent demo and then wonder why nobody converts. The answer is almost always the same: you built the brain but forgot the body. No onboarding. No billing. No way for a non-technical person to go from "this looks cool" to "this is running my follow-ups."
What I actually learned
A few specific things came out of this work that I think are worth sharing.
Cloudflare Pages Functions are underrated for this kind of thing. I needed lightweight server-side logic — not a full backend, just a few API routes for checkout, onboarding, and auth. Pages Functions gave me that without spinning up another service. The KV store handles onboarding state. The JWT auth is minimal but real. Total infrastructure cost for the frontend: zero dollars.
Resend over SendGrid, every time. For transactional email at this scale — welcome emails, password resets eventually — Resend is absurdly simple. Verified the domain, pointed the DNS, and had branded emails sending from hello@handledagency.co in under an hour. The DX gap between Resend and legacy email providers is enormous.
Twilio on a trial account will waste your time. We wired up SMS through Twilio for inbound webhook handling, and carrier filtering on the trial tier blocks delivery to almost everyone. The integration works — the webhooks fire, the agents process the messages — but the messages never arrive. If SMS is part of your product, budget for the paid tier from day one or don't bother building the feature until you can test it properly.
The principle underneath
There's a pattern here that applies beyond AI tools. The interesting technical work and the valuable product work are usually different things. The thirteen agents were the interesting work. The Stripe-to-KV-to-Resend pipeline was the valuable work. One makes for good demos. The other makes for paying customers.
I think a lot of indie builders — myself included, historically — get stuck in an infinite loop of interesting work. You build the core thing, it's cool, and then you start building the next core thing instead of wrapping the first one in everything it needs to actually function as a product. I've got a whole portfolio of projects in various states of "the cool part works" that proves this point.
The shift I'm trying to make, and the one I'd recommend if you recognize yourself in any of this: treat the boring parts as the product. The onboarding flow is the product. The billing integration is the product. The error state when someone's credit card gets declined is the product. The AI agent that drafts perfect follow-up emails is a feature. The system that lets a plumber in Greenville, South Carolina sign up and start using it without calling you — that's the product.
The takeaway
Before you build your next feature, audit your current one. Can someone who has never talked to you go from discovering it to paying for it to using it without any manual intervention from you? If the answer is no, that's your next sprint. Not the new model, not the extra agent, not the UI redesign. The boring parts. They're the product.