What to check before choosing sermon-repurposing software

Before comparing sermon-repurposing software, define what your church needs to finish.

A generated draft is not a reviewed asset. An export is not a scheduled item. A provider receipt is not proof that the right post is visible on the right account.

Without a shared finish line, a feature comparison rewards breadth. It hides the work that determines whether a post is accurate, approved, accessible, and recoverable.

Then test one ordinary sermon that your church has permission to use. Follow it through the whole route. Count setup, source repair, human decisions, editing, handoffs, failed states, destination checks, and the evidence kept for a later correction.

Public product pages can tell you what a vendor offers. They cannot tell you what your church will have to fix or wait for.

Church Media Kit team makes Church Media Kit and has a commercial interest in this guide. This is a maker-authored checklist, not an independent review.

We checked public vendor pages, the reviewed Church Media Kit build and records, and relevant commercial, legal, privacy, and deployment records on 29 August 2026 from Canada. We used public, logged-out access for external pages. We did not create vendor accounts, use a trial, buy a plan, run vendor outputs, contact sales, or perform an independent side-by-side test.

Where vendor pages exposed both monthly and annual billing, we checked both views. The named sermon-software pages displayed USD. Prices, taxes, limits, plan contents, and eligibility can change. Vendor statements below remain vendor statements. A feature missing from one public page is not proof that the product lacks it.

Start with the completion definition

Write one sentence that describes done. For example:

One approved static teaching post is visible on the intended account with the final wording, crop, link, audience, and alternative text checked, and the source and approval record retained.

Your finish line may stop at an approved local export. That is valid. Just do not compare it with another route whose finish line includes provider delivery and native inspection.

Software should be compared against the last state your church actually requires, not the first state a product can create.

Check the source and rights path

Start with what the product can accept under the exact plan you would buy. Products in this category describe different combinations of public links, private links, files, documents, slides, audio, and recorded messages. Do not assume the category name means every product supports the same sources.

Ask these questions:

• Which source types are accepted, and which require public access?
• Does the product retrieve existing captions, transcribe an audio track, read a supplied document, or use another method?
• Which languages and caption tracks are supported?
• Can a reviewer trace a candidate back to source words and a useful time range?
• Are exact quotations, paraphrases, and summaries labelled differently?
• What happens when captions are missing, incomplete, or wrong?
• What happens when the source cannot be reached temporarily?
• Can a reviewer replace or correct the source without losing the decision record?
• Who confirms that the church may process and republish the sermon and every included work?
• Does the vendor verify rights, or merely record the user's statement?

YouTube says a transcript is available when an item has captions. A public YouTube URL therefore does not prove that useful transcript evidence exists. A saved URL with no sermon words is a source reference, not a transcript.

Availability also does not settle permission. YouTube's copyright overview and licence guidance make clear that material appearing on YouTube does not grant another party the right to reuse it.

A church may own its recording while still needing to consider music, Scripture editions, guest speakers, photographs, identifiable stories, and other included material.

A checkbox can record the church's statement. It cannot investigate or grant rights.

Match the output to the actual job

Name the required output without relying on a product label.

Representative vendor pages show how far the category spreads.

Sermon Shots currently advertises transcription, static graphics, moving-image excerpts, templates, written resources, languages, and direct publishing on named plans. Pulpit AI currently advertises document, slide, audio, and recorded-message inputs with several written and visual outputs.

ChurchSocial describes a broader social-planning product with a sermon add-on, publishing, design, and team functions. Modulus describes a narrower source-and-writing job while leaving visual production elsewhere.

These are different workflows. None of those public pages proves output quality, source accuracy, suitability for your church, or parity with another product.

If your weekly need extends beyond editable static sermon-derived drafts, do not score a static-draft product against work it does not claim to perform. Exclude it. The same rule applies in the other direction. A broad output list should not receive credit for source fidelity, approval, or recovery until the route proves those duties.

Inspect fidelity and human review

Ask the vendor to show the evidence behind an exact candidate. Then make your own reviewer check the result.

The reviewer should be able to answer:

