The Starting Point

An SEC-registered, privately held investment management firm in the New York metro area needed its digital presence to match its investment operation. They provide actively managed balanced and equity strategies to institutions, individual investors, and their advisors. Their product line includes ETF offerings that require daily public-facing performance data.

That’s a long list of requirements for any website. But this firm didn’t need a website. They needed a system: live market data displayed securely, a growing library of decks and fact sheets managed at scale, compliance review on every piece of published content, and quarterly performance reports that update without a developer. Most agencies hear those requirements and suggest a custom-built platform. We built the entire thing on HubSpot.

The Challenge

Three problems were layered on top of each other, and none could be solved independently.

The first was visual credibility. The site needed to look institutional, the kind of presence that an allocator or advisor visits and immediately takes seriously. Financial services audiences have specific expectations around visual sophistication: muted color palettes, polished data presentation, video-forward content. Anything that looks like a marketing template undermines trust before a visitor reads a word.

The second was operational scale. The firm maintained a growing library of investment documents: strategy decks, fact sheets, quarterly outlooks, performance recaps, video content, downloadable resources. Managing these as individual pages created maintenance overhead and inconsistency. When a new fact sheet meant building a new page from scratch, content updates moved slower than the firm’s investment cycle. They needed a structured system that could grow without proportional increases in development time.

The third was a technical constraint that didn’t have an off-the-shelf answer. The firm’s ETF products required daily performance data displayed publicly on the website. That data lived on an external server, on a separate domain, with its own security restrictions. There was no API. No native HubSpot integration. No plugin that could pull a CSV from an external domain, parse it, and render it in a public-facing table. If this was going to work on HubSpot, someone had to build it.

And threading through all three: compliance. Every piece of published content passes through compliance review. That constraint doesn’t just affect the content itself. It shapes the technical architecture, the approval workflows, and the speed at which anything moves from draft to live.

The Approach

Creative direction came first. Two designers established the visual language: a shift to muted navy with orange accents, video-forward design, a look and feel that read as institutional finance rather than startup marketing. The lead developer translated that direction into HubSpot CMS architecture.

The biggest architectural decision was how to handle the content library. Instead of building individual pages for each resource type, the team centralized everything into a single HubDB table. Every deck, fact sheet, video, investment outlook, performance recap, and downloadable document would live as a row in that table. Custom modules would pull the right content into the right sections of the site based on content type, strategy, and date. Adding a new resource would mean adding a row, not requesting a page build.

The ETF data integration required a completely different technical approach. No existing HubSpot feature could display live data from an external CSV hosted on a separate domain. The ETF site developer designed a custom solution from scratch: JavaScript that reads, parses, and renders data from that external source through a custom HubSpot module. The architecture had to respect the security restrictions on the data source while making the information publicly accessible.

Six workstreams. One platform. One team thinking through all of it together.

The Solution

Live ETF Data Integration

This is the technical centerpiece of the project, and it’s worth describing precisely because it demonstrates what HubSpot CMS can actually handle when someone knows how to build on it.

The client’s ETF products generate daily performance data. That data gets uploaded as a CSV file to an external server hosted on a separate domain, not on HubSpot, not on a connected system. The server has its own security restrictions governing access.

The ETF site developer wrote custom JavaScript that reads that CSV from the external domain, parses the data, and maps it into a custom HubSpot module. The module renders a public-facing table displaying current ETF performance data. No API is involved. The entire integration is JavaScript, a hosted CSV, and a custom module working together.

This matters because it’s the kind of requirement that typically pushes firms off HubSpot entirely. “You need live data from an external source? HubSpot can’t do that.” Except it can, if you build the integration yourself. The ETF sub-site is actively maintained and the data feed continues to update without developer intervention for each refresh.

For a technical audience: the architecture is intentionally simple. No middleware, no third-party connectors, no API layer that introduces additional failure points. JavaScript reads a file, a module displays it. The complexity is in making that work reliably within HubSpot’s CMS constraints and the external server’s security model.

HubDB as Enterprise Content Management

Most agencies use HubDB for blog listings or event calendars. This project uses it as the backbone of an enterprise content management system for a financial services firm.

A single HubDB table manages every resource the firm publishes: strategy decks, fact sheets, the video library, investment outlooks, quarterly recaps, and downloadable documents. Each resource is a row with structured fields for content type, associated strategy, publication date, file links, and descriptions. Custom modules pull from this table to populate resource sections across the site, filtering by type and relevance.

The operational impact is significant. When the firm produces a new quarterly outlook, someone adds a row to the HubDB table with the relevant fields populated. The document immediately surfaces in the correct sections of the site. No page creation, no template work, no developer ticket. When a fact sheet gets updated, the row gets updated. One source of truth, multiple display contexts.

This is HubDB operating at a scale most implementations don’t attempt. It’s the difference between using a database feature to manage a blog sidebar and using it to run the content operations of a regulated financial firm.

Site Redesign and Custom Data Visualization

