Skip to content
prod e051e98
Browse

Full roadmap & checklist

You are here: PlaybookRoadmap & checklist This page is for you if: you want the whole setup-new workflow in one scroll — phases, steps, gate items, and links — without hopping through the sidebar. Power-user mode. Not this? Overview = narrative intro · sidebar = one phase at a time.

One page, one workflow: 12 phases as toggles, numbered steps with a short summary and a link to the full page, and gate items (from each step’s checklist) as substeps you can tick off. Progress saves on this device.

12 phases · 88 steps · 432 gates 0 / 520 done

01 AI System
  1. Stand up the agent operating system for a CodeCanyon Laravel app — the constitution, permission modes, rules, skills, and IDE wiring that every later phase relies on.

  2. Start here — create the project folder, stage the CodeCanyon download in _source/, bootstrap an anchored .gitignore + git init, promote the Laravel app to the root, prove nothing was missed with a filesystem completeness gate, commit the pristine vendor baseline on author/v* + tag, then write .vscode/ for the AI layer (committed at C2 · machine setup).

  3. Authenticate the GitHub CLI, register MCP servers, and install the permission-mode switcher and deploy orchestrator — once per machine (your user account), reused by every project.

  4. Write the cross-tool contract (AGENTS.md), the thin CLAUDE.md pointer, and the gitignored CLAUDE.local.md — the persistent project knowledge every agent loads at session start.

  5. Write the project-wide settings.json, pick a permission mode (strict/medium/yolo), set personal model/thinking/compact defaults in settings.local.json, and wire the hard-block + vendor-edit guard hooks that no mode can override.

  6. Seed .claude/rules/ with the universal behavioral + reference rule set, install the stack skills and deploy orchestrator into .claude/skills/, then restart so the new context loads.

  7. Wire the project MCP servers (.mcp.json with Laravel Boost) and make Cursor, Gemini, and Codex read the same constitution via a boot rule and thin mirrors.

  8. Run the AI System verification checklist, confirm the gate condition, and hand off to Code & repository setup with the AI System fully wired.

02 Code Repo
  1. Verify the local toolchain, then create the private GitHub repo, hosting sites, and databases — and wire passwordless SSH to both servers — before anything depends on them.

  2. Choose Option A (solo/small team — one setup branch, one commit per phase) or Option B (a branch per phase, merged via PR), then learn the branch model the rest of the playbook commits against.

  3. Extract the CodeCanyon vendor ZIP cleanly, initialize git with a frozen vendor snapshot and branch strategy, and wire .env templates — so every later vendor update diffs cleanly.

  4. Extract the CodeCanyon ZIP into a verified Laravel root, capture vendor docs, back up a pristine copy, and identify any author patches inside vendor/ — before a single file is touched.

  5. Set session variables, write .gitignore BEFORE git init so secrets and installed dependencies never enter history, then initialize git on develop and lock down per-directory storage ignores.

  6. Back up the vendor's env into the project vault, lay down local/staging/production templates, activate local and generate the app key, then verify the per-environment values that differ.

  7. Verify the pristine vendor baseline from AI System setup, push develop + author/vX + tag to the private remote, cut your working branch, and prove the seam is clean — without recreating the vendor import.

  8. Project-structure scaffolding (Admin-Local vault + docs), commit & documentation standards with the Zaj customization strategy, and version management (SemVer + CHANGELOG) — SHOULD, not skip-by-default.

03 Local Dev
  1. Authenticate Composer to dodge the rate limit, install PHP and JS dependencies without clobbering vendor patches, audit .env.example for fail-loud placeholders, then build and commit frontend assets.

  2. Start the local MySQL/MariaDB service, create an empty utf8mb4 schema for the installer, and point .env at it with every secret double-quoted.

  3. Create the storage symlink, detect and wire your app's addon system (Modules vs packages vs addons), then link the project to Herd over HTTPS and prove the installer route is reachable.

  4. Install dependencies, build assets locally, run the CodeCanyon installer, and get the app booting at a local HTTPS domain with login working — the first time you see it run.

  5. Raise the PHP-FPM and nginx timeouts so big migration runs don't 504, pre-flight four preconditions, complete the web installer wizard, then capture the admin credentials safely.

  6. Confirm every migration ran (modules included), troubleshoot pending ones the right way, capture a normalized schema baseline for cross-environment diffs, then run the 11-point gate that proves the app actually works.

  7. Commit the installer's output (especially the storage/installed marker), document any author patches in the shipped vendor tree, verify deploy symlinks and shared_files, then lock down /install and /update with layered defense.

  8. Optional power-ups for the local environment — Atlas schema management, a database GUI (Bytebase), Redis caching via Herd Pro, and a right-sized debug-tools stack. None block launch; each has a free fallback.

