Phase 8 · Configure the app

▶Start here

You are here: Playbook → Phase 8 · Configure the app This phase is for you if: staging runs but the product is still empty — brand, mail, payments, plans need wiring. Not this phase? Phase 7 = hardening · Phase 9 = growth surfaces.

Turn a deployed-but-empty install into a launch-ready product. This phase covers everything that lives outside the day-one code import: brand identity, transactional mail, payment gateways, third-party integrations, and the plan/feature flags that gate what customers can do — then seeding and verifying each flow before real users arrive.

Phase 8 — configure the live product, then prove it works

Branding and core settings come first (they feed mail templates and checkout). Seed + verify is the gate: nothing ships until every flow is proven in staging.

Gate

The app is configured and proven. A real test payment succeeds end-to-end, a transactional email lands in the inbox with spf/dkim/dmarc=pass, plans render at /pricing with correct prices, and every reproducible setting is captured in your project context — not just in someone’s memory.

The one rule for this phase

Most CodeCanyon SaaS templates ship with an admin panel that overrides .env. Before configuring anything in code, check the admin UI and the database — settings stored there win at runtime, and editing the wrong layer silently does nothing.

Check the admin panel first

For mail, payments, plans, and email templates, look for a built-in manager (Settings → Payment, Settings → SMTP, Settings → Plans, Settings → Email Templates). If it exists, configure there — it is faster and authoritative. Only fall back to code/seeders when no admin surface exists.

Prerequisites

• Earlier phases complete — code in git, app running locally and on staging, security hardened, legal pages live.
• A registered domain with DNS access (needed for mail authentication and payment webhooks).
• SSH access to the server (for performance and cache verification).
• Accounts created at any payment/email providers you intend to use.

Optional tasks are SHOULD, not skip

Several items in this phase are SHOULD or OPTIONAL. Never silently skip them — surface each one and let the operator decide. If running a batch, the first choice (“do all” / “skip all optional”) carries forward, and skipped items are listed at the end.

Step	Priority	Notes
MUST path (mail, payment, plans, seed+verify)	MUST	The launch-blocking critical path
Brand kit	SHOULD	Do before mail templates and marketing assets
Payment gateway	SHOULD	Pick at least one; Stripe + PayPal is the common pair
Transactional mail	MUST	Delivery must work before launch
Performance pass	SHOULD	.htaccess, PHP/OpCache, CDN caching
Alerts / analytics / PM	OPTIONAL	Slack alerts, privacy analytics, issue templates
Social identity / changelog	LATER	Post-launch

Pages in this phase

1 · MUST path The launch-blocking spine: brand & settings, mail, payment gateway, webhook verification, plans & flags, seed + verify every flow.

2 · Brand kit Name, logo set, WCAG-checked palette, bilingual typography, committed reference files, design tools, marketing assets.

3 · Payments & billing Gateway decision matrix (Stripe built-in vs from-scratch, PayPal, Tap for MENA, LemonSqueezy MoR), plans, webhooks, tax, dunning, lifecycle.

4 · Email Confirm + test delivery, provider deliverability matrix, the six core templates, optional drip campaigns and newsletter.

5 · Performance Lighthouse baseline, .htaccess caching + gzip, PHP/OpCache, Redis, Cloudflare, quick wins — realistic targets.

6 · Integrations Slack notifications, GitHub project management (labels/forms/board/PR template), Rybbit privacy analytics.

7 · Post-launch Claim social handles early; wire the dual (internal + public) changelog so every release ships an announcement.

Start with the MUST path.