• Does every exact quotation match the authorized source?
• Does a paraphrase stay labelled as a paraphrase?
• Does the short version preserve the qualification that controls the point?
• Are Scripture references, names, dates, locations, and factual claims correct?
• Does the wording represent the church's teaching?
• Does the source include a pastoral story, prayer request, child, vulnerable person, health detail, or other sensitive material that should not be republished?
• Does the church have permission and consent for the planned use and destinations?
• Does the copy sound like this church without inventing a voice-matching result?
• Does the final design fit the church's visual rules?
• Do the exported pixels remain readable and complete?
• Does the alternative text describe the final image in its posting context?
• Who has authority to approve the exact version?
• What evidence identifies the source, corrections, approver, final asset, and later destination state?

Automated checks can catch missing fields, placeholders, structural defects, or some source mismatches. They do not make a pastoral, theological, legal, safeguarding, or publication decision.

Accessibility also belongs to the final version. The W3C Images Tutorial says informative images need a concise text alternative that conveys their essential information. WCAG contrast guidance also applies to words rendered into an image.

A draft alternative-text field and a structural readiness label do not prove that the crop, contrast, text size, or description works after export and destination processing.

Test editing, brand control, and export

Open a candidate and correct it. Do not settle for watching a polished demo.

Check whether a person can edit the exact words, images, shapes, backgrounds, crop, page order, layers, and layout properties needed for the result. Test design alternatives, undo and redo, asset replacement, multi-page handling, and whether a correction survives reopening or regeneration.

Ask how the product handles brand inputs. A logo upload is not automatic branding. A template is not proof that church colors, fonts, imagery, logo use, and writing choices are applied to every output. If people must apply those rules manually, put that work in the comparison.

Export the exact approved version. Check:

• all pages selected and in the intended order;
• supported file formats and dimensions;
• filenames that another person can identify;
• opened files, not only a success message;
• text fit, crop, color, transparency, and image quality;
• caption, link, alternative text, credit, and notice files;
• metadata or a manifest when the handoff needs one; and
• a record that ties the export to the approved version.

An editor with common static controls is not automatically a replacement for a general design product. An export button is not proof that every browser, page, and file path works in normal use.

Map the people and the handoffs

One person can carry several duties. The duties still need names.

Then inspect the product's account model. Ask about owners, seats, invitations, roles, concurrent editing, comments, approvals, transfer, and what happens when the only account holder leaves. A documented ownership transfer is not the same as shared seats. A comment is not approval. An approval control is not proof that the reviewer had ministry authority.

A one-owner product is a non-fit when several people need separate accounts, must edit concurrently, or must approve inside one shared workspace. Outside review can work, but the owner must preserve the exact version and bring the decision back into the handoff.

Demand destination and recovery evidence

If the purchase depends on publishing, require a current demonstration with the same account type and destination your church will use.

For Facebook, Instagram, and Threads, ask separately about:

• eligible account types and connection permissions;
• supported asset shapes and caption differences;
• alternative-text transport and destination editing;
• previews and what they do not reproduce;
• scheduling and immediate handoff;
• provider identifiers and native-result links;
• correct handling when some destinations succeed and others fail;
• ambiguous responses where the provider may have accepted the post;
• duplicate prevention before retry;
• credential repair, retry, rescheduling, and final verification;
• local archive or hide controls compared with remote deletion; and
• the record retained for later correction or removal.

Do not let a local scheduled, sent, or published label replace provider proof. The final publisher should inspect the native result for the correct account, asset, caption, links, crop, audience, and accessibility treatment.

An ambiguous provider response is not permission to send again blindly. Check the destination first. A retry that creates a duplicate is a new failure.

Deleting or hiding a local record also does not prove that a provider-held post changed. Ask which removals happen inside the product and which require the provider's own controls.

Read the commercial terms as a workflow

The headline monthly number is only one input. Record:

• market and currency;
• monthly or annual billing;
• taxes and invoice information;
• what the allowance counts;
• when work reserves capacity;
• what the visible usage meter omits;
• treatment of terminal failures and uncertain jobs;
• overages, credit packs, or extra-work purchases;
• trial terms and conversion;
• team plans and seat charges;
• live Checkout amount, interval, and currency;
• receipts and payment-failure handling;
• refund terms;
• cancellation controls and effective date;
• access, editing, export, retention, and deletion after cancellation;
• support route and response terms;
• service levels, eligibility geography, and regional restrictions; and
• what happens when normal demand exceeds the allowance.

Do not compare plans whose allowance units differ as if the numbers were equivalent. A file upload, recorded hour, generated kit, connected account, and owner seat are different units. The output and retained work can differ too.

The Church Media Kit offer needs live verification

