Be a Giver!
“It is more blessed to give than to receive.”Acts 20:35
Giving is bigger than money — time, a skill, a kind word, a prayer. Nobody is empty.
Case study · CP Devotional
A daily devotional, reviewed by people.
A devotional app I designed and shipped by directing an AI coding agent through every decision, from the first idea to a live product people use every day.
Now on Google Play
Devotion
Testimony
Gospel music · Praise
The Stranger Who Gave Away Everything
As a boy, Jimmy Darts handed a homeless man a hundred-dollar bill — and never forgot his face.
The One in the Room
How this was built: I make the calls: what to build, which trade-offs to accept, what's broken and why it matters. An AI coding agent writes the code and implements each change, under my direction and review. Every decision on this page is mine; the implementation is the agent's.
- Directed by
- Uzo Nwokoro
- Runs for
- ~$25–30 / month
- Shipped
- 214 commits since July 2026
- Live on
- Google Play & the web
01 · What it does
Three practices, in any order.
Devotion
A daily reading built around a Bible passage, to read or listen to.
Testimonies
Real, sourced stories that match the day's theme.
Gospel music
Three songs a day, with favourites members can keep.
Members reach each practice from a menu and open them in any order. An earlier version pushed everyone through one fixed sequence every time. Once it was clear people mostly wanted to jump straight to the one thing they came for, I rebuilt the app around letting them do that.
Everything a member sees, the devotion, its testimony and the day's three songs, passes through the same draft-then-approve process before it goes live.
02 · How it's built
Two apps, one server.
A website and a mobile app, both talking to the same server, which is the only piece that reaches the database and outside services.
Why one server, not two
Running the website and the server separately would cost more each month for no real benefit at this size, so they share one.
Why two apps, not one shared codebase
Building each screen twice is more work up front, but each app feels native to its platform instead of a compromise between the two.
How it stays unbroken
Automated checks run on every change before it can go live, with the closest attention on accounts, security and content review, where a bug would do real damage.
03 · How the app works
Nothing goes live without review.
The path each kind of content takes from a first idea to something a member sees.
Devotion & testimony
The devotion and its testimony are drafted and reviewed side by side, then approved and paired in a single action.
Devotion
- 1
Idea
An author picks a title, or asks the built-in assistant for one to start from.
- 2
Draft
The full devotion is written, often AI-assisted.
The Bible verse text is always fetched fresh from a trusted source, never taken from the AI's memory. - 3
Review
A person reads every draft before it can move on. Nothing skips this step.
Testimony
- 4
Search
The app looks for a real, verifiable testimony matching the devotion's theme, or an author supplies one.
- 5
Draft
A short account is written, always linked to its source.
If nothing real and checkable turns up, it says so instead of inventing one. - 6
Review
A person opens the source and checks it, the same standard as the devotion.
- 7a
Approve & pair
The devotion is approved with the exact testimony reviewed alongside it.
Not whichever testimony is next in line, so the two can never drift apart later. - 7b
Schedule
The approved pair takes the next open day.
Counting starts from tomorrow, because today's slot may already belong to something approved earlier. - 7c
Publish
On its date, the devotion and testimony go live for every member.
Gospel music
Songs come from a standing catalogue, so the path is shorter, but it ends at the same review gate.
- 1
Add to the library
Each track is catalogued with title, artist and category.
- 2
Auto-pick three
The app suggests the next set of three.
Favouring songs that haven't played in a while, so the rotation stays fresh without anyone tracking it. - 3
Adjust
An author can swap any song before review.
- 4
Review & approve
A person checks and approves the set.
- 5
Schedule
Approved sets queue up on their own, first approved, first played.
- 6
Publish
On its day the three songs go live, ready to play and favourite.
04 · Using AI responsibly
AI drafts. People decide.
AI drafts devotions, finds real testimonies and suggests writing prompts, but it never publishes anything by itself.
A person reviews everything
AI-drafted content goes through exactly the same approve-before-publish step as anything written by hand.
The AI doesn't own the facts
Verse text is always looked up from a proper source rather than trusting the model to remember it correctly.
The right model for the stakes
Small suggestions use a faster, cheaper model; anything a member will read uses a stronger one.
05 · What it costs to run
About $25–30 a month.
File storage, email delivery and Bible verse lookups currently sit inside their providers' free tiers. The AI line is the only one that moves with usage; the rest are flat subscriptions. These are estimates, not months of billing history.
| Item | Monthly |
|---|---|
| Hosting (server + database) | $12.00 |
| Music subscription | $10.00 |
| AI writing assistant | ~$1–6 |
| Domain name | ~$1–2 |
| App store registration | $0.42 |
| Total | ~$25–30 |
06 · Problems I solved
Real problems, and what each one shows.
A pairing that could quietly fall out of sync
Each devotion is matched with a related, real testimony. Early on, both were picked independently, "the next devotion" and "the next testimony", which worked until someone removed one item from either list. Then a testimony could appear next to a devotion it was never reviewed with. Now the app remembers exactly which testimony was approved with which devotion, and discarding a devotion discards its testimony too.
Catching bugs that only appear once something changes later, not just testing the obvious case.
A duplicate that only looked different
"Trust God" and "trust god" passed as two different titles. The check now ignores capitalisation, and it runs before the AI generates anything, so a rejected duplicate never costs a paid AI request.
Noticing the edge case a real person will hit, and fixing it in a way that also saves money.
Never revealing who has an account
Suggested by the AI coding agent · reviewed and approved by me
If "forgot password" answered differently, or even faster, when an address had no account, someone could test a list of emails and learn who is registered. The app now gives the same reply in the same time either way, sending any email in the background.
Understanding an AI-suggested fix well enough to explain it and stand behind it.
A permission limited by what it could cost
One admin tool could regenerate a batch of AI writing prompts as often as someone clicked, and every click was a paid request. That action is now owner-only, while a cheaper, capped version stays open to other admins.
Some safeguards protect the budget, not just the data.
Reversing a decision once the evidence came in
I moved one AI feature to a free-tier provider to cut costs. Under real use the free capacity ran out almost immediately, so I reverted the next day rather than keep complexity around a plan that wasn't working.
Trusting the real result over the original plan, and changing course quickly.
Removing unfinished ideas instead of leaving them half-built
Two early features got placeholder screens and some backend work, then didn't make the final plan. I removed them completely, so if either returns it starts clean.
Knowing the difference between "not right now" and "sort of, halfway".
Two mistakes in two days changed how the database is managed
Database changes were made by hand until two incidents in two days: one missed update, then one that broke part of the admin dashboard. I switched to Alembic, which applies every change automatically and in order, so the same mistake can't happen the same way again.
Treating a repeated mistake as a reason to fix the process, not just the symptom.
07 · What I'd still improve
Naming what isn't finished.
- Test coverage is thin outside accounts and content review. Most of what a member sees on the website and mobile app isn't automatically tested yet.
- The login-attempt limiter assumes one server. If the app ever ran on several at once, it would need an upgrade.
- The monthly cost is a projection, not a bill. It's based on expected usage until there's enough real traffic to measure.
Try it