visit.waterschurch.org/Visit Page Prompt.md

You are a senior product designer, conversion-rate optimization strategist, and full-stack engineer. Build a production-ready advertising landing page for Waters Church that helps first-time visitors feel comfortable, understand what to expect, and take the next step toward attending a service.

## Primary objective

Create a modern, edgy, simple, mobile-first landing page that converts traffic from Facebook, Instagram, X, Google, and TikTok ads into prospective first-time visitors.

The page should:

1. Identify the Waters Church campus closest to the visitor.
2. Give newcomers clear, reassuring information about their first visit.
3. Capture contact information and visit intent.
4. Add consenting visitors to a Mailchimp email journey.
5. Send consenting visitors a confirmation text through Sinch Engage.
6. Let visitors text the church with questions.
7. Preserve advertising attribution for campaign reporting.

Do not create a generic church website. Create a focused, high-converting “Plan Your Visit” landing page with one primary conversion goal.

Add this section to the Claude Code prompt, immediately after “Primary objective”:

## Confirmed project information

Use these details throughout the implementation:

- Production URL: `https://visit.waterschurch.org`
- Main Waters Church website: `https://waterschurch.org`
- Hosting environment: cPanel
- Official information, campus details, service times, brand references, logos, and approved photography can be sourced from `https://waterschurch.org`.

Treat the main Waters Church website as the primary source of truth for church information. Review it before designing or writing the landing page. Reuse accurate public information where appropriate, but do not copy large sections of text verbatim. Adapt the information into concise, newcomer-focused landing-page copy.

Download only the Waters Church logos and images needed for this project. Store optimized local copies in the project rather than hotlinking production assets. Preserve image quality, aspect ratio, and transparent backgrounds. Convert oversized photographs to modern web formats such as WebP or AVIF, while retaining fallbacks if needed. Do not alter the logo or invent new brand marks.

Verify campus addresses, coordinates, service times, contact details, kids information, and other factual claims against `waterschurch.org`. Make uncertain or missing information configurable and flag it for Waters Church to confirm before launch.

## cPanel hosting requirements

The finished project must be deployable through the church’s cPanel hosting environment.

Before selecting the final architecture:

1. Inspect the existing repository.
2. Determine which runtimes the target cPanel account supports, including its Node.js version, application manager, PHP version, database options, scheduled tasks, SSL, environment-variable management, and reverse-proxy configuration.
3. Do not assume that a continuously running Next.js server is supported.
4. Choose the simplest secure architecture compatible with the available cPanel features.

Preferred deployment options, in order:

1. Use the existing application stack if it is already compatible with cPanel.
2. Use a Node.js application through cPanel’s supported Node application manager if the account supports the required runtime and persistent server processes.
3. If Node hosting is unavailable, produce an optimized static frontend with secure PHP server endpoints for form processing, lead persistence, Mailchimp, and Sinch Engage.
4. Do not move secrets or third-party API calls into browser code to work around hosting limitations.

The deployed page must resolve at:

`https://visit.waterschurch.org`

Configure:

- The canonical URL to use `https://visit.waterschurch.org`.
- Production metadata and social-sharing URLs for that domain.
- HTTPS redirects.
- Non-`www` URL consistency unless Waters Church specifies otherwise.
- cPanel-compatible routing and rewrite rules.
- Secure environment or configuration storage outside the public web root whenever possible.
- Production error logging without exposing personal information or API credentials.
- Appropriate file permissions.
- A custom 404 response.
- Cache headers and compression.
- A deployment process that does not require manually editing generated build files.

If Apache configuration is required, provide the appropriate `.htaccess` file. If cPanel’s Node.js application manager is used, document the startup file, application root, environment variables, build command, startup command, and restart procedure.

Do not rely on serverless-platform-specific features such as Vercel functions, edge middleware, or proprietary geolocation headers unless an equivalent cPanel-compatible implementation is provided.

For approximate location detection, prefer a privacy-conscious server-side IP geolocation service that can operate from cPanel. Keep precise browser geolocation optional and initiated only by the visitor.

## Updated deployment deliverables

In addition to the other deliverables, provide:

- A production build compatible with the target cPanel account.
- Any required `.htaccess`, Node startup, PHP endpoint, or database setup files.
- A cPanel deployment guide written for a site administrator.
- Instructions for creating and pointing the `visit.waterschurch.org` subdomain.
- Instructions for enabling and verifying SSL.
- Instructions for adding production environment variables securely.
- Instructions for configuring scheduled retries or background processing using cPanel cron jobs, if needed.
- Instructions for updating campus details, logos, photographs, service times, and contact numbers.
- A post-deployment checklist covering forms, Mailchimp, Sinch Engage, location detection, analytics, consent records, redirects, SSL, and mobile performance.

Do not publish or change DNS until explicitly authorized. Prepare the project and deployment documentation so Waters Church can launch it safely through cPanel.

## First steps

Before writing code:

1. Inspect the existing repository, application structure, coding conventions, and design system.
2. Reuse the existing framework and components when practical.
3. Look for existing Waters Church branding, campus data, logos, photography, analytics, environment-variable conventions, and API integrations.
4. If this is a greenfield project, use:
   - Next.js with the App Router
   - TypeScript
   - Tailwind CSS
   - Server-side route handlers for integrations
   - Zod or equivalent server-side validation
5. Create a brief implementation plan, then build the complete experience.
6. Do not stop at a mockup. Implement the functional page, form flow, campus selection, API integration layer, validation, tracking hooks, loading states, errors, and documentation.

Do not invent factual information about Waters Church. Put unknown campus details, service times, addresses, phone numbers, and API values into clearly documented configuration or structured placeholder data.

## Audience and message

The audience consists mainly of people who:

- Have never attended Waters Church.
- May not regularly attend any church.
- Are curious but uncertain about what the experience will be like.
- May worry about dress, parking, children, service length, beliefs, or being pressured.
- Are arriving from an advertisement and need an immediate connection between the ad and the page.

The experience should feel welcoming, confident, energetic, contemporary, and human. Avoid insider church language, clichés, guilt, pressure, and institutional wording.

Core message:

“Your first visit doesn’t have to feel uncertain. We’ll help you know what to expect and make it easy to find the Waters Church location nearest you.”

## Visual direction

Create an original visual system that feels modern, bold, edgy, and uncluttered.

Use:

- Large, heavy display typography.
- Short, direct headlines.
- Strong contrast.
- Generous spacing.
- A restrained color palette aligned with existing Waters Church branding.
- Bold photography or video areas, when appropriate.
- Subtle motion and interaction feedback.
- Clear, repeated calls to action.
- Mobile layouts designed for one-handed use.
- Accessible focus states and large tap targets.

Avoid:

- A generic church-template appearance.
- Excessive gradients.
- Overly rounded “startup SaaS” styling.
- Busy navigation.
- Long walls of text.
- Stock religious imagery unless it genuinely fits the brand.
- Carousels, autoplay audio, or distracting animation.

If brand assets are unavailable, use tasteful placeholders and organize them so they can be replaced without changing the layout.

## Page structure

### 1. Minimal header

Include the Waters Church logo and only essential actions:

- “Find Your Campus”
- “Text Us”

Keep users focused on planning a visit. Do not add a full website navigation menu unless one already exists and is necessary.

### 2. Hero section

Create a high-impact hero with:

- A direct headline such as “Church Can Feel Different Here.”
- Supporting copy that addresses first-visit uncertainty.
- Primary CTA: “Plan My Visit”
- Secondary CTA: “Find My Campus”
- A visible “Questions? Text Us” action
- Relevant Waters Church imagery or a well-designed media placeholder
- A compact trust cue such as “No pressure. Just a friendly welcome.”

The primary CTA should scroll to or open the visit form without sending the user to another page.

### 3. Closest-campus experience

Offer the closest relevant Waters Church campus using location-aware logic.

Use this sequence:

1. On initial load, make a non-invasive approximate recommendation using server or edge location data if the hosting platform provides it.
2. Clearly label the result as a recommendation.
3. Offer “Use my precise location” as an optional action that triggers the browser permission request only after the user chooses it.
4. Always provide a manual ZIP/postal-code search and campus selector.
5. Never block the experience when location access is denied or unavailable.
6. Save the selected campus through the conversion flow.
7. Explain location use in plain language and do not retain precise coordinates unless truly necessary.