As of 29 August 2026, the Church Media Kit offer reviewed for this guide says US$29.95 per month in USD for one owner account and seven successfully completed full Sermon Kits per Stripe billing period. The reviewed offer shows no trial, annual plan, extra-kit purchase, overage route, credit pack, or team plan.

The completed-kit meter does not show every reservation. A job can reserve one of seven slots while queued, running, waiting for attention, successful, or awaiting reconciliation after an uncertain result. A known terminal failure releases its reservation. Retrying the same request reuses the same job identity rather than creating two independent reservations.

That rule does not guarantee seven completed or usable kits. It also means the meter may show fewer successful kits than the number of slots currently held.

This is reviewed offer and product-behavior evidence, not live billing proof. We have not verified a live Stripe Checkout amount, charge, tax result, receipt, Customer Portal, refund, cancellation, post-cancellation access, or production entitlement cycle.

The current commercial direction and legal drafts also conflict on refunds and post-cancellation access. Tax treatment, Verse of the Day inclusion, service geography, support response, and service levels remain unresolved or insufficiently proven. A buyer should hold the decision until the current approved terms and live purchase flow agree.

Audit privacy and operations separately

Ask what happens to the source and generated material at every step:

• Which AI providers receive sermon words, prompts, settings, or generated content?
• Does the vendor use customer material for training, evaluation, product improvement, or marketing?
• Which settings, plan terms, and contracts govern that use?
• How long do source files, transcripts, prompts, drafts, exports, and provider records remain?
• How does account deletion differ from content deletion?
• What remains in backups, logs, billing records, support records, or legal holds?
• Which subprocessors receive data, and in which regions?
• What happens to copies already sent to a destination provider?
• Can the church export its data in a usable form before cancellation or deletion?
• Which incident, support, uptime, backup, restore, and recovery promises are contractual and currently operated?
• What current deployed evidence supports those promises?

A marketing privacy statement is not a security audit. A documented deletion path is not proof that a deletion job ran. A provider setting is not proof that all copies disappeared.

Church Media Kit's current Privacy draft says sermon context, transcript excerpts, prompts, and generation settings are sent to OpenAI through requests configured with store: false. The draft expressly says this is not a zero-retention promise and does not remove provider abuse-monitoring practices. It also says Hekima does not use customer material for training, evaluation, or product-improvement datasets without separate consent.

The same draft names subprocessors and describes retention, deletion, backup, cross-border processing, and provider-held posts. Those documents are not approved live policy, and the current operational record does not prove every stated deletion, purge, backup, incident, or recovery step. Buyers who need resolved privacy terms or deployed deletion proof should treat the current product as a non-fit until those gaps close.

What Church Media Kit can and cannot support in this check

In the product build inspected for this guide, Church Media Kit starts with a supported public YouTube sermon URL, the user's rights statement, and usable captions. The user selects bounded direction and content choices. The product can prepare source-linked editable static drafts, run structural readiness checks, provide manual controls for common static-design edits, and use the reviewed local static export paths.

Those facts do not establish rights verification, captionless transcription, other source types, automatic branding, broad format support, shared editing, in-product approvals, universal alternative-text delivery, a persisted deployed Sermon Kit, live Stripe, successful connected production publishing, privacy operations, reliability, service levels, or buyer outcomes.

Church Media Kit is a non-fit under current evidence when the church needs:

• a source other than the supported public YouTube path;
• a workflow without usable captions or a clear rights decision;
• broader media outputs than editable static sermon-derived drafts;
• automatic church-brand application;
• shared seats, concurrent editing, comments, or in-product approval;
• current live destination proof before purchase;
• one alternative-text method guaranteed across destinations;
• normal demand above the reviewed allowance with an overage path;
• a trial, annual billing, or team plan;
• resolved commercial or privacy terms that remain unresolved;
• service in a geography that has not been confirmed; or
• a workflow with no accountable human reviewer.

Some of those cases may change as the product and its approved terms change. They are still non-fit cases for the evidence available on the date of this guide.

Run one representative-source trial

Use one ordinary sermon your church may repurpose. Make sure it has usable captions and keep a stronger approved transcript or manuscript for checking.

Give every product the same:

• source and source words;
• brief for one required static result;
• dimensions and destination fields;
• church assets and wording rules;
• source and ministry reviewer;
• final publisher;
• intended destination and account; and
• completion definition.

Record the whole route:

