BuiltEmail workspace

Signup welcome contract

Purpose: introduce a newly registered user to Built, the dashboard and mobile app. API implementation: App\Mail\GetStarted. Baseline view: resources/views/emails/getstarted.blade.php. Referenced from AuthController::signup, signupV2 and googleCallback; preserve the existing email-versus-phone identifier guards.

Suggested subject: Welcome to Built. GetStarted does not explicitly set a subject in build(); adopting this suggestion requires a deliberate subject decision during integration. The HTML title does not set the email subject.

Suggested preheader: Open your Built dashboard to get started.

Portable placeholder contract

TokenExisting Laravel source / derivationRequirement
{{logo_url}}Existing Built app_name PNGOptional deployment override; default is the verified project HTTPS PNG; approved HTTPS or matching CID
{{preheader}}Suggested fixed copy aboveRequired escaped text; no commercial or account-completion claim
{{dashboard_url}}Existing view literal https://app.built.africaRequired trusted URL; primary dashboard action
{{features_url}}Existing view literal https://built.africaRequired trusted URL; secondary website link, not a new features endpoint
{{google_play_url}}Existing view literal https://play.google.com/store/search?q=built+accounting&c=appsLegacy source was search. Under the shared-footer update, map this preserved alias to https://play.google.com/store/apps/details?id=com.builtaccounting.app&hl=en as explicitly supplied by the user; it now drives the Google Play badge.
{{app_store_url}}Existing view literal https://apps.apple.com/gh/app/built-accounting/id1547855525Required trusted URL; opens the Apple App Store listing

The current constructor passes $user to the Blade view, but that welcome body does not interpolate a personal name. This draft adds no first-name or recipient-address token. Recipient and user data stay with the existing caller.

Content, states and destinations

The dashboard is the single primary action. The website remains a secondary text link; existing mobile-store aliases now drive the shared footer badges. The existing feature set remains: expense management, invoicing, instant payments, multiple users, bill payments, payroll, POS, multicurrency and bank reconciliation. Dashboard overview topics remain month-on-month business health, cash/bank health, top expenses and transaction tagging. No trial, discount, approval, onboarding-time or delivery promise is added.

Email signup and Google signup preview states deliberately share the same body. They document separate API trigger paths, not a new body conditional. Do not add a verify-account action to this welcome: signup verification is a separate notification, and Google signup is not evidence of the same verification sequence.

Preview links point only to the local design explanation. They never open a real dashboard, store or customer account. The standalone extract retains portable URL tokens; map the store aliases to the user-approved exact destinations in the shared-footer contract, while preserving dashboard/website literals. There are no legacy duplicate dynamic link fields for this Mailable.

Copy and integration decisions

The feature tiles and decorative images are condensed into readable text. The supplied image badges now appear once in the shared footer, with descriptive alt text and preserved URL aliases. The geographic audience and product categories remain. No source data is dropped, and no new user field is required. The proposed subject and simplified presentation are review changes, not production edits.

ready/welcome.txt and each populated state's .txt file provide plain-text alternatives. Convert the HTML tokens into existing Blade expressions/literals; do not treat {{dashboard_url}} as executable Blade. No new template framework is needed. Escape text and attributes, validate action URLs against approved hosts, and use the existing verified logo or a configured CID as described in integration-notes.html. Native dark mode is progressive enhancement; actual email-client testing is still required.

Approved activation refinement

The welcome now leads with Open your dashboard to get started with Built and the dashboard action. Product education follows that action in a single supporting section. Existing capability names, audience, overview topics and all four destinations are retained. Store destinations stay clearly labeled secondary links; no account-completion, setup-time or verification claim is added. This welcome retains its warmer team sign-off. All emails now use the user-approved shared footer described in shared-footer.md; the earlier Built-only footer policy is superseded.

Shared footer update

Read docs/integration/shared-footer.md as well. The user supplied exact app-store destinations and new badge artwork. Google Play moves from the legacy search destination to the exact user-approved app URL; both portable alias names remain. The badges require the supplied PNGs embedded as CID attachments or approved absolute HTTPS hosting. Primary dashboard action and all product/security copy remain separate.