04 Deploy Pipeline
  1. Install Deployer and author deploy.php for atomic releases — symlinked current → timestamped releases, shared storage and .env, retention, hooks, server binary paths, and an SSH-verified dry run.

  2. Plan the subdomain map, add A/CNAME records, provision SSL/TLS certificates, force HTTP→HTTPS, and confirm everything with a five-check CLI verification (dig, HEAD, redirect, proxy, cert details).

  3. Assemble a safe production .env — bidirectional drift check against .env.example, a Git-history secret scan, production flags and caches, directory permissions, and a verification pass. The .env lives server-side and is shared by Deployer.

  4. Wire GitHub Actions for deploys and ServerSync — author the workflow, set the GitHub Secrets (PAT, SSH key), keep clear_paths ↔ GIT_ONLY_PATHS symmetric, validate with actionlint, and confirm the run.

  5. Stand up everything that makes deployment possible — Deployer for zero-downtime releases, subdomains + SSL, production .env, and (recommended) CI, DNS email records, and a CDN — so `dep deploy staging` just works.

  6. Make transactional email deliverable — verify the email provider, add SPF, DKIM, and DMARC records (plus MX), defer CAA to Phase 7, and confirm everything with dig.

  7. Front the app with Cloudflare on the Free plan — nameserver cutover, API-driven DNS, Full (Strict) SSL + HSTS, WAF and rate limiting, cache rules, DNSSEC, and a final API verification probe. Rocket Loader stays OFF for Laravel.

  8. Close the phase — bootstrap or update the changelog and version, tag the release, then stand up an incident-response runbook (Sentry, uptime, SSL expiry, severities, contacts) wired into the repo as dev-only.

05 Deploy Staging
  1. Run the canonical pre-flight (Deployer plan preview + PHP triple-check), prepare and push the staging branch, then scaffold the server — deploy tree, .user.ini limits, and the shared .env with APP_KEY left empty.

  2. Confirm the staging subdomain resolves to the server and serves a valid TLS chain before the first release lands — a deploy onto an unresolved or untrusted host wastes a round-trip.

  3. Run the atomic first deploy, confirm APP_KEY and clear caches with the versioned PHP binary, verify the Deployer directory tree and the .env symlink (a 5-second check that prevents a 90-minute outage), confirm demo content, then loosen permissions for the installer.

  4. Temporarily unblock /install, run the CodeCanyon web installer wizard, verify the app loads, then immediately re-block /install + /update and re-harden storage and .env permissions from the installer's insecure 777 state.

  5. Take the app from "runs locally" to "runs on a real server" — provision the staging host, point DNS, ship the first atomic release, run the web installer, verify the schema, and prove rollback before a 24–48h monitoring window.

  6. Install and verify the every-minute schedule:run cron (catching the hPanel "once per minute" preset trap that silently inserts 0 * * * *), then verify migrations and export + diff the staging schema against your local baseline.

  7. Prove a one-command rollback restores the previous release, then run the full post-deploy monitoring sweep — auth, features, integrations, mobile, performance, DB integrity, logs, security, and three end-to-end journeys — across a 24–48h window, log findings, and clear the Phase 5 gate.

  8. Capture server-side changes the web installer made (config, storage markers, generated files) back into Git via the ServerSync GitHub Actions workflow — verifying workflow availability and version parity, re-auditing clear_paths ↔ GIT_ONLY_PATHS, triggering the run, and reviewing the resulting PR file-by-file.

  9. A staging-time deep audit of the codebase — project structure, composer security audit, Git hygiene, FVDUT storage persistence, secret + debug-code scans (with the word-boundary fix for dd()), storage-tracked-file triage, CodeCanyon frontend anti-patterns, and an optional schema audit.

  10. Optionally register your schema with Atlas Cloud for versioned migration tracking — open the SSH tunnel, build a baseline migration from the staging schema, push it to Atlas Cloud, apply the baseline to staging, and wire up GitHub CI. Requires an active Atlas Cloud license; free alternatives noted.

