Independent client · Build record
Ladies 4 Jesus: a moderated community the owner runs alone
A faith community site where women submit testimonies, questions and comments, and where nothing a visitor writes appears in public until the owner has read and approved it. The interesting engineering here is not speed. It is that a non-technical owner runs the entire site — content, moderation, gallery and settings — without a developer in the loop.
Published August 7, 2026. Live at www.ladies4jesus.com.
“I was hesitant to use them at first because the price seemed more than reasonable and I had never heard of them but I am so glad I chose to work with them.”
“Hassan and his team were wonderful to work with. They created a phenomenal website for me. I couldn't be happier. I highly recommend.”
— Etoy McDaniel. Unprompted review on Trustpilot, August 2026.
That is one client's experience and it is worth reading for the hesitation rather than the praise. A price below what someone expects, from a company they have not heard of, is a reasonable thing to be cautious about. It is a fair reaction to a real signal, and the only useful answer to it is finished work somebody can go and look at.
What this record does and does not prove
This is a build record, not a performance comparison.The project was a migration, but the previous platform's load times and monthly costs were never recorded before it was replaced — so there is no baseline, and no honest before-and-after to publish. We are not quoting a launch score either, because a number with nothing to compare it against is decoration rather than evidence.
That is worth saying out loud, because it is a mistake anyone can avoid. Measure load time, PageSpeed and the actual monthly bill before you migrate. The day the old site is switched off is the day that evidence stops existing, and no amount of later work recovers it.
What is verifiable is the architecture, and you can check the search-facing parts of it yourself on the live site: the pages are indexable, each carries a canonical URL and an Open Graph image, and the root layout emits an Organization and WebSite JSON-LD graph. No traffic, ranking or revenue outcome is claimed on this page.
The brief was "I need to run this myself"
The deciding requirement was not design and it was not speed. The owner needed to run the entire site without calling anyone.Approve a testimony at nine in the evening. Swap the gallery photos after a Paint & Praise session. Fix a typo in the About story. Answer a question that came in overnight. None of those can involve a developer, because a community site where publishing requires a support ticket is a community site that goes quiet.
That turned the admin experience into the actual deliverable, and it is why the CMS choice mattered more than the framework choice. Sanity was picked because its editing interface is genuinely usable by a non-technical person and because the Studio embeds directly in the application — so there is one login, one place to go, and no second system to learn.
What she can change without us
Effectively all of it. Nine content types are editable in the Studio, and edits reach the live site in about a minute through incremental regeneration — no deploy, no developer, no waiting on anyone's availability:
| She controls | Without touching code |
|---|---|
| Site identity | Logo, hero, founder section, section imagery, social profiles |
| Devotionals | Title, body, scripture reference, category — published on her schedule |
| Testimonies | Read, approve, reject. Nothing appears publicly until she says so |
| Q&A | Answer submitted questions and categorise them |
| Comments & reports | Moderate replies and act on flagged content |
| Paint & Praise | Page copy, feature cards and the photo gallery, swappable after every session |
| Standing pages | About, Contact and the salvation page, body copy and galleries |
| Messages | Contact submissions arrive in the same place as everything else |
The reasoning behind the pairing, and what it costs, is set out in our guide to Next.js with Sanity. The same stack under commerce load, with the founder-affiliation disclosed, is Panda Patches.
The only thing that still needs a developer is a schema change — adding a new kind of content rather than new content. That boundary is deliberate and worth stating to any owner evaluating a CMS: changing what the data says should never need an engineer; changing what shape the data has, should.
Why moderation had to be structural
A community site that invites strangers to publish personal stories has a problem most marketing sites never face: everything a visitor writes is a publication decision. Testimonies, questions, comments, contact messages and reports all arrive from the public, and all of them carry the owner's name once they are visible.
So approval is enforced in the data layer rather than in the interface. Submissions are written server-side in a pending state, and the public queries filter on that status — which means an unapproved testimony cannot reach a visitor even through a bug in the page code. Moderation you can accidentally bypass is not moderation.
Four decisions that carry the site
Moderation before publication, enforced in the query
Five of the nine content types are visitor-submitted. Each is written server-side in a pending state and filtered out of every public query until the owner approves it. Approval is a data change, not a deploy.
Video with a cleanup path, not just an upload path
Testimonies accept a direct video upload or a YouTube/Vimeo link. A webhook deletes the stored file when a testimony is rejected or removed, and a scheduled job sweeps abandoned uploads that no webhook would ever fire for.
An owner who is not a developer
Copy, imagery, gallery, devotionals, Q&A and site settings are all editable in an embedded Studio. Content reaches the live site in about a minute through incremental regeneration, with no code deploy in the loop.
Search that reads the body, not just the title
Stories, devotionals and Q&A share one search component that matches against title and body text, reports a result count, and scrolls to results on submit. Title-prefix search would have missed the phrase most visitors actually remember.
The cleanup nobody builds
Video testimonies are the part of this build worth copying. Accepting an upload is straightforward. What most implementations skip is what happens to the file afterwards, and there are two distinct leaks:
- A testimony is rejected or deleted, and its video stays in storage forever. Handled by a webhook that fires on that change and deletes the blob.
- A visitor uploads a video and then abandons the form. No document is ever created, so no webhook can fire. Handled by a scheduled job that sweeps orphaned uploads.
The second one is the one that gets missed, because it never produces a visible bug. It produces a storage bill that grows quietly and an owner who cannot explain it.
What was built
| Layer | Implementation |
|---|---|
| Framework | Next.js 16 App Router with React Server Components, TypeScript |
| CMS | Sanity, Studio embedded in the app at /studio, nine content types |
| Submissions | Five moderated paths, written server-side, filtered from public queries until approved |
| Video | Direct upload to blob storage or an embedded link, with webhook and scheduled cleanup |
| Search | Shared component matching title and body across three sections, with result count |
| Security | Strict CSP and security headers on the public site; the authenticated Studio route scoped out deliberately |
| Search visibility | Per-page metadata and canonicals, generated sitemap and robots, Organization and WebSite JSON-LD |
| Tests | Unit tests and end-to-end browser tests, both runnable in CI |
Frequently asked questions
Frequently Asked Questions
Why does this case study have no before-and-after performance numbers?
This was a migration, but nobody recorded the previous platform's load times or hosting costs before it was replaced, so there is no baseline to compare a launch reading against. Our MyCustomPatches record captured a before-and-after because those readings were taken on the old site while it was still running, though the performance figures from that project are themselves withdrawn pending reconciliation, which makes the same point twice over. Here they were not, and inventing a plausible 'before' after the fact is exactly the kind of number this firm spent a month removing from its own writing. The lesson generalises: capture load time, PageSpeed and the actual monthly bill before you migrate, because the day the old site is switched off is the day that evidence stops existing.
How does the moderation workflow actually work?
Five of the nine content types are visitor-submitted: testimonies, questions, comments, contact messages, and content reports. Each carries a moderation status and is written to the CMS in a pending state by a server-side route, never directly from the browser. Nothing a visitor submits is rendered publicly until the owner sets it to approved in the Studio. The public queries filter on that status, so an unapproved item cannot appear even by accident.
What happens to a video when a testimony is rejected or deleted?
It is removed from storage rather than left to accumulate. Video testimonies upload directly to Vercel Blob, and a Sanity webhook fires on rejection or deletion to delete the associated blob. A separate scheduled job sweeps up abandoned uploads, which are the files a visitor uploads before abandoning the form and which no webhook would ever fire for. Most builds implement the upload and skip both cleanup paths, and the storage bill is where that decision eventually shows up.
Can the owner change content without a developer?
Yes, and that was the point of the architecture. The Sanity Studio is embedded in the application at /studio, and content edits reach the live site in about sixty seconds through incremental regeneration, with no deploy and no developer involved. Schema changes still ship with a normal git push, because those change the shape of the data rather than its contents.
Why is the Studio route exempt from the Content-Security-Policy?
Because the Studio is an authenticated admin application that loads its own assets and opens its own connections, and a strict policy written for the public site blocks it. The exemption is scoped to that one route deliberately rather than loosened site-wide. The public site keeps a strict policy with image, media and frame sources limited to the CMS CDN, the blob store, and the two video hosts the site actually embeds.
Building something people submit to?
Moderation, storage lifecycle and admin usability are the three things that decide whether a community site is still running in a year. We scope them before the design, not after launch.
What other clients said
Different projects, different people. Each one links to the review on Trustpilot so you can read it in full rather than take the excerpt on trust.
“It looks premium, loads fast, and perfectly captures Emblematic Studio's brand.”
“Hassan was super helpful and communicative throughout the process.”
“They worked with me to make a website that I could afford.”
“Hassan was available to me at any time, and his response time was always less than an hour.”