The full site redesign took approximately three months from creative direction to launch. The homepage leads with video content. A mega menu dynamically pulls the latest blog content, so navigation stays current without manual updates. The visual design was built to meet the expectations of institutional investors and financial advisors who evaluate credibility partly through visual sophistication.

Custom pie charts, built from Excel data, support the firm’s investment strategy communications. Financial services audiences expect polished data visualization as a baseline, not a feature. Quarterly strategy pages for each investment strategy display current performance data and get updated each quarter with the latest earnings and return figures. These are manual updates, distinct from the automated ETF feed, handled as routine content operations rather than development projects.

The distinction matters. Not every data operation needs to be automated. The quarterly pages update four times a year with curated data that requires human judgment about presentation and context. Automation serves the daily ETF feed. Structured manual processes serve the quarterly reporting. Both are valid architectures for different cadences.

Newsletter Strategy and Content Operations

The firm’s monthly newsletter is built around their investment strategy, not around marketing metrics. Each edition combines a core content piece with industry analysis and commentary from the investment team. The format is designed to keep institutional audiences engaged between quarterly reports, positioning the firm as a thinking partner rather than just an asset manager.

Hypha launched the newsletter, established the production workflow, and audited its performance. 

The compliance dimension is constant. Every edition, from subject line to market commentary, passes through compliance review before send. That’s not a bottleneck when it’s built into the workflow from the start. It only becomes a problem when teams treat it as a final gate rather than a production step.

On the blog side, the content strategy is built around evergreen value. Posts are written to stay relevant, and high performers get periodic refreshes rather than replacements. That discipline means the blog compounds over time instead of requiring constant new production just to maintain traffic. All new content follows a compliance-conscious process, with review built into the production workflow rather than added at the end.

What Changed

The firm now runs its entire content operation through a single platform. The shift isn’t dramatic in the way a traffic graph or lead count might suggest. It’s structural. The firm has content infrastructure rather than a collection of pages, and that infrastructure handles the complexity of financial services content operations without requiring a custom-built platform or a team of developers to maintain it.

What that looks like in practice:

• Live data: ETF performance updates without developer involvement. The CSV-to-module pipeline runs on its own.
• Content management: Investment documents surface automatically when someone adds a row to a database. No page builds, no tickets.
• Quarterly reporting: A content update, not a web development project. Data entry into an established structure, four times a year.
• Newsletter: A tested playbook with documented optimal send times, subject line patterns, and compliance guardrails.
• Blog: An evergreen content strategy with a refresh discipline for high performers, plus a compliance-conscious production process for new pieces.

Before this build, these functions were either spread across multiple systems, handled manually, or simply not possible. The ETF data wasn’t accessible on the website at all. Content management meant individual page builds for every new document. Quarterly reporting required development support for what should be a routine operational task.

What Became Possible

With the foundation in place, several things changed about how the firm operates its digital presence.

New content types can be added to the HubDB system without building new templates. If the firm launches a new content format like a podcast series, a research publication, or a new type of investor update, it’s a new content type in the existing table, not a new section of the website. The architecture was designed for content types that don’t exist yet.

The quarterly reporting cycle is now predictable and self-contained. Strategy pages get updated with new performance data four times a year. No scope discussions, no development estimates, no project timelines. Just data entry into an established structure.

The newsletter has documented benchmarks and a testing framework that produces reliable results. Future optimization work builds on a known baseline rather than starting from assumptions. And the compliance workflow is established and repeatable, so new team members can follow the same process without reinventing the approval chain.

Perhaps most importantly, the ETF data integration proved that HubSpot CMS can handle requirements that most people assume require a different platform entirely. That proof of concept opens the door for additional data integrations, additional external feeds, and additional use cases that would have been dismissed as “not possible on HubSpot” before someone built the first one.

The Broader Pattern

Financial services firms tend to accumulate fragmented systems because they’ve been told their needs are too complex for a single platform. Compliance requirements push them toward specialized tools. Live data needs push them toward custom builds. Content management at scale pushes them toward enterprise CMS platforms with six-figure licensing costs.

The pattern we see is that the complexity isn’t in the platform. It’s in the implementation. HubSpot CMS, properly architected, can handle live external data feeds, enterprise content management, compliance-conscious workflows, and the full range of financial services content operations. The gap isn’t capability. It’s that most implementations don’t push the platform far enough to find out.

That’s not a criticism of other approaches. Plenty of financial services firms have good reasons for their current architecture. But for firms that are already on HubSpot or evaluating it, the question worth asking isn’t whether the platform can handle financial services complexity. It’s whether the team implementing it knows how to build at that level.

Starting the Conversation

Most financial services firms we talk to have the same question: Can HubSpot actually handle what we need, or are we going to outgrow it in a year? The answer depends entirely on how it’s built.

If your content operations are spread across multiple systems because someone told you HubSpot couldn’t handle the complexity, or if you’re evaluating whether your current platform can support live data, compliance workflows, and enterprise content management, that’s a conversation we’re well-equipped for.

Not a pitch. A technical conversation about your specific architecture and what’s realistic. Reach out to a Hypha expert today to learn more.