06 Superadmin
  1. Separate the in-app superadmin from the three-tier ops model, adopt the inspect-then-configure pattern that makes this phase work on any CodeCanyon app, and learn the Playwright + Livewire traps before you touch a single form.

  2. Run the up-front discovery that every later task depends on — a vendor capabilities inventory (what's admin-editable vs hardcoded, what's tier-gated), a vendor-docs digest with the APP_ENV gotcha scan, and a one-page brand profile that answers every "what colour / name / plan?" question before it's asked.

  3. Lock the admin account first (default superadmin@example.com / 123456 is publicly known), generate and upload a coherent brand asset kit, resolve the correct PHP binary for every SSH command, then audit and replace the vendor's seeded demo content before any public URL goes live.

  4. Wire transactional email through the admin panel, and learn the Froiden-family trap where a CustomConfigProvider loads SMTP from the database regardless of APP_ENV — meaning the panel's "APP_ENV changed" warning banner lies and .env MAIL_* values are ignored at runtime.

  5. Stand up the payment gateway and subscription plans — pick a Stripe account strategy, discover the REAL webhook URL and event list (never assume /stripe/webhook), grab sandbox keys with the three-actor model, paste them into the admin panel (verifying columns with DESCRIBE first), and create plans only after market research unblocks the pricing.

  6. Stand up the three legal essentials — a cookie/GDPR consent banner, a Privacy Policy, and Terms of Service — using the check-first pattern. Each is either an admin-panel field to fill or a deferral to the security/compliance phase, and the consent banner has a hard dependency on the analytics tag from the next page.

  7. Log in as the superadmin and configure everything the vendor exposes in the admin panel — branding, theme, email, payments, plans, legal pages, and analytics — using a check-first pattern that adapts to any CodeCanyon app.

  8. Apply your brand colours through the admin panel (or defer to code), confirm the error pages (404/500/503) are branded rather than raw Laravel defaults, and prepare a branded maintenance-mode page you can flip on safely with a bypass token.

  9. Wire the growth surfaces — GA4 analytics via the universal 3-file Safe Vendor Deviation Pattern (the canonical example), plus the lighter check-first tasks for a chat widget, social login, the blog system, and the sitemap. Most CodeCanyon scripts ship zero built-in analytics, so the deviation path is the common case.

07 Security Monitoring
  1. Treat every shipped secret as compromised — rotate vendor defaults, lock down file permissions, throttle sensitive endpoints, and audit mass assignment + session cookies before anything watches the app.

  2. Enforce HTTPS with HSTS + the standard header set in .htaccess, back it with a SecurityHeaders middleware, force HTTPS in production, encrypt high-risk PII fields, and require strong passwords — for Grade A at securityheaders.com (unsafe-inline caps at A until CSP nonces/hashes).

  3. Give security-relevant events a durable audit trail — install Spatie Activity Log, capture model changes, log auth and GDPR actions, and auto-prune old records so an incident always has a paper trail.

  4. The one MUST of observability — assess what already exists, wire Spatie Laravel Backup to run daily, and ship to an S3-compatible off-site destination (S3 / Spaces / B2 / R2) under one BACKUP_AWS_* env prefix with the 3-2-1 rule.

  5. Extend the basic Sentry DSN into cron monitors, performance, and release health; add rotated + structured logs; expose a health endpoint with external uptime monitoring; and define alert escalation backed by a quarterly restore drill.

  6. Decide which legal pages you need, generate and host Privacy + Terms via one generator (GetTerms / Termly / Iubenda), wire a cookie-consent banner, build GDPR data export + deletion-with-grace-period, and finalize with ROPA + DPAs.

  7. Reference for when SOC 2 and HIPAA enter the picture — applicability tests, cost and timeline, what each involves, and the platforms that automate evidence collection. Most CodeCanyon SaaS launches skip both.

  8. Harden the deployed app (rotate vendor defaults, TLS/HSTS, security headers, rate limits, session/mass-assignment audit), add an audit trail, then make it observable — off-server backups, Sentry, uptime, logs — and close out the legal layer (GDPR, cookie consent) and compliance tracks (SOC 2 / HIPAA).

