Wealth-Tech Feature Launch Readiness Checklist
Most wealth-tech feature launches that go sideways post-ship don't fail on the engineering. They fail on a missing compliance review, an unmapped edge-case archetype, a broker-dealer disclosure that wasn't updated, a CRM field that wasn't added, or a CS team that wasn't briefed on the failure modes. This checklist is a cross-functional readiness gate covering the gaps that consistently surface in our post-launch reviews of buyer features (rebalancing, planning, reporting, onboarding, advice). Run it as a hard gate: if any item is red, ship date moves.
Engineering readiness
- Feature flag wired with rollout-percentage capability
Feature flag with percentage-based rollout and per-customer override capability. Flags without rollout are launch-or-rollback only — no graduated risk reduction.
feature_flag.percentage_rollout, .per_customer_override - Test coverage on edge-case archetypes
Automated test coverage that exercises the feature on a synthetic-data corpus including the edge cases the feature must handle (ITIN, multi-state, K-1, RSU vesting). Modal-only test data produces features that crash on the long tail.
tests.archetype_coverage[] - Performance baseline at production scale
Latency and throughput baseline measured at the production-equivalent corpus size, not at dev-fixture size. P99 latency measured under realistic concurrency.
perf.baseline.{p50, p95, p99, throughput}, .corpus_size, .concurrency - Observability instrumentation
Metrics, traces, and structured logs for the new feature with named alerts wired to on-call rotation. Features that ship without alerting have undetected failures.
observability.metrics_emitted[], .alerts_configured[] - Rollback procedure documented and tested
Documented rollback path with the specific commands, the data-migration impact, and a successful tabletop or staging dry-run. Untested rollbacks are the leading cause of extended outages.
runbooks.rollback.{procedure, last_tested_date}
Compliance & legal
- Compliance review sign-off with documented scope
CCO sign-off on the feature with documented scope of review (suitability, advertising, fiduciary, fee-disclosure). Scope-and-date is what regulators ask for.
compliance.review.{cco_signoff, scope[], date} - Disclosure refresh (Form ADV / Form CRS / engagement letters)
Required disclosure updates filed and effective. New advice-feature → Form ADV Part 2A item update. New fee component → engagement letter refresh.
compliance.disclosure_updates[] - State registration / notice-filing implications evaluated
If the feature affects state-by-state activity (e.g. taxable advice in new states), the state-registration / notice-filing impact must be evaluated. Often missed for features that look state-neutral but aren't.
compliance.state_filing_impact_review - Marketing materials reviewed under SEC Marketing Rule
All marketing materials reviewed against the SEC Marketing Rule (effective Nov 2022) including testimonial / endorsement disclosures and performance presentation rules.
marketing.review_completed_date, .marketing_rule_compliance_check
Data & integrations
- CRM field additions deployed
New CRM fields (Salesforce Financial Services Cloud, Wealthbox, Redtail) deployed and field-permissions configured for the relevant roles.
crm.field_additions_deployed[], .permissions_configured - Custodian integration tested end-to-end
End-to-end test of the integration to relevant custodians (Schwab, Fidelity, Pershing) — order routing, position reconciliation, fee-debit. Integration sandbox testing alone is insufficient.
integrations.custodian_e2e_tests[] - Data backfill plan for existing customers
If the feature requires new data fields, the backfill plan for existing customers — sourcing, validation, communication. Features that work for new customers and silently fail for existing ones are common.
data.backfill_plan, .existing_customer_communication - Reporting / statement template updates
Customer-facing statement and reporting templates updated to reflect the new feature. Statement-template lag is a customer-trust hit.
reporting.template_updates[]
Customer success & support
- Internal training delivered to CS, sales, ops
Documented training delivered to customer-facing teams covering the feature, the failure modes, the FAQ, and escalation paths. Training-deck-only without delivery evidence is insufficient.
training.delivery_log[] - Support runbook covering common issues
Support runbook with common-issue diagnostic flows and escalation criteria. Run a tabletop with two CS reps to validate before launch.
runbooks.support, runbooks.support.tabletop_completed - Customer communication plan
Sequence of customer-facing communications — pre-launch announcement, launch notice, post-launch follow-up. Beta-customer outreach plan if applicable.
comms.customer_comms_plan
Post-launch monitoring
- Success metrics defined and dashboard wired
Defined success metrics (adoption, retention, revenue impact) with a dashboard wired before launch. Post-hoc metric definitions don't survive the first sprint.
success_metrics.{definitions, dashboard_url} - Failure modes catalogued with response plan
Pre-launch enumeration of expected failure modes with response plan for each (alert → who → what action). Includes performance regression, integration breakage, compliance issue.
failure_modes[].name, .response_plan - Decision criteria for full-rollout
Pre-defined criteria for advancing from N% to 100% rollout — adoption threshold, error-rate ceiling, support-ticket volume. Rollout decisions made post-hoc tend to be over-influenced by the loudest stakeholder.
rollout.advancement_criteria
Key takeaways
- The launches that go sideways usually fail on a non-engineering item — disclosure refresh, CRM field deployment, CS training, statement-template lag.
- Test coverage on edge-case archetypes is the leading indicator of post-launch incident rate. Modal-only test corpora produce features that look great in QA and crash on the long tail.
- Rollback procedures must be tested, not just documented. Untested rollbacks are the leading cause of extended outages because the rollback itself fails under stress.
- Pre-defined rollout-advancement criteria prevent post-hoc decisions dominated by the loudest internal stakeholder. Set them in writing before launch.