1. List setup, access, plan, permissions, source preparation, templates, church assets, and training.
2. Keep every candidate and trace it to the source.
3. Record corrections to quotation, context, doctrine, facts, rights, consent, safeguarding, church voice, design, and accessibility.
4. Separate active work, waiting, and blocked time.
5. Open every export and destination preview.
6. Record handoffs, approval, provider responses, native checks, partial results, ambiguous results, duplicate checks, and recovery.
7. Preserve the source, candidates, exact approved asset, screenshots, errors, decisions, and final state.

One run may expose a broken source path, missing control, or unreliable handoff. It cannot prove what every church will experience.

Canada's Competition Bureau says performance claims need an adequate and proper test completed before the claim. Public manuals, similar products, anecdotes, and one operator's impression do not support broad claims about speed, quality, accuracy, savings, reliability, or outcomes.

Fictional evaluation: fit, hold, or non-fit

This evaluation is fictional. It is not a church, person, customer, testimonial, product test, or reported result.

The source is one rights-cleared public YouTube sermon with usable captions. The required preparation result is one editable static teaching post. One accountable owner can collect the source, ministry, design, accessibility, and publication decisions.

The source and output fit Church Media Kit's reviewed boundary. The human duties have owners. That prevents an immediate non-fit decision.

The evaluation still cannot reach fit. The buyer requires the current approved refund, cancellation, post-cancellation, privacy, and deletion terms to agree with the live purchase flow. The buyer also requires one persisted deployed Sermon Kit and current connected-destination proof. Those facts were not established in this check.

The decision is hold.

That result does not say the product failed a trial. No trial occurred. It says material buying evidence remains unresolved. If a required source or output fell outside the product boundary, or the team needed shared accounts inside the product, the result would be non-fit. If the required result, evidence, human ownership, commercial terms, privacy terms, and live workflow all passed the church's documented trial, the church could record fit for that defined use.

What we checked

We checked this guide on 29 August 2026 from Canada. Sources included current Google Search and Competition Bureau guidance, official YouTube and W3C pages, public vendor product, plan, terms, privacy, and help pages, current practitioner discussions, and Church Media Kit product, commercial, legal, privacy, and deployment records.

The Competition Bureau pages intermittently timed out during direct access. We used the current indexed regulator text and our dated source record, and the live pages still need another check before publication.

We did not create vendor accounts, accept free access, buy a plan, contact sales, inspect authenticated controls, run a vendor output, test support, or complete a side-by-side trial. We did not audit a vendor's security, privacy, retention, deletion, training, reliability, or service operations. Missing public detail proves only that we could not verify it on the pages checked.

Google's people-first guidance, generative search guide, and review guidance support clear sourcing, honest creation context, useful original decision work, and first-hand evidence for performance conclusions. They do not promise that this page will rank, appear in a generated answer, or receive a citation.

To report a factual error or changed vendor fact, use the correction route on our editorial standards page.

Frequently asked questions

What is the first question to ask a sermon-software vendor?

Ask the vendor to show how your required result reaches your definition of done. Name the source, output, reviewer, approval, destination, and retained evidence. A general feature tour cannot answer that question.

Is a generated sermon post ready to publish?

Generation creates a candidate. A person still needs to check source wording, context, doctrine, facts, rights, consent, safeguarding, church voice, design, accessibility, destination fields, and the exact version being approved.

Should we choose the product with the most output types?

No general conclusion follows from output count. First exclude products that cannot accept the required source or produce the required result. Then compare review, correction, handoff, commercial terms, privacy, provider proof, and recovery for the work that remains.

Does a rights confirmation prove we may repurpose the sermon?

No. It records the user's statement. The church still needs a defensible rights and consent decision for the recording and every included work or person. Seek qualified advice when the answer is uncertain.

Does a scheduling status prove the post is live?

No. A scheduled item is an instruction. A provider receipt is a later state. The final publisher should inspect the native result on the intended account and record partial, ambiguous, failed, or corrected outcomes.

How should a church compare allowances?

Compare the unit, reservation point, visible meter, failed and uncertain work, reset boundary, overage path, and required output. File uploads, recorded hours, completed kits, destination accounts, and seats are not interchangeable.

Is Church Media Kit a fit today?

The reviewed source and static-draft boundary may justify a controlled test for a church with a permitted, captioned public YouTube sermon and one accountable owner. The current commercial, legal, privacy, deployment, and connected-destination gaps require a hold when the buying decision depends on those facts.