From 50 Minutes to 1 Second. 220 Times.

What this project actually proves

This is the cleanest example of my method at HelloBible. Spot the friction, decompose the problem, design the AI workflow, pilot Claude to write the code, validate every output by hand, ship, iterate, hand it off to itself.

The site you’re on demonstrates I can pilot AI to build something outside my skill set. This pipeline demonstrates the same thing applied to a real ops problem with real business stakes - because the output isn’t just plans, it’s a top-of-funnel acquisition channel. Every published plan ends with a bit.ly link that redirects readers to HelloBible. YouVersion has hundreds of millions of users. We’re systematically converting that audience into ours.

If you’re a founder or CPO and your team has a manual loop blocking a growth lever, this is the kind of system I show up to build.

---

The friction I found

Eric Célérier - HelloBible’s founder - had written 110 reading plans in French over the years and published them on YouVersion himself, by hand. Each plan is 3-7 days of devotional content, cited Bible verses in context, two branded images per plan.

To take HelloBible global, those 110 plans had to ship in every language we expand into. English and Dutch first, then dozens more. The catch is that each language requires:

• Translating the devotional text
• Finding the official Bible version for every cited verse (NIV for English, HSV for Dutch - you can’t translate the Bible itself, only the surrounding content)
• Rebuilding the plan structure in the YouVersion Partner Portal
• Sourcing and resizing two images per plan
• Validating everything visually before publishing

Time per plan, end to end: 40 to 50 minutes. Across 110 plans × 2 languages, that’s roughly 180 hours of manual work. And that’s just to start - the whole point is global expansion across dozens more languages.

There was one more friction nobody told me about until I started building: the YouVersion Partner Portal API is undocumented. No public reference, no SDK, no examples. I had to reverse-engineer the endpoints, payload shapes, and validation rules by intercepting network requests from the web UI and watching what worked. That alone took hours of focused work before any “real” code could be written.

---

The pivot that mattered

My first instinct was N8N. Visual workflow, easy debugging, what every “AI automation” tutorial recommends in 2026.

I built the workflow. It worked for two test plans. Then it broke because I couldn’t get Claude through MCP working reliably - the Safari cookie auth flow needed a tunnel I couldn’t stabilize. I spent half a day trying.

I killed it. Switched to terminal-based Node.js scripts running on my Mac. Less observable, less impressive on a slide. But it worked end-to-end in twenty minutes after the pivot.

This is one of the most useful operational reflexes I’ve built: pick the boring tool that ships over the impressive tool that almost works. Especially when the impressive tool keeps eating your time.

---

What I’m actually selling

When you hire a Product Ops who pilots AI in 2026, what you’re buying isn’t the artifact - it’s the loop:

1. Spot the friction with real numbers attached (40-50 min × 110 plans × 2 languages, then dozens more)
2. Decompose the work into a deterministic pipeline
3. Pick the right tool per step (DeepL for translation, Bible.com for verses, Pexels for images, YouVersion API for publishing)
4. Pilot Claude Code to write the actual code - read every diff, validate every decision
5. Run the pipeline, validate visually, find every bug, patch, resume
6. Stop touching it once it works

I don’t write code. I make every decision. I see every output. The result is a system that runs without me - which is the whole point.

The replication play is what makes this strategic, not just clever:

• New language: swap a Bible version ID, set a Polly voice ID, run the pipeline. HelloBible’s ambition is dozens of languages worldwide - the pipeline scales to all of them with the same architecture.
• Audit and clean French source plans: I ran the 110 originals through the same tooling to enforce consistency (Bible verses italicised, founder name bolded everywhere, all images regenerated to a new visual standard).
• New partner: the same pattern works for any creator publishing to YouVersion. One-week port whenever we want to onboard the next one.

That’s the actual asset. Not the 220 plans live today - the system that ships every plan after this one.

---

The technical architecture, if you want it

Stack

• Node.js ES modules, dotenv config
• DeepL Pro for the translation itself (not Claude - more on this below)
• Bible.com webproxy API for fetching official Bible verses by USFM reference
• YouVersion Partner Portal API (planportal.youversionapi.com/4.0) for creating and updating plans
• Canvas + Cairo with embedded Playfair Display TTF for image generation
• Pexels API for sourcing photos by theme
• MD5 caches for DeepL translations, Bible verses, and Pexels photos (cohérence between EN and NL versions of the same source plan)
• JSON files for progress tracking and idempotence

