Research and Publishing Platform for Financial Services
Test: A Custom Research and Publishing Platform for a Financial Services Firm
A financial research publisher came to us with a requirement that ruled out the usual route. They wanted a subscription research product with tiered plans, an editorial workflow for staff analysts and invited guest writers, live market tooling for subscribers, and an AI layer that could answer questions about a subscriber's own holdings. Every off-the-shelf combination of a CMS, a membership plugin and a charting widget broke down at the point where those pieces had to share a single user record and a single permission model.
We built the platform end to end instead, on React, Node and PostgreSQL, and handed over the repository and the database with it. The client owns the code, the schema and the deployment, which was the point of the engagement as much as any individual feature.
What we built
The platform runs as a single application with one identity layer underneath it, so a subscriber's plan tier governs what they see across every surface, and an analyst's role governs what they can publish.
| Platform surface | What it does | Built with |
|---|---|---|
| Research CMS | Long-form report authoring, review and scheduled publishing, with categories and a newsletter push | React, Node, PostgreSQL |
| Editorial roles | Invitations for guest writers and external advisors, scoped to draft or publish rights | Role-based access control |
| Watchlist and charts | Per-user watchlists with embedded TradingView charting | React, TradingView widgets |
| Portfolio analytics | Holdings upload, exposure and performance breakdowns per subscriber | Node services, PostgreSQL |
| AI research chat | Conversational questions answered against the subscriber's own holdings and published research | LLM API, retrieval layer |
| News aggregation | Scheduled ingestion from multiple sources, de-duplicated and mapped to watchlist tickers | Node workers, cron |
| Transcript pipeline | Earnings call transcript fetching and automated summarisation for the research team | Node, LLM API |
| Plans and billing tiers | Free, retail and institutional tiers gating features and report access | Node, PostgreSQL |
| Admin dashboard | User administration, subscription management, content oversight and usage reporting | React, Node |
| Support and analytics | Self-hosted live chat and a full SEO and traffic analytics layer | Chatwoot, Docker |
The stack, and why each piece is there
Nothing in the stack was chosen for novelty. Each layer was picked because the client's team could hire against it and maintain it themselves after handover, which matters more over a five-year horizon than any performance argument.
| Layer | Technology | Reason |
|---|---|---|
| Frontend | React | One component library across subscriber, editorial and admin views |
| Application layer | Node | Shared language with the frontend and straightforward background workers |
| Database | PostgreSQL | Relational integrity across users, plans, content and holdings in one schema |
| Infrastructure | Docker on a private VPS | Portable deployment with no vendor lock-in on hosting |
| Support | Self-hosted Chatwoot | Subscriber conversations stay inside the client's own infrastructure |
What the client got
The result is a single platform where the research team publishes, subscribers read and analyse, and the operator sees the whole picture from one admin console. Because the identity and permission model was built once and shared, adding a new plan tier or a new subscriber-facing tool is a configuration change rather than a rebuild.
If you are running a business that has outgrown a stitched-together set of tools and you want a system your own team can keep hold of, that is the work Rungentic Studio does.
Disclosure: the platform described here was built for a company within the AccelXC group under a separate engagement. It runs in production with paying subscribers.