FaithMap
A church discovery product built for real-world ownership, trust and operations.
FaithMap is a production iPhone application for discovering churches, exploring church information and connecting with local Christian communities.
The visible product is only one part of the work.
Behind it is a connected system for accounts, church ownership, permissions, backend services, operational tooling and production release.
The problem
A church directory creates an unusual ownership problem.
Church information needs to be publicly discoverable, but being listed cannot automatically give someone the right to change it.
At the same time, legitimate church leaders need a practical way to take control of their listing and manage information inside the product.
That meant FaithMap needed to answer two different questions:
Who can see this church?
Who is allowed to manage it?
Those are not the same thing.
Public discovery. Controlled ownership.
FaithMap separates public church discovery from management authority.
A church can appear publicly without giving anyone administrative control over it.
A signed-in user can submit a claim for a church. That claim enters an approval workflow with pending, approved and rejected states.
Only an approved claim unlocks church-management capabilities.
The restriction is not just handled by hiding buttons in the iPhone interface. Protected operations are also enforced through database authorization policies on the backend.
That means access rules continue to apply even if someone attempts to bypass the visible interface.
The ownership flow
Discover
A church can be found and viewed publicly.
Claim
A signed-in church representative can submit an ownership claim.
Review
The claim can be approved or rejected through the administrative workflow.
Manage
An approved claimant gains access to authorized church-management capabilities.
Rejected claims also follow a controlled resubmission process with a database-enforced seven-day cooldown.
Proven in production
This architecture is operating in the live product, not sitting unused in a prototype.
As of September 3, 2026, FaithMap had approved claims for 10 distinct churches in the production database.
The production records contained 11 approved claims across those 10 churches, demonstrating that the ownership model can also support more than one approved claimant for a church.
- Distinct churches
- 10
- Approved claims
- 11
The important result is not the count itself. It is that a permission model designed around public discovery, verified ownership and controlled management has been completed by real churches in production.
From interface to backend
The ownership system required several parts of the product to agree with one another.
The iPhone application handles claim submission, status and management access.
The administrative side supports approval and rejection.
The backend maintains the authoritative claim state.
Database authorization policies protect church profiles, announcements, messages, prayer-request workflows and other claimant-controlled operations.
iPhone application
Claim submission, status and management access
Administrative review
Approval and rejection
Backend authority
Maintains the authoritative claim state
Protected operations
Guarded by database authorization policies
Who the user is.
What that user is allowed to control.
That distinction became one of the most important architectural decisions in FaithMap.
Taking the iPhone app through release
FaithMap was taken through production testing, App Store submission, review and public release.
During review, Apple placed the submission under Guideline 2.1 — Information Needed and requested additional review materials, including a physical-device demonstration and information about the application's behavior and purpose.
Those requirements were addressed, the submission reached approved status and FaithMap subsequently became publicly available on the App Store.
App Review can stop a release for information and review materials, not only for problems in the code.
Software behind the operation
Church outreach created repetitive work across candidate processing, personalization, sending, record keeping and follow-up.
An internal outreach system was built to handle the repeatable parts while retaining operational controls.
It handles structured candidate data, duplicate and suppression controls, personalization, dry-run and live sending, logging, lifecycle status, scheduling and daily sending limits.
Automate the repetitive work without removing the controls that keep the operation safe.
In one documented production run on August 27, 2026, the system processed 100 sending cycles and stopped automatically when its configured daily target of 100 sends was reached.
What FaithMap demonstrates
FaithMap is proof of more than an interface.
It required product decisions, iPhone development, backend integration, authentication, authorization, operational systems, production infrastructure and App Store release to work together.
The strongest lesson from the project is also one of the simplest:
The visible experience is only trustworthy when the systems underneath it enforce the same rules.
For FaithMap, that meant making churches easy to discover without making them easy to take over.
Built as an Osuna Works product.
FaithMap began as an internal product idea and became a production iPhone application with backend infrastructure, operational systems and an ownership workflow completed by real churches in production.