I spent 3 weeks wiring Stripe + auth + LLM routing. Here's what indie hackers should skip.

The split I would use is: borrow commodity plumbing, but own the data model that defines trust in your product.

Auth, billing, model gateways, and basic observability are usually good candidates to buy or borrow. But if an agent influences a high-impact decision, I would preserve the exact source, prompt, policy, permission, model, and tool versions used during the run from day one. Retrofitting point-in-time reconstruction after customers depend on the system is much harder than adding another provider later.

The useful test is not only “will customers pay for this infrastructure?” It is also “does this infrastructure encode the reason customers can trust the outcome?”

Same pain, different domain.

Building Incipite (blockchain proof of authorship for creators), OpenTimestamps integration ate three weeks: calibration files larger than the actual data, Bitcoin network latency, and Next.js serverless timeouts nobody had documented for this use case.

Customers still don't know any of this exists. They just want the PDF that says their work was first.

One Stripe-specific thing I'd add: req.text() vs req.json() for webhook signature validation. Using json() silently kills the HMAC — the request body gets reparsed and the signature fails. Half a day lost before a forum comment saved me.

This hits close to home, though from a different angle — I'm not building AI SaaS, but the "week one is supposed to be product, it becomes cookies and sessions" pattern is universal to solo building. I've been heads-down on a browser-based tool and the amount of time that goes into stuff nobody will ever notice or thank you for (edge case handling, cross-device quirks, fallback logic) versus actual user-facing features is wild. Nobody's going to compliment your error handling, but they'll absolutely notice if it's missing.
The "own your product, borrow the platform" framing is a good mental model even outside AI specifically — I think every solo builder eventually has to decide which parts of the stack are worth reinventing and which aren't. Good luck with the launch.

Great post. The two-layer infra reality is exactly what slows most indie devs down. I run an API marketplace with per-call billing using x402 protocol + PayPal, and the payment orchestration was harder than the actual API routing. Stripe webhooks alone have ~15 edge cases around subscription state transitions. For LLM routing, starting with a single provider + simple cost logging, then adding multi-provider failover only after real usage data justified it, saved weeks. Ship the product first, iterate the infra later.

"We fail because we rebuild the same plumbing before the product exists" - painfully accurate. I went through something similar with Paddle instead of Stripe for my own project: webhook signature verification, idempotency on retried events, handling the subscription-canceled-but-still-active-until-period-end edge case. None of that is the product, but skip any of it and you find out the hard way during a real transaction.

Curious what you ended up doing for the auth part specifically - build it yourself, or lean on something like Clerk/Supabase auth to skip that week entirely?

this hits close to home lol. spent way too long early on trying to get every piece "production ready" before i had a single real user. wish someone had told me to just duct tape it together and go talk to people first

This matches my experience almost exactly. I'm building ReportSync (turns spreadsheets into board-ready reports), and the AI part was actually the smaller lift. The real time sink was chart auto-detection across messy, inconsistent spreadsheets people actually upload, and keeping the AI summary grounded in the real numbers instead of confidently making things up. The "boring" infra — live links, view tracking, PDF/PPTX export — ended up costing just as much time as the AI pipeline. Nobody notices it until it breaks, but it's most of the calendar.

The part that resonates is that AI products have two infrastructure layers: normal SaaS plumbing and AI plumbing. A lot of founders budget for the first and discover the second halfway through the build.

One thing I'd caution against is solving all of AI infrastructure before you have user feedback. I've seen teams spend weeks building provider fail-over, agent orchestration, and observability when a single-model setup would have been enough to validate demand.

The sweet spot is usually: auth + billing + one reliable model + minimal logging, then add RAG, multi-provider routing, and agents only after users are hitting real limits. Otherwise the platform becomes the product before the product has proven itself.

The rule I’d add is: borrow infrastructure, but own the exit path and the operational evidence. A boilerplate saves weeks only if you can still inspect billing state, model cost, failed agent runs, and export the data when the abstraction stops fitting. Otherwise the plumbing debt is postponed rather than removed.

I recently launched a product. The events when:

• identify gap
• scope build
• build

Then when the build was complete, I thought "okay, time to bolt on Stripe" and what a naive thought it was. I probably burned 3 weeks learning Stripe and getting its plumbing to work. With hindsight, I should have budgetted more time for the billing integration.

