Validating Weekly Releases Across HelloBible's 20+ Services
HelloBible's home screen alone gives access to 20+ services - independent user paths with their own logic and edge cases - shipped by an offshore dev team on a weekly release cadence. Throughout 2025 I handled release validation across all services: I wrote the specs, tested every release, and drove the release validation process before each production deployment. The system that made that possible: AI-assisted specs to reduce clarification back-and-forth with offshore devs, a structured Google Sheet test plan covering every service, and three explicit test layers (staging, release candidate, production).
Context. HelloBible is a complex app with 20+ services accessible from the home screen alone. The dev team was offshore, around 5 devs. Releases shipped on a weekly cadence. A regression in one service could silently break another.
Result. Weekly releases shipped through this system throughout 2025. AI-assisted ticket writing reduced clarification back-and-forth with the offshore team. The Google Sheet test plan structured the cross-service testing routine before every release. Three test layers gave the team a clear escalation path proportional to release risk.
Throughout 2025, I handled release validation across HelloBible’s services. I wrote the specs, tested every release across 20+ services, and drove the release validation process before each production deployment. The work itself isn’t a build. It’s a function. This case study focuses on the release validation system I built to support weekly releases across multiple services.
The friction I found
HelloBible is a complex app. From the home screen alone, users can tap into 20+ services - each one an independent user path with its own logic, screens, and edge cases. The dev team was offshore, around 5 devs. Releases shipped on a weekly cadence.
Three risks stacked on top of each other:
- A regression in one service could silently break another. Without a written test plan, you forget a service and ship a bug.
- A vague ticket could ship the wrong feature. The offshore team builds what’s written, not what you meant.
- Cumulative review time. Test everything for every release and you bottleneck the dev cycle. Test too little and you ship regressions.
The three systems I built
1. AI-assisted ticket writing
I built a chat specifically prompted to write tickets when I dictated the key facts of a problem. The flow:
- I dictate the bug or feature request in a few keywords
- The chat generates the ticket structure: context, jobs to be done, affected devices, affected versions
- I fill in the specifics
- The output is standardized English documentation ready for the offshore team
The output structure stayed consistent enough to reduce repeated clarification with the offshore team. No more “wait, what device version did you say?” coming back from the devs three days later.
2. The Google Sheet test plan
20+ services means 20+ test areas before every release. Without a written plan, you forget one and ship a regression.
I built the test plan as a Google Sheet listing what had to be checked before each release: service, critical user path, expected behavior, and known edge cases. About 30 paths across the 20+ services. Before every release, I work through the sheet systematically. The sheet evolved over the year as we added services and found edge cases.
One example of what it caught: on the Verse of the Day service, the “Read the full chapter” button stopped working after a release. The sheet caught it before production because that path was in the systematic checklist - the kind of regression that slips through smoke tests when nobody happens to click that exact button.
3. Three test layers
Not every release gets the full test plan. I stratified the testing into three layers:
- Staging (dev environment): smoke tests after the dev hands off
- Release candidate (pre-production build): targeted regression on the changed services
- Production (after ship): monitoring + spot checks on the live app
This stratification kept the time investment proportional to the risk. A bug fix in one service doesn’t trigger the full 20-service test plan. A major feature does.
Why these three, not a SaaS tool
Monday was already the team’s ticket tracking system when I arrived. Rather than replace it with a dedicated QA platform (TestRail, Xray, etc.), I built the test validation system around it - keeping tool overhead at zero. The additions were the Google Sheet test plan and the AI-assisted spec system for offshore dev clarity.
- Monday for ticket tracking: already used by the team, no new tool to maintain
- Google Sheet for the test plan: everyone can edit, no permission setup, easy to evolve
- A prompted chat for ticket writing: no integration, no API, immediate value
The Google Sheet still works at 20+ services.
Where this lives now
Weekly releases in 2025 used this system as the validation frame.
In 2026, HelloBible moved from a 5-dev offshore team to a smaller in-house team of 2 senior devs. With more experienced developers on board, what ships works better and faster from the start - which lowers the validation overhead. Parts of the system, especially the test plan and validation structure, are still used when releases require broader regression coverage.
Want to talk about something like this?
Email me, send a LinkedIn message, or download the CV. Conversations are what this site is built for.