Day 35: Six help articles, zero shortcuts

Day 35 was session two of three in the Help Center sprint. Day 34 built the foundation — MDX loader, five category routes, three seed articles in getting-started. Day 35 was pure content. Six articles across the two categories that actually determine whether a paying customer trusts the product: billing (does this cost what I think it costs, can I leave) and reviews-and-replies (is the AI worth paying for, what happens when someone leaves a 1-star). Day 36 closes the Help Center sprint.

Billing articles: answering the questions that block the upgrade

Three articles, one goal: remove every billing-related reason to delay upgrading or email support.

Upgrading your plan isn't just "click the button." The article explains proration math — why the first charge after an upgrade differs from your renewal amount — what features unlock immediately, and the founding pricing lock. Customers who understand proration don't email asking why they were charged an unexpected amount. The article does the explanation once so I don't have to do it six times over support messages.

Cancelling your subscription is the article most SaaS companies write defensively. The Ominvo version is transparent: what happens at period end (access continues until it expires), what gets deleted versus preserved (business data soft-deleted, Stripe subscription cancelled automatically), and how to resubscribe. If someone wants to leave, making it easy to leave and easy to come back is the right posture. Customers who can cancel without friction are less likely to feel trapped, and less likely to dispute a charge.

Invoices and payment method is the accountant article. How to access the Stripe customer portal, where receipts live, how to update a card, and a roadmap note on annual billing. Small businesses need this for their bookkeeper. The article takes 90 seconds to read and will save multiple support messages per month.

The principle: billing docs aren't about retention. They're about trust. A customer who understands exactly what they're paying for and exactly how to stop it pays longer and asks fewer questions. Writing billing docs defensively — burying cancellation steps, hedging on refunds — is a tell. It signals that you don't trust your own product to keep people subscribed on merit.

Reviews-and-replies: the articles that earn the AI's credibility

Three articles that answer the questions a potential customer has before they hand over a card number.

How AI replies work is the most important trust article in the entire Help Center. It's explicit about what the model sees — review text, star rating, business name, industry, tone preferences — and what it doesn't see. It's explicit that Ominvo does not auto-post anything; every reply goes through you before it touches Google. It's explicit that Anthropic does not train their models on API data. If a potential customer reads this article and still doesn't trust the AI, they're not the target customer. That's fine. The article exists to make that decision clear, not to paper over it with vague reassurances.

Editing and approving replies is the 60-second workflow article. Click, read, edit if needed, approve. The article explains why there's no "reject and regenerate" button: editing is faster than regenerating from scratch, and it teaches you specifically what the AI gets wrong about your business. One round of editing per review. The framing matters — it positions editing as information-gathering about your own tone, not as fixing the AI's failures.

Responding to negative reviews is the most tactically useful article in the Help Center, regardless of whether you use AI. The framework — acknowledge, offer to take it offline, keep the public reply short — holds whether you're writing manually or reviewing a draft. The article covers what the AI does conservatively on 1 and 2-star reviews versus 4 and 5-star, and why public rebuttals almost always backfire even when you're factually correct. The short version: arguing with a customer in a Google review makes you look defensive to every future reader, not just the one you're arguing with.

The one-liner that was actually three one-liners

The redirectTo parameter on the login page — first wired to /admin on Day 34 — needed to be applied to the remaining three protected routes. Each change was one line per file:

• /dashboard → /login?redirectTo=/dashboard
• /settings → /login?redirectTo=/settings
• /reviews → /login?redirectTo=/reviews

Before: a signed-out user clicking a bookmarked link to /settings landed on /dashboard after login and had to navigate again. After: they land on /settings. The fix is invisible to users who stay logged in continuously — and removes real friction for anyone who gets logged out mid-session and clicks a direct link.

safe-redirect.ts, written on Day 34, already validates the redirectTo parameter against open-redirect attacks — rejecting external URLs, backslash smuggling, and embedded protocols. Three new lines in three files, zero new security surface area. This is the kind of sweep that only costs time if you defer it until there are users experiencing the problem.

What's left

Day 36 closes the sprint — six more articles across integrations and account-and-security, plus the thumbs y/n backend wired to Supabase instead of dying in console.warn. After Day 36 the Help Center is at 15 articles and content-complete for launch.

The remaining pre-launch work shifts back to product: annual billing, real testimonials, and Stripe live-mode prep. The full list of what shipped each day is in the changelog. Three focused days of content work — not three months of slow-drip writing — is the right model for a pre-launch knowledge base. Scope it, sprint it, ship it.