Calculate the closest campus from latitude and longitude when coordinates are available. Put all campus records in a typed configuration containing:

- Campus name
- Address
- Latitude and longitude
- Service times
- Campus-specific phone/SMS number
- Directions URL
- Campus page URL
- Parking or arrival notes
- Kids information
- Optional campus image

The selected-campus card should include:

- Campus name
- Distance when it can be calculated
- Address
- Upcoming service times
- Directions action
- “Choose This Campus”
- “Text This Campus”
- An easy way to select a different location

Do not silently claim a campus is closest if the location result is uncertain.

### 4. “What to Expect” section

Answer the most common newcomer questions in short, scannable content:

- What should I wear?
- How long is a service?
- What is the music and teaching like?
- Where should I park?
- What happens when I arrive?
- Is there something for children?
- Will I be singled out or pressured?
- Is the venue accessible?

Use cards, expandable items, or a clean editorial layout. Keep the answers editable through configuration or content components.

### 5. Kids and family reassurance

Give families a concise explanation of:

- Kids check-in
- Safety and security
- Age groups
- When to arrive
- What parents should bring
- Accessibility or special-needs support, if confirmed

Do not invent policies. Mark missing information as content placeholders.

### 6. Social proof

Add a restrained social-proof section using real testimonials only if they exist in the repository or supplied content. Do not fabricate quotations, attendance numbers, ratings, or claims.

If real content is unavailable, create an obvious content placeholder that can be removed cleanly before launch.

### 7. Plan Your Visit form

Build a short, conversion-oriented multi-step or progressive form. Ask only for information that has a clear purpose.

Recommended fields:

- First name — required
- Last name — optional
- Email — required
- Mobile phone — required only if the visitor elects to receive texts
- Selected campus — required
- Expected visit date or service — optional
- Number of adults — optional
- Number and age ranges of children — optional
- “What questions can we answer?” — optional
- Email marketing consent
- SMS consent with a separate, unchecked checkbox

Do not bundle SMS and email consent. Consent boxes must not be preselected.

Place concise privacy and consent language beside the relevant controls. The SMS disclosure should explain that the visitor agrees to receive messages from Waters Church, that message and data rates may apply, that frequency may vary, and how to opt out. Link to Privacy Policy and Terms pages or configurable URLs.

Use accessible labels, inline validation, server-side validation, bot protection, rate limiting, and a honeypot or equivalent anti-spam control.

The main button should use intent-based language such as:

- “Plan My Visit”
- “Help Me Get Ready”
- “Send My Visit Details”

Avoid “Submit.”

### 8. Confirmation experience

After a successful submission:

- Show a warm confirmation message.
- Confirm the selected campus and visit details.
- Display directions and service times.
- Explain that an email is on the way.
- If SMS consent was provided, explain that a text is on the way.
- Provide a prominent “Text Us a Question” action.
- Preserve the page design instead of displaying a generic success alert.
- Fire a conversion event only after the server confirms success.

If one integration succeeds and another fails, do not lose the lead. Store or log a recoverable integration state, show the user a sensible confirmation, and record the failure for retry or follow-up without exposing technical details.

## “Text Us” functionality

Provide a persistent but unobtrusive “Text Us” action throughout the experience.

On supported devices, use an `sms:` link associated with the selected campus. If no campus has been selected, use a configurable central Waters Church SMS number or ask the visitor to choose a campus.

Pre-fill a natural message such as:

“Hi! I’m thinking about visiting Waters Church and have a question.”

Make sure the visitor can edit the message before sending it.

The automated confirmation text sent after form submission should be concise and conversational. Example structure:

“Hi {{first_name}} — we’re excited that you’re considering Waters Church {{campus_name}}. Your visit details: {{service_or_date}}. Have a question? Reply to this message. Reply STOP to opt out.”

Treat this only as editable copy. Ensure the final implementation follows the actual Sinch Engage capabilities, local regulations, and approved Waters Church messaging policies.

## Sinch Engage integration

Implement the SMS integration behind a server-only adapter.

Requirements:

- Never expose credentials in client-side code.
- Use environment variables.
- Validate and normalize phone numbers, preferably to E.164 format.
- Send an automated message only when explicit SMS consent was provided.
- Store consent timestamp, disclosure version, source, selected campus, and attribution data.
- Include appropriate opt-out handling in the message and downstream workflow.
- Use idempotency protection so retries do not send duplicate texts.
- Handle API errors and timeouts safely.
- Redact personal information and secrets from logs.
- Add a mock/development mode so the flow can be tested without sending a real text.
- Document which Sinch Engage endpoint, sender identity, template, and credentials must be configured.

Sinch products and account configurations can differ. Use the official documentation matching the project’s actual Sinch Engage account. Isolate provider-specific code so it can be adjusted without changing the form or page.

Create an adapter interface similar to:

- `sendVisitConfirmation()`
- `sendInternalLeadNotification()`, only if supported and desired
- `normalizePhoneNumber()`

Do not pretend that SMS delivery succeeded if the provider did not confirm acceptance.

## Mailchimp integration

Implement the Mailchimp connection behind a server-only adapter.

On valid form submission:

- Create or update the contact in the correct audience.
- Avoid creating duplicate contacts.
- Apply tags for:
  - First-time visitor
  - Selected campus
  - Landing-page source
  - Advertising platform
  - Campaign
  - Visit date or service, when supplied
- Map useful merge fields.
- Trigger or qualify the contact for the appropriate welcome/first-visit customer journey.
- Respect the email consent state and the audience’s opt-in model.
- Preserve the lead safely if Mailchimp is temporarily unavailable.
- Add idempotency protection.
- Provide a mock/development mode.
- Never expose the Mailchimp API key in the browser.

Document the required Mailchimp environment variables, audience ID, server prefix, tags, merge fields, and automation prerequisites.

## Lead storage and reliability

Do not make Mailchimp or Sinch the only record of the form submission.

If the existing application has a database, save the lead and integration status there before calling external services. If it does not, implement a clean persistence interface and a development adapter, then clearly document the production storage option that must be connected.

Track:

- Submission ID
- Timestamp
- First and last name
- Email and phone
- Consent choices and consent-language version
- Selected campus
- Visit details
- Questions
- UTM and click identifiers
- Landing-page variant
- Referrer
- Mailchimp status
- Sinch status
- Retry state

Protect personal data, minimize what is retained, and define a deletion or retention approach in the documentation.

## Advertising attribution and analytics

Capture and preserve the full attribution context across the form experience, including when the user changes campus or moves between steps.

Support:

- `utm_source`
- `utm_medium`
- `utm_campaign`
- `utm_content`
- `utm_term`
- `gclid`
- `gbraid`
- `wbraid`
- `fbclid`
- TikTok click ID when present
- X/Twitter click identifiers when present
- Landing-page variant
- Initial referrer
- First landing URL

Create a consent-aware analytics layer with clearly named events such as:

- `landing_page_view`
- `campus_recommended`
- `location_permission_requested`
- `campus_selected`
- `plan_visit_started`
- `plan_visit_step_completed`
- `plan_visit_submitted`
- `plan_visit_success`
- `text_us_clicked`
- `directions_clicked`

Include event properties such as campus, source, campaign, device category, and landing-page variant, but do not send unnecessary personal information to ad platforms or analytics tools.

Provide integration hooks for the organization’s chosen analytics and advertising tools. Do not hardcode production tracking IDs.

## SEO and landing-page marketing

Although this is an advertising destination, make it technically strong for search and sharing.

Implement:

- A focused title and meta description.
- Canonical URL support.
- Open Graph and social-sharing metadata.
- Appropriate robots behavior controlled by environment.
- Organization/Church and location schema using verified information only.
- LocalBusiness or Place schema for campuses when appropriate.
- Semantic heading structure.
- Descriptive link labels and image alt text.
- Fast loading and minimal client-side JavaScript.
- Optimized responsive images.
- Sitemap integration if the project uses a sitemap.
- Clean, readable URL structure.
- Campus-specific copy and metadata where the architecture supports it.

Do not keyword-stuff. Write for newcomers first. Keep the primary CTA visible and ensure message continuity between ad copy and landing-page content.

## Performance and accessibility

Target excellent mobile performance and Core Web Vitals.

Requirements:

- Mobile-first responsive design.
- WCAG 2.2 AA-oriented implementation.
- Full keyboard navigation.
- Visible focus styles.
- Proper form labels and error associations.
- Sufficient color contrast.
- Reduced-motion support.
- No layout shifts from images or fonts.
- Optimized font loading.
- Lazy-load content that is below the fold.
- Avoid unnecessary third-party scripts.
- Test at common mobile widths and slow-network conditions.

## Security and privacy

Implement:

- Server-side validation and sanitization.
- Rate limiting.
- Bot protection that does not create needless friction.
- Same-origin and CSRF protections where appropriate.
- Secret management through environment variables.
- Safe error messages.
- Redacted logs.
- Request timeouts.
- Idempotent form processing.
- A configurable consent-disclosure version.
- Privacy Policy and Terms links.
- No automatic precise-location request on page load.
- No email enrollment or SMS delivery without the applicable consent.

Do not make legal-compliance claims. Flag all consent language, data retention, TCPA-related SMS behavior, and privacy disclosures for review by Waters Church’s legal or compliance adviser before launch.

## Content and configuration architecture

Keep frequently changing information outside presentation components.

Create typed configuration for:

- Church name and central contact details
- Campuses
- Addresses and coordinates
- Service times
- SMS numbers
- Directions
- Kids information
- FAQs
- Testimonials
- Privacy and Terms URLs
- Consent copy and version
- Analytics IDs
- Mailchimp mapping
- Sinch sender and templates

If a CMS already exists, use it appropriately. Otherwise, make the configuration simple for a non-developer to update.

## Testing

Add meaningful tests for:

- Campus distance calculation
- Postal-code/manual-location fallback
- Form validation
- Consent enforcement
- Attribution capture
- Mailchimp field and tag mapping
- Sinch message construction
- Idempotency behavior
- Partial integration failure
- Successful submission
- Accessible keyboard operation for the main flow

Also manually verify:

- Small and large mobile screens
- Desktop layout
- Denied location permission
- Unsupported geolocation
- No nearby campus result
- Missing or malformed campaign parameters
- API timeout and provider failure
- Duplicate form submission
- Screen-reader-friendly errors
- Text links on iOS and Android where possible

## Environment variables

Add a documented `.env.example` containing placeholders only. Include the variables required for:

- Public site URL
- Database or lead-storage connection
- Mailchimp API key
- Mailchimp server prefix
- Mailchimp audience ID
- Mailchimp journey/tag configuration
- Sinch Engage API base URL
- Sinch project/service identifiers
- Sinch API credentials
- Sinch sender identity
- Central SMS number
- Geocoding provider, if one is required
- Analytics and advertising IDs
- Bot-protection service
- Preview/mock mode

Never place real secrets in the repository.

## Deliverables

Complete the work with:

1. The functional landing page.
2. Responsive styling and interactions.
3. Campus recommendation and manual selection.
4. The visit-planning form and confirmation state.
5. Mailchimp and Sinch server-side adapter layers.
6. Attribution and analytics hooks.
7. Validation, consent, reliability, and anti-spam protections.
8. Tests.
9. `.env.example`.
10. A concise setup guide explaining:
    - How to enter campus details
    - How to connect Mailchimp
    - How to connect Sinch Engage
    - How to configure tracking
    - How to run locally
    - How to test without sending messages
    - How to deploy
    - Which content and compliance items require human approval

## Definition of done

The project is finished when:

- A visitor arriving from an ad immediately understands the purpose of the page.
- The page suggests a campus without forcing location permission.
- The visitor can always choose a campus manually.
- The visitor can confidently understand what a first visit will be like.
- The form works on mobile and has clear, separate consent choices.
- Successful submissions are persisted before external integrations run.
- Consenting contacts are correctly prepared for Mailchimp.
- Consenting phone numbers receive one idempotent Sinch confirmation request.
- Visitors can initiate a text conversation with the appropriate church number.
- Campaign attribution reaches the stored lead and integration mapping.
- Failure states are graceful and recoverable.
- The experience is accessible, fast, secure, and visually polished.
- No factual church information, testimonials, legal language, or API success has been fabricated.
- The setup documentation allows another developer to configure and deploy the site.