Building a data-dense financial analytics frontend directly against a client-developed API

PROJECT OVERVIEW

ABOUT THE CLIENT

This case study is based on a real VNEXT project. The client's identity and certain project details have been anonymized or generalized for confidentiality purposes.

Our customer is a leading provider of financial data, business information, and industry research. Its analytics platform is built for the people who make decisions with numbers every day: securities firms, banks, insurers, investment funds, research houses, and consulting firms. For those users, a screen is only as good as the speed with which it lets them find the figure that matters and understand what sits behind it. Exact financials are withheld for confidentiality.

THE CHALLENGE

This engagement had a specific shape. Our customer's own engineers were developing the API, and our team was responsible for the frontend that would bring that data to life. A frontend built against someone else's API depends on constant, precise alignment, because every screen is a promise about data that another team is still shaping.

The customer's team was also technically excellent, which is a wonderful thing to work with and a high bar to meet. Their questions were sharp, their expectations for the code were high, and there was no room for a handoff that needed explaining twice.

The team was also deliberately compact, three developers guided by a project manager. In a team that size, quality cannot be something handed to a separate group at the end. It has to be a habit that every developer carries into each task.

PROJECT OBJECTIVE

Our customer wanted sector and economy analytics screens for its platform, built in React and connected to its own API, delivered by a team that could work independently, communicate clearly with a very capable group of engineers, and hand over work that was ready to review.

APPROACH AND METHODOLOGY

Starting with a daily rhythm and agreed rules

At the beginning of the project, our team met every day, and our project manager reviewed each task with the team to confirm that everyone understood it in the same way. Working rules and contact rules were agreed early, so that everyone knew who to ask about what and how quickly to expect an answer. By the time the project settled into its routine, the team was working smoothly even on days when the project manager was not involved.

Making quality a habit of the developers themselves

Quality was built into how each developer worked. Every developer tested their own task before asking for a review, and every function and module then went through code review. That sequence meant that when work reached the customer's engineers, the obvious problems had already been found and fixed.

Clarifying every task directly with the customer

Each member of our team confirmed their own tasks with the customer to clear up any doubt, rather than relying on a second hand description. With an API changing on the other side, a short direct conversation is the quickest way to avoid building against something that is no longer true.

Letting the team propose, and raising problems early

Our project manager encouraged team members to propose their own solutions, which gradually built their ability to manage their own work, and any problem the team ran into was reported to the customer as soon as it appeared. Together these habits made the team a reliable partner for a customer who valued directness.

TEAM SCALE

Our team for this engagement was a small dedicated team of three developers, guided by a project manager and working through the customer's own communication and task tools.

• Developers: built the React interfaces, tested their own work, and reviewed one another's code
• Project manager: reviewed each task with the team, kept an eye on progress, and raised issues with the customer
• Customer's own tools: communication ran through Microsoft Teams and tasks were tracked in the customer's own Jira, so our team worked inside the customer's routine

THE SOLUTION AND TECHNOLOGY STACK

The screens our team built are the part of the platform that analysts actually look at, and they are designed to turn a large amount of data into something that can be read quickly.

What was built

• Sector analytics: gives each industry sector its own area, with an overview, news and reports, and charts and tables that compare production, consumption, and individual companies
• Economy analytics: presents macroeconomic and money market data through tables, trend lines, and breakdown charts, with time range controls to move between short and long views
• A dense, readable data interface: uses a dark theme, tabbed navigation, and many charts on one screen, so that analysts can compare figures without leaving the page
• A frontend built to an external API: connects every screen to the customer's own services and keeps the interface aligned as that API evolves

Technology Stack

THE RESULTS

A frontend built beside someone else's API earned the trust of the people who wrote that API.

• A customer that wants to build more: the customer was happy with the team and expressed a wish to build further systems with it
• A team that runs on its own routines: once working and contact rules were clear, the team ran smoothly even when the project manager was not directly involved
• Work that arrives ready to review: self testing before review and code review at the function and module level meant the customer's engineers received work that was already checked
• Analytics that analysts can actually use: sector and economy views present dense data in a form that supports comparison rather than scrolling

For a customer whose own engineers set a high bar, being asked to build more is the clearest way of being told that the first project met it.