The plumbing problem is real, but I'd keep validating what founders are actually buying. They may not be buying a boilerplate—they may be buying the confidence that they can reach users before infrastructure becomes the bottleneck. That's a stronger promise than "auth + Stripe + RAG in one package."

The hidden cost of AI SaaS is all the stuff nobody sees. I’ve burned time on billing, limits, and infra too. The product idea usually isn’t the hard part.

hey guys anyone want to take a part in answering questions about the tech stack they use , i'm hosting a builder talks in my website that might help people who are new or confused to what tool to use when they are from real builders like you guys .

actually for me airwallex is the best payment gateway for buisnesses in USA and Canada

"Borrow the platform, own your code" is solid advice. I’d take it a step further: own your execution state too.

Prebuilt templates let you spin up auth, billing and RAG in no time. But if your AI context, task checkpoints and command logs are all trapped inside the template’s database, you’re locked in. Every time you swap models, pause a long task or hand work to someone else, you get hit with that costly context rebuild tax all over again.

A portable single-file state format lets your work flow freely between tools, no repeated context reconstruction needed. Leverage outside platforms, but keep your single source of truth in a file you fully control.

This hits home. Spent 2 weeks on Stripe webhooks alone before realizing I was building infrastructure instead of product. The "borrow a platform" mindset shift is real — wish I had internalized it earlier.

"Build the product. Borrow the platform." — this is the line I wish I'd had tattooed somewhere visible when I started.

Building an AI content tool for Vietnamese e-commerce sellers, I fell into this exact trap. Spent the first weeks obsessing over the LLM routing setup and prompt versioning system before I even had 5 users. Completely backwards.

What snapped me out of it: I forced myself to do a "calendar test" (your framing is perfect). I looked at where my hours were going and realized I was spending 80% of the week building infrastructure I was proud of, and 20% actually talking to shop owners. Flipped the ratio and got more signal in one week of user conversations than in the prior month of building.

The piece on Stripe webhook edge cases is also gold — the unpaid + incomplete_expired gotchas are exactly the type of thing that burns you at the worst possible moment (your first real customer churning for a billing bug).

One thing I'd add to your list: language/locale handling. If you're building for non-English markets, baking in locale support as an afterthought later is significantly more painful than just building for it from day one. Lesson learned the hard way.

Replying to the actual ask at the end rather than the pitch: for me it wasn't Stripe or auth, it was platform fragility. I'm building on top of someone else's UI (not a SaaS backend, a browser extension riding on a platform's DOM), and the calendar-eater turned out to be the same shape as your webhook problem but invisible until it bites - the platform changes a selector or a flow without warning, a feature silently breaks, and you don't find out until a user reports it days later. No amount of clean architecture on my side prevents that particular tax, because the failure point isn't in my code at all.

What ended up helping wasn't a boilerplate, it was building a cheap internal harness that runs my actual parsing/detection logic against real fixtures on a schedule, so breakage shows up as a red flag within hours instead of via a 1-star review a week later. Boring infra, but it's the thing that actually bought back calendar time - not because it made building faster, but because it stopped me from burning a week diagnosing "why did this randomly stop working" after the fact.

Great post and very informative! Im new to IH also in n the process of building my launch site, I'm seeing people posting about something called HugeLeap is that some kind of tool that i should be looking into?

The 'never invent infrastructure customers won't pay for' rule is right, but plumbing is often a symptom, not the disease. At SocialPost.ai we caught ourselves polishing internal tooling whenever the next user conversation felt uncomfortable, and I suspect half the founders stuck in week three of Stripe webhooks are hiding there too. Buy the boilerplate, sure, but the calendar test is hours talking to users versus hours on everything else.

Spending weeks wiring Stripe, auth, and LLM routing shows real commitment. It’s always tricky balancing infrastructure with product‑market fit. How did you decide when to stop building and start testing with users?

Auth and billing wiring is exactly the kind of code where I do not skip reading the diff even when an agent wrote it fast and every test passed. A subtly wrong webhook signature check or a missed edge case in subscription state can sit quiet for weeks before it costs real money. Three weeks for that stack sounds about right, in my experience most of the pain in that combo is edge cases, not the happy path. What is the one thing you would tell someone not to skip, the tedious part that bites you later if you shortcut it?