Short answer
There may not be one owner for every part of your church app. Your church may own its content and member data without owning the platform code. It may control the app listing but not the security keys used to publish updates. It may own the domain but not the analytics account. A clear answer is a written map of every account, asset, license, export, and handoff rule. The checklist below helps you build that map before you sign or renew.
Ask a church app vendor, "Do we own our app?" and you may hear a quick yes. That answer is too broad. An app depends on many separate things, and each one can have a different owner or license.
This is not legal advice. It is a practical checklist for a pastor, operations lead, or finance team. Use it to make the contract conversation specific. If a term matters, put it in the signed agreement.
1. Apple Developer account
Check the legal organization name shown in Apple Developer and App Store Connect. Record the Account Holder, admins, recovery email, phone number, and payment method.
- Is the church the enrolled organization?
- Can two current staff members access the account?
- Who controls two-factor authentication and recovery?
- Who renews the membership each year?
- Would the app be eligible for transfer if the vendor relationship ends?
The store listing holds the app name, reviews, ratings, and the people who already installed it. Account control can matter more during a migration than access to a code repository.
2. Google Play developer account
Run the same check in Google Play Console. Confirm the legal owner, account admins, recovery methods, payments profile, and who receives policy notices.
Ask whether the vendor publishes in the church account or in a shared vendor account. If it is shared, ask what happens at service end and whether the app meets Google's current transfer requirements.
3. Member, donor, and content data
List every data type the app holds:
- Member profiles and contact details
- Group, volunteer, and attendance records
- Prayer requests and form responses
- Giving history and fund records
- Sermons, videos, audio, artwork, and captions
- Events, registrations, messages, and notification history
The agreement should say the church owns or retains rights to its submitted content and customer data. It should also say what the vendor may use to provide, secure, and improve the service. Ask how backups and deletion work. Also ask when the vendor must keep data for legal reasons and which other companies help handle it.
4. Payment processor and recurring gifts
The giving screen may carry the church logo while another company processes the payment. Identify the merchant account, processor, bank connection, payout owner, tax records, and support contact.
- Whose legal name is on the merchant account?
- Where do payouts land?
- Who can issue refunds?
- Can donor history export?
- Can recurring payment credentials move, or must donors act?
- Which party handles disputes and tax receipts?
Never assume saved card or bank details can move through a normal export. Ask both the current and future processor for a written transition path.
5. Domain, email, SMS, and media accounts
Your domain and communication channels should not depend on one former employee or agency login. Check the domain registrar, domain settings (DNS), email sender, SMS provider, livestream host, podcast host, video channels, and link-shortening tools.
For each one, record the owner, admins, recovery details, renewal date, billing card, and the person responsible. Use role-based church email addresses where the provider allows them.
6. Analytics and crash reporting
Analytics are part of the app history. Confirm the church can see usage, event, crash, and campaign data without asking the vendor for screenshots.
- Which analytics and crash tools are installed?
- Does the church have direct account access?
- Can historical reports export?
- Will the same analytics account continue after a vendor change?
- Who controls consent settings and data retention?
A migration is easier when the new release can be compared with the old one using the same basic measures.
7. Source code, platform code, and licenses
These terms are often mixed together. Separate them:
- Customer-specific code: work written only for your church.
- Platform code: the vendor's shared system, templates, libraries, and operations tools.
- Open-source code: components licensed under their own terms.
- Third-party services: connections to outside tools, fonts, media, and software with separate subscriptions or licenses.
A managed service can let the church control its data and accounts while licensing the software during service. A custom agency may assign customer-specific code but keep its reusable framework. Neither model is automatically wrong. The risk is an unclear promise.
Ask what the church receives at the end. The answer may include editable source code, an installable app file, documentation, data exports, account transfer help, or a limited license. It may include none of these. Put the exact answer in the agreement.
8. Exports and service-end terms
Do not wait until cancellation to learn what can leave. The contract should answer:
- Which export formats are available?
- Are linked records, files, and change history included?
- How often can the church request an export?
- How long is access available after notice?
- Is transition help included, hourly, or unavailable?
- When are backups and production data deleted?
- What happens to domains, certificates, store listings, and app signing keys?
Test an export during the contract, not just at the end. Open it, count the records, and confirm that important fields are understandable.
9. Roles and day-to-day responsibility
Ownership does not tell you who keeps the app working. Write down who handles store policy changes, phone software updates, security certificates, security fixes, content changes, support tickets, backups, and the response to a security problem.
A do-it-yourself platform may give your team broad control but also broad responsibility. A done-for-you service may carry more operational work while defining the church's account and data rights in the agreement. Compare the work, not only the label.
A one-page ownership table
| Item | Who owns or controls it? | What happens at service end? |
|---|---|---|
| Apple listing | Name the organization and Account Holder | Keep, transfer, or replace |
| Google Play listing | Name the organization and admins | Keep, transfer, or replace |
| Customer data | State the church's rights | Format, timing, and deletion |
| Payments | Name the merchant and processor | History, recurring gifts, and payouts |
| Domain and analytics | Name the account owner | Credentials and history remain available |
| Code and licenses | List assigned code and licensed systems | Archive, license, handoff, or no transfer |
Questions to ask before signing
- Which accounts will be created in the church's legal name?
- Which data and content rights stay with the church?
- Which parts of the software are assigned, licensed, or vendor-owned?
- What export can we request today?
- What changes on the final service day?
- Who pays for and manages each third-party account?
- What migration help is included?
- Which statements will appear in the signed agreement?
FAQ
Does a church own an app published under its name?
Not necessarily. The display name does not prove ownership of the store account, code, platform, or data. Check the legal account holder and contract for each part.
Should our church own the source code?
It depends on the model and your ability to maintain it. Source code can be valuable when the church has a capable engineering team or a funded handoff plan. For many churches, control of data, store accounts, domain, exports, and service continuity matters more. Ask what a code handoff would include and who could run it.
Can a vendor own the platform while we own our data?
Yes. That is common in software services. The vendor licenses its platform while the customer keeps rights to submitted content and customer data. The agreement should define permitted use, security, exports, deletion, and the end of service.
What is the most important account to control?
There is no single answer, but the Apple and Google store listings, domain, payment processor, and recovery email addresses are high priority. Losing any one can interrupt the member experience or a migration.
When should we review app ownership?
Before signing, at each renewal, after staff changes, and before a migration. Run the account checklist at least once a year.
The bottom line
Church app ownership is a map, not a slogan. Name the owner and admins for every account. Define rights to data, content, code, and licenses. Test exports. Write the handoff and deletion rules. Then assign the weekly work.
If you are leaving Subsplash, follow the 30-day Subsplash migration plan. If you want a custom church app that Rehost operates for you, see Rehost Faith and how the service works in our method. You can also book a church app ownership walkthrough. Bring your agreement and account list. We will help you turn vague promises into a one-page ownership map. This walkthrough is not legal advice.