Why DeepL and not Claude for the translation

DeepL leads on European language quality, supports HTML mode natively (tag_handling: 'html' with ignore_tags: ['x'] to protect verse placeholders), and is significantly cheaper at scale than running translations through an LLM. Quality is also more consistent for this kind of long-form devotional content.

Claude is my coding assistant for the project, not a runtime component of the pipeline.

The non-trivial part: not translating the Bible

You can’t translate Bible verses. Each language has officially approved versions (NIV for English, HSV for Dutch since NBV21 was pulled in 2021). Translating them via LLM or DeepL would be theologically and legally wrong.

So the pipeline:

1. Extracts Bible verses from the source HTML
2. Replaces each one with a placeholder (VPHOLDER0, VPHOLDER1…)
3. Sends the HTML with placeholders through DeepL
4. Fetches the official target-language version of each verse from Bible.com using its USFM reference
5. Inserts the official verses back into the translated HTML
6. Re-syncs the references panel that YouVersion shows separately from the plan body

This step is what makes the pipeline non-trivial. Anyone can call DeepL. The interesting work is keeping the sacred text untouched while everything around it translates.

The reverse-engineered API

YouVersion’s Partner Portal has no public API documentation. To build the pipeline I had to:

• Inspect network requests in the web UI to map every endpoint
• Trial-and-error on payload shapes until validations stopped failing
• Identify hidden requirements (e.g. references panel must be synced separately from HTML body)
• Find the right status flow (draft → approved → published)
• Discover undocumented constants (Polly voice IDs, Bible version IDs, org IDs) by reading actual data on the platform

This is a few hours of work that doesn’t show up in any line count - but without it, nothing else ships.

Domain knowledge encoded

• USFM mapping for ~50 Bible books across French, Dutch, English (Genèse → GEN, Mattheüs → MAT, etc.)
• Bible version IDs (NIV=111, HSV=1990, BGT=3743)
• Polly voice IDs per language for audio narration
• YouVersion org ID (823 for Eric Célérier)
• 30 regex patterns to detect plan themes (lion, shepherd, water, peace, mountain…) for matching Pexels image queries
• Brand-specific patterns: stripping promotional P.S. blocks, preserving brand hashtags untranslated, gras “Eric Célérier” handling

Flow end-to-end per plan

1. Load source plan (French) from local JSON
2. Translate title, description, keywords via DeepL in parallel
3. POST createPlan to YouVersion → get plan ID back
4. PATCH plan metadata (CTA link, Polly voice ID, Bible version ID)
5. For each day:
   • Concatenate multiple content blocks (one of the bugs I had to fix)
   • Clean HTML (strip P.S., Conseil, stars)
   • Protect verses with placeholders
   • Translate via DeepL
   • Fetch and restore official verses
   • Patch the day into YouVersion
6. Generate 1440×810 hero image and 320×320 thumbnail via Canvas + Pexels (cached per source plan ID for EN/NL consistency)
7. Upload images, set plan images
8. Save progress to data/progress.json
9. Re-publish via separate republish-plans.js script

---

What broke

Every interesting pipeline has a list of bugs that nearly killed it. The honest ones:

• DeepL Free quota exhausted silently because an auto-test was running on every script import - draining quota without me knowing. Caught it when plans started coming out empty.
• French verses skipping translation in 10 plans because my isFrench() detector missed phrases without accents.
• Multi-block days collapsing to the first block - my .find() only captured the first text block, so plans with multiple text blocks per day showed only the title. Affected 4 plans. Had to write a separate fix script.
• Long Dutch titles overflowing 320×320 thumbnails - words like “Ondoorgrondelijke” (19 characters) needed 3 levels of adaptive font sizing.
• DeepL “Quota exceeded” with quota actually remaining - turns out you have to set the spending cap explicitly in DeepL Pro settings. Nowhere obvious in the docs.

I’m listing these because the loop “ship → spot the bug → patch → resume” is the whole skill. Every system I’ve shipped has a list like this.

---

Where this lives now

Pipeline operational. 220 translated plans live, plus the 110 French source plans audited and cleaned. Code on GitHub. Maintenance is minimal - mostly running the pipeline for new plans and new languages as they come in.

The next language is one Bible version ID away. The next partner is a one-week port. That’s the part that matters strategically.