Executive summary
We set out to build a clean, trustworthy, and technically robust website for Mercer WM: a small, high-touch wealth advisory practice that offers personalized financial planning, retirement strategies, tax-aware investing, and related client services. Our remit was to create a platform that communicates the firm’s values, supports client onboarding, publishes educational resources, and runs a secure, scalable backend for account tools and advisor workflows. From the outset we decided to use Python for the majority of web and data work, and C++ for a handful of performance-sensitive components (real-time analytics and several legacy integrations). Along the way we wrestled with regulatory constraints, data integration, security hardening, and product design tradeoffs. This article explains everything we did, what tripped us up, and where we plan to take the product next.
- Why this website matters: product goals and user needs
Our primary goals when building a wealth-management website are consistent across firms, and for this project they were:
Trust & clarity. Wealth advice is built on relationships. The website must build immediate credibility: clear team bios, an explicit fiduciary orientation, transparent service descriptions, and easily understandable educational content.
Client onboarding that reduces friction. Prospective clients should be able to learn, request a discovery call, and — for existing clients — access secure tools without endless paperwork.
Operational efficiency for advisors. The site should surface the firm’s workflow tools (client dashboards, document exchange, meeting scheduling) and integrate with back-office systems to reduce manual work.
Content & thought leadership. A resource center to publish investment education, retirement planning guides, and video explainers so the firm can engage each client cohort (young professionals, generational families, retirees).
From a UX perspective we wanted the story to feel human first (people over jargon), while behind the curtain the product must be rigorous, auditable, and secure.
- Product definition: pages, features, and MVP scope
We split the initial product into distinct modules so we could iterate quickly and deploy a secure MVP.
Essential public pages (MVP):
Homepage: clear value proposition and segments (Young Professionals, Generational Families, Retired).
Services: full descriptions of financial planning, retirement income strategies, tax minimization, investment advisory, insurance evaluations.
Team & firm story: bios, credentials, and a simple “why choose us” section.
Resource center / blog: structured for articles, videos, and downloadable checklists.
Client-facing features (MVP+):
Secure client portal (document upload/download, secure messaging).
Appointment booking integrated with advisors’ calendars.
A lightweight onboarding questionnaire that feeds into an advisor dashboard.
Newsletter signup and analytics for content performance.
Advanced features for the first major release (post-MVP):
Client net-worth aggregation (read-only view of accounts via aggregation APIs).
Retirement income projection tools (scenario modeling).
Advisor workflow tools (task queues, compliance checklists, templates).
Splitting the product into modules allowed us to use Python where developer velocity and web-framework maturity mattered, and to reserve C++ for the modules where raw performance and deterministic resource use were required.
- Architecture overview (how Python and C++ work together)
We deliberately chose a hybrid architecture.
Why Python?
Python is our main language for web development, API layers, data ETL, and analytics orchestration. It offers rapid development (Django/Flask/FastAPI), excellent libraries for security and testing, and a large ecosystem for integrating with fintech APIs and cloud services. Python accelerates iteration on user flows, content management, and admin tooling.
Why C++?
C++ is used selectively for components that require maximal performance and minimal latency: the financial scenario engine that runs thousands of Monte Carlo simulations per client query, and a few data normalization adapters that must process large transaction streams deterministically. Using C++ in these spots kept computational cost low and response times snappy for users who run on-demand projections.
High-level diagram (textual):
Client browser or mobile app → HTTPS → Python Web/API Layer (FastAPI)
Python handles authentication, page rendering (server-side templates + client SPA), and orchestrates microservices.
Heavy compute requests (scenario modeling) are proxied to our C++ compute service via a secure RPC (gRPC).
Results are cached in Redis and persisted to PostgreSQL for auditability.
Static assets and media are served from a CDN; backups and logs land in an S3-compatible storage layer.
CI/CD pipelines manage deployments (automated test suites → staging → canary → production).
The result: developer-friendly app iteration with a performance-critical core that scales predictably.
- Core technical stack and key libraries
Below is a distilled list of the technology choices we made and why.
Backend / API
Python 3.11 — main server language for APIs and admin.
FastAPI — async, high-performance web framework for JSON APIs.
SQLAlchemy + Alembic — database ORM and migrations.
PostgreSQL — primary relational store for client profiles and configuration.
Celery + Redis — background tasks (report generation, external fetches).
Client / Frontend
Server-side rendered landing pages for SEO, with a small single-page portion for the client portal (React).
Progressive enhancement to ensure content loads even with JS disabled.
Compute / Performance
C++ (modern standard) for the scenario engine and for a small, high-throughput adapter that cleanses transaction data before normalization.
gRPC between Python and C++ services for efficient binary RPC with strong typing.
Security
OAuth2 / OpenID Connect for staff login sessions.
AES-256 encryption at rest; TLS 1.3 in transit.
WAF and automated security scanning in CI.
Observability & Ops
Prometheus + Grafana for metrics.
Centralized logging (structured JSON logs forwarded to an ELK/Opensearch cluster).
Sentry for runtime error tracking.
Testing/CI
pytest + hypothesis for Python.
Google Test for C++ components.
Docker-based integration tests in GitHub Actions.
This stack balanced speed of development with enterprise-grade reliability.
- Content strategy & information architecture
A wealth firm’s site must solve two problems: convert new leads and support existing clients. We organized content to support both.
Audience-first taxonomy:
We modeled pages for each audience bucket (Young Professionals, Generational Families, Retired) with content tailored to the lifecycle stage and likely concerns: debt management, saving for college, retirement income, healthcare planning, and legacy strategies. These buckets allowed targeted landing pages and clearer navigation.
Resource center:
Data-driven content is crucial for SEO and client trust. We built a resource center as a CMS-backed collection with:
Long-form articles (guides and explainers).
Short primers (checklists).
Video explainers embedded securely.
A library of calculators (retirement horizon, tax-loss harvesting examples).
Client education funnel:
Visitors can move from an educational post → interactive calculator → request a consult. Every resource contains clear next steps and contact points.
- Security, compliance, and regulatory demands
Building a financial advisory website requires strict adherence to privacy and compliance expectations.
Regulatory and fiduciary considerations:
Financial firms must be careful with claims, disclosures, and client solicitation. All service copy was reviewed by compliance to ensure no unsubstantiated promises.
Data security:
PHI/PII minimization: we never store unnecessary identity attributes. We built data retention policies and a data access matrix so that only authorized staff can retrieve sensitive client documents.
Encryption: we implemented field-level encryption for account numbers and social security identifiers, and encrypted backups with rotation of keys.
Audit trails:
Every advisor-facing action (recommendation upload, plan acceptance, version changes) is logged and time-stamped for compliance and for client transparency.
Third-party vendor scrutiny:
We have strict vendor onboarding: SOC 2 Type II reports, penetration test results, and contractual SLAs. Any third-party aggregation service (for account read-only views) must meet our security bar.
- Data integration: account aggregation and custodial links
One of the most delicate technical pieces is integrating financial account data for clients.
Challenge: multiple custodians, different CSV layouts, inconsistent APIs.
Solution approach: build a normalization pipeline:
Ingest layer (Python) — accepts raw files (CSV, OFX) or API payloads from aggregators.
Normalization (C++ adapter + Python rules) — we initially experimented with pure Python parsers, but for the highest-volume brokers the transaction feeds were large and needed deterministic parsing. We implemented a C++ adapter to parse and canonicalize streams into a common schema. C++ gave us speed and lower memory overhead for batch jobs.
Reconciliation (Python) — after normalization we run reconciliation rules, detect duplicates, and error out to a human review queue if mapping confidence is low.
Storage & display — normalized snapshots persisted to PostgreSQL and the time-series bucket in our analytics store.
Tradeoffs: C++ code reduced runtime and memory on large files, but raised the barrier for junior developers. We wrapped the C++ bits with Python bindings to keep day-to-day development flow in Python.
- What we learned building the retirement scenario engine
A key value-add is interactive retirement projections. People expect a responsive tool that can run multiple scenarios quickly.
Design goals:
Fast on-demand simulations.
Clear, auditable assumptions (inflation, expected returns, sequence of returns risk).
A format that advisors can save and annotate.
Why Monte Carlo in C++?
We prototyped Monte Carlo simulations in Python (NumPy), but profiling showed that for high-precision runs the latency per scenario was too slow when used by multiple users concurrently. We rewrote the simulation core in modern C++ (vectorized, using high-performance random number generation and parallelism). The Python layer orchestrates parameters and presents results; the C++ service returns summarized results and percentile bands.
UX choices influenced by technical constraints:
We limited interactive runs in the browser to a reasonable default (e.g., 2,000 trials) and allowed advisors to request high-fidelity batch runs asynchronously (10k+ trials), with email-notified completion.
Caching: identical parameter runs are memoized for 24 hours to cut compute spend.
Outcome: sub-second responses for common queries and a robust, auditable batch pipeline for advisor-grade reporting.
- Problems we faced and how we solved them
Every build has unglamorous, instructive problems. Here are the main ones we encountered and our resolutions.
Problem 1: Reconciling marketing vs compliance copy
Issue: Marketing wanted bold claims; compliance required precise language.
Resolution: We created a formal two-stage copy process: marketing drafts → compliance review → legal approval. We built a small CMS flag that forces sign-off steps for any content tagged as “promotional” or “service claims.” This reduced rework and made approvals auditable.
Problem 2: Data provider instability and schema drift
Issue: Third-party feeds changed CSV headers, causing nightly jobs to fail.
Resolution: Implemented a robust schema-detection and mapping layer with automated schema-change alerts. New header shapes enter a quarantine pipeline where a human reviews mapping suggestions. This prevented silent data corruption.
Problem 3: Performance bottlenecks in projections
Issue: Python Monte Carlo runs blocked concurrency and spiked cloud bills.
Resolution: Offloaded the compute core to C++ and implemented request throttling + caching. Also set up a job queue for heavy runs.
Problem 4: Secure document exchange with non-technical clients
Issue: Some clients resisted multi-step SSO flows or password managers.
Resolution: Supported secure one-time URLs for document upload/download with strict expiration and IP logging, and offered phone-assisted walkthroughs to help adoption.
Problem 5: Balancing developer velocity with C++ complexity
Issue: C++ modules were harder to maintain and slowed feature changes.
Resolution: Keep C++ minimal and well-encapsulated behind a gRPC API; provide Python wrappers and robust integration tests so most feature changes happen in Python.
Problem 6: Analytics vs privacy
Issue: Marketing wanted detailed analytics, compliance insisted on minimal PII collection.
Resolution: Implemented pseudonymized analytics — activity events are hashed and separated from identity mapping in a protected vault; only aggregated metrics appear in dashboards.
These problems forced us to design for maintainability, auditability, and graceful degradation.
- Testing, QA, and release process
Financial sites cannot afford regressions. We designed a stringent test and release pipeline.
Automated tests
Unit tests for Python + C++ units.
Integration tests that spin up ephemeral databases and run end-to-end flows (onboarding, document upload, projection runs).
Security tests: dependency checks, static analysis, dynamic scanning.
Staging and canary
Staging environment mirrors production.
Canary deployments roll features to 1–3% of users and monitor errors, latency, and resource use before full rollout.
Compliance regression suite
A special test set checks that policy-required disclosures show, that content copy is not altered accidentally, and that workflow sequences satisfy compliance checklists. This suite is run before any public content change.
Disaster recovery
Daily backups, tested restores, and runbooks that cover common failure modes (DB failover, key rotation, WAF incidents).
- Accessibility and inclusive design
Advisory sites must be accessible to older clients and users with impairments.
Actions taken
WCAG AA standard as a baseline for layout and color contrast.
Large-font and simplified views for clients who want concise information.
Keyboard-only navigation and aria-labeling for interactive controls.
Usability testing sessions with representative clients (including retirees with limited tech experience).
Accessibility improved conversion and decreased support calls.
- SEO, content optimization, and discoverability
We designed content to be discoverable for people searching for retirement planning, tax-aware investing, and family wealth planning.
Tactics
Deeply structured resource center with topical clusters and internal linking.
Server-side rendered landing content for immediate SEO value.
Semantic headings, FAQ sections (schema markup), and well-structured metadata.
Fast page load and image optimization (CDN + lazy load).
Content strategy is aligned with educational outreach: provide value first, then invite deeper connection.
- UX patterns for financial trust
Trust is both visual and functional. We incorporated several trust-building UX patterns.
Team visibility: short bios and professional credentials with photos — but we do not publish sensitive personal data.
Process transparency: a simple step-by-step explanation of how we work with clients (discovery → plan → implement → review).
Case studies (anonymized): real-life scenarios showing outcomes without revealing identities.
Regulatory badges & disclosures: clearly shown but not overbearing.
These elements reduce friction in the initial outreach process and set correct expectations.
- Operationalizing advisor workflows
A website is not merely a brochure — it must be tightly integrated into advisor workflows.
Key integrations
Calendar sync (read/write) for appointment booking and reminders.
Document management with versioning for engagement letters and plans.
Task queues and templated checklists so advisors follow consistent compliance steps.
Audit logs for every client-facing communication.
Advisor portal features
Universal search across client files.
Snapshot views of client financial health with quick actions (request documents, schedule reviews).
Exportable reports with advisor annotations for regulated record-keeping.
Automation reduced advisor admin time and improved the client experience.
- Branding and tone: voice of the site
The copy strategy aims for clarity mixed with warmth: no buzzword-heavy claims, just explanatory writing that respects the reader’s intelligence. This voice supports stewardship and long-term relationships.
We created a style guide covering:
Plain language rules for financial terms.
A template for problem→solution→next steps in each service page.
A “translation” glossary that explains terms like “sequence of returns risk” in consumer-friendly language.
- Performance & cost optimization
Keeping hosting costs under control is important for independent firms.
Optimizations implemented
CDN for static assets.
Autoscaling for API servers with resource-based autoscaler (CPU + request queue length).
Cache layers (Redis) to reduce database reads for repeated projection requests.
Cold-start avoidance for compute containers by maintaining a minimal warm pool during business hours.
Observability feedback loop
Cost alerts feed into our weekly engineering review, so engineering and business stakeholders can tune compute options (e.g., reduce Monte Carlo fidelity for non-advisor runs).
- Launch metrics and what we monitor
On launch and in the first months we tracked the following KPIs:
Organic traffic to resource pages and average time on page.
Conversion rate from content view → contact form.
Onboarding completion rate (percentage of users who complete the intake questionnaire).
Average time advisors spend on administrative tasks (goal: reduce by 25% in 6 months).
System reliability (SLA adherence, error rates).
These metrics guided iterative improvements.
- Future goals & roadmap
Our vision extends beyond a brochure site to a full digital experience for clients and advisors. Key near- to mid-term goals:
1) Smarter client personalization
Use client-provided profile data and site behavior to surface tailored resources. For example, dynamically prioritize retirement-focused content for users in late-career, and present budgeting tools to early-career users.
2) AI-assisted advisor workflows
Introduce generative-assistance for draft plan summaries, compliant email templates, and meeting notes — all with human-in-the-loop controls and strict logging to meet regulatory requirements.
3) Mobile-first client app
A lightweight, secure app giving clients quick access to documents, messages, and a simplified snapshot of their plan and upcoming tasks.
4) Deeper integrations with custodians
Direct custody-level integrations to provide near real-time balances and position-level insights while maintaining read-only security posture.
5) ESG and impact investing modules
Tools to screen portfolios for ESG preferences and model the impact of values-based choices on expected returns.
6) Financial wellness for employees and small businesses
White-label modules where the firm can provide benefits counseling for small business owners and their teams.
7) Community & education
A webinar series, cohort-based planning workshops, and tools for family governance (education modules for generational wealth transfer).
Technically, these features will require careful scaling — more ML models, more asynchronous jobs, and continued prudence about which workloads go to Python vs compiled backends.
- How we’ll measure success for future features
Each new feature has a hypothesis and measurable outcomes:
Personalization hypothesis: "Personalizing resource landing pages will increase conversion to consult requests by 15%." Measurement: A/B test with tracked conversion events.
AI-assist hypothesis: "Draft templates will cut advisor drafting time in half while maintaining compliance." Measurement: Time-on-task and compliance flags.
App adoption hypothesis: "Offering a mobile app will increase onboarding completion by 20%." Measurement: onboarding funnel analytics split by platform.
We plan short experimentation cycles with guardrails for privacy and compliance.
- Team, culture, and handoff
To maintain the site we set a cross-functional team model:
Product owner / advisor liaison — closes the loop between advisors and engineering.
Frontend & backend engineers — Python-heavy for most work; one senior C++ engineer for compute components.
Compliance & legal reviewer — mandatory reviewer on any messaging or product flows that touch client agreements.
QA, security & operations — maintains reliability and incident response.
Documentation is critical. We maintain an internal developer playbook, onboarding docs, and runbooks for common incidents.
- Final thoughts: delivering a site that people trust
Building a wealth-management website is more than UI polish. It’s about engineering a trustworthy experience that handles sensitive data with caution, provides helpful education, speeds advisor workflows, and supports long-term relationships. Using Python for speed of iteration and C++ for targeted performance allowed us to ship features quickly while retaining compute efficiency.
Our roadmap remains centered on clients: better tools, clear education, and an honest, transparent service model. Every technical decision — the normalization pipeline, the choice to memoize compute results, the strict vendor review — was driven by that north star.
We are proud of what we launched: a secure, user-first digital presence that amplifies the advisor-client relationship, reduces friction, and creates space for the firm to scale its impact while keeping the human element first.
Top comments (0)