08 Configure App
  1. The non-negotiable critical path — brand & core settings, transactional mail with DNS auth, a payment gateway with verified webhooks, plans & feature flags, then a full seed + verify pass before launch.

  2. Build the single source of truth for visual identity — brand name, logo variations, a WCAG-checked color palette, typography (including bilingual RTL), reference files committed to the repo, and marketing assets.

  3. Choose a payment approach from the gateway matrix (Stripe built-in vs from-scratch, PayPal, Tap for MENA, LemonSqueezy as Merchant of Record), then add the production billing depth — model, plans, verified webhooks, tax, dunning, and lifecycle documentation.

  4. Confirm and test the transactional mail path, choose a provider from the deliverability matrix, customize the core template set, and (optionally) add drip campaigns and a newsletter — all with SPF/DKIM/DMARC passing.

  5. Capture a Lighthouse baseline, then layer .htaccess browser caching + compression, tune the PHP runtime (OpCache, memory, extensions), verify Redis, enable Cloudflare, and apply accessibility/CSP quick wins — with realistic targets for a vendor-bundled app.

  6. Surface (don't silently skip) the optional integrations — Slack notifications for errors/deploys/backups, GitHub project management (labels, issue forms, project board, PR template), and privacy-first Rybbit analytics.

  7. Two post-launch tasks — claim social-media handles early (even before you post) and wire the dual changelog (internal + public) so every stable release ships with an announcement.

  8. Wire the live product end-to-end — branding, mail, payment gateways, integrations, and plan/feature flags — then seed and verify every flow before launch.

09 Growth Polish
  1. SEO needs a reachable URL, so it leads — sitemap + robots, per-page meta + schema + titles, then Search Console verification and a PageSpeed pass.

  2. Onboarding, a public changelog, a feedback collection channel, and an optional blog — the streams that keep new users reaching value and existing users informed.

  3. Two customer-facing systems with several alternatives each — a live chat widget and a help center / knowledge base. Pick one tool per row and record the choice.

  4. The pass that makes the product feel finished — SEO (sitemap, meta, schema, Search Console), onboarding/changelog/feedback/blog, and customer-facing chat + help center. Mostly SHOULD with many alternatives.

10 Audit QA
  1. Fast, deterministic checks that need no browser — project structure, Composer security audit, git hygiene, code-quality/secrets scan — plus migration analysis and FVDUT storage classification.

  2. The full security pass — header grading, ownership-aware vulnerability decisions, blocked sensitive files, admin + storage hardening, and a vulnerability register.

  3. Measure Core Web Vitals (inspect before changing), audit the live database for index coverage and N+1 queries, and fix anything that blocks Google from indexing public pages.

  4. WCAG 2.1 AA checks (automated scanners + manual verification) and GDPR/CCPA cookie inventory with consent gating that actually blocks non-essential cookies.

  5. Drive every critical journey and role (automate with Playwright MCP), run live security tests, triage by severity, then mine Telescope/Sentry/logs and check for unmerged fixes.

  6. The final gate — walk the pre-launch checklist across blockers, infra, security, monitoring, payments, comms, legal, content, and team readiness, then execute the launch sequence.

  7. The full pre-launch audit — static code & dependency checks, a security re-check, performance/DB/SEO/accessibility audits, functional QA across roles, debugger review, and a pre-launch sign-off gate.

11 Pre Customer
  1. The seven MUST gates that verify the deployed system against reality — git/deploy verification, codebase + security scan, database confidence, env audit, end-to-end testing, monitoring, and final signoff.

  2. The tiered launch decision — Tier 1 blockers must be 13/13, Tier 2 important items launch with documented exceptions, Tier 3 nice-to-haves can defer.

  3. A customer needs something to land on, a way to pay, and the legal pages that make billing legitimate — landing page, legal pages, transactional email, pricing & payment, analytics & social meta.

  4. Make the path to value short and the path to help obvious — a support surface, a five-minute time-to-first-value flow, and activation funnel tracking.

  5. The final go/no-go gate before the first real customer — technical verification, business and legal readiness, support and docs, then a tiered launch signoff.

12 Production
  1. Never skip this — rotate every test-mode key and staging password that touched a chat or log, migrate plaintext credentials into a secrets manager, re-scope over-privileged service accounts, and record the audit.

  2. Cut the changelog and version before deploying, then promote staging → production, stage the production .env, deploy dry-run then real, run the installer (first deploy only), and verify it's live.

  3. Lock down installer-friendly permissions, verify schema parity against staging, then sync all branches back to a shared base and tag the release as your rollback and audit anchor.

  4. Watch closely through the first 24–48h — smoke tests, integration checks, performance/security spot-checks, log triage, and baselines — with rollback always one command away, then the abbreviated subsequent-deploy cycle.

  5. Go live safely — pre-flight security hygiene, the first production release and installer, schema and branch verification, version tagging, and 24–48h post-deploy monitoring with a rollback always ready.

  • Read top to bottom — expand a phase, skim step summaries, open a step only when you need commands or detail.
  • Execute with checkmarks — tick the step when it’s done; ticking a step checks all its gates; ticking every gate auto-completes the step.
  • Expand all / Collapse all — scan the full tree or